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

[Bruce Ferrell]

On 3/26/19 11: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
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon

If you've not tested the functionality, why on earth would you think it should be merged? *just* because it's JS/JSON?

In my professional life, I've found some pretty extensive issues with JS and pushing stuff I think of as server side out to the browser even if it DOES make things easier for devs.

While JS allows very fast "use" there is also  an entire discussion happening over in docker land about people grabbing and using container images with no idea of the entirety of 
it's dependencies or safety/security resulting in insecure containers in the docker repository.  JS is all of that in spades.

You and I have had a somewhat similar discussion on Python right here.

My own opinion, worth what you paid for it, is that when you've tested the function for yourself and can articulate the exact benefit to be gained for us all, WITH patches only 
then should integration be considered.  Until then, it's a statement that you want someone to do that work for you.

I DO appreciate getting a chance to see these little known add-ons though.

Looking at the GIT repository for xymondash, I see the usually Python nonsense... You need Python 3.5 (probably not installed already and a royal pain to get into your system and 
bleeding edge) and if you want to use what IS likely already installed, you need to switch to "python esoteric feature X" and makes reference to python docs along with snark about 
which browsers don't support the dripping blood features of the "tool".

GACK!

The procmem tool is somewhat interesting but if you KNOW have a process that needs to be monitored for it's memory use, don't you think that an indication of an issue with that 
process that needs fixing? Ya know, memory leaks ARE kind of considered very to be bad form, or maybe that's just me.

That said, I do a "kill -9" on devmon and restart it via cron because I know it balloons on my system;  I know it because xymon told me something was using up memory.  Once I did 
the diagnosis of what and how often, my remedial action was to just kill it off and restart it.  Inelegant perhaps, but I seem to be the only one experiencing this particular 
issue.  Why would I do monitoring on it rather than fixing the issue if not the process?  Seems like asking how many angels can I get to dance on the head of a pin and when exactly 
do they start falling off.