[Xymon] Merging some add-ons into Xymon source code

[John Thurston]

Does the procmem add-on not work just fine as is?
Is it just the configuration-point which is annoying you?

> Another example is Xymondash:

Oh please, no.    Read my sig.

If I wanted a json xml javascript monster, I'd select from the myriad of 
commercial products out there. We've run xymon/bb since the dawn of 
time. In the last twenty years, several other monster products have been 
brought in to "improve the look and feel" of our monitoring. All have 
died an early death, leaving our simple xymon server doing its duty and 
displaying its results.

I'll stick with "boring that works".

--
    Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska

On 3/26/2019 10:49 AM, SebA wrote:
> I think merging some add-ons into the Xymon source code should be 
> considered where those add-ons would be widely used, subject to 
> licensing restrictions.
> 
> For example, and I have not yet tested this add-on, but a way to alert 
> on processes using too much memory looks increasingly useful to me 
> (together with graphing of memory for certain processes):
> http://tools.rebel-it.com.au/xymon-procmem/ 

> Ideally the shell code that add-on uses would be converted to support in 
> the C code so that this could be configured in analysis.cfg rather than 
> hosts.cfg though.
> 
> Another example is Xymondash:
> https://github.com/daduke/Xymondash 

> I haven't used it yet either, but it sounds good.  Having said that, 
> development on that shouldn't be stymied by locking it to Xymon releases 
> - and it requires Python >= 3.5 (or 3.4).  Maybe as a post-installation 
> task Xymon could ask if you wish to install it, check dependencies, ask 
> a few questions, download and install it?
> It would be good to be able to present a more modern GUI as part of Xymon.
> 
> Kind regards,
> 
> SebA
> 

>