Merging some add-ons into Xymon source code 🔗 link

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

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    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Department of Administration
State of Alaska

On 3/26/2019 10:49 AM, SebA wrote:

On 3/26/2019 12:06 PM, John Thurston wrote:

I was looking at how something like this could be added in as well, but it'll be a bit of effort to convert it into the existing C testing loop.

It's definitely very useful as an add-on, though.

I think there's a lot to like in xymondash, but for the moment cleaning up the existing interface and making most usable to users and add-ons would be the priority.

Adding JSON output to xymondxboard (xymondjboard?) should be considered a priority, however. That would probably aid in interoperation.

Regards,

-jc

On Tue, 26 Mar 2019 at 19:52, John Thurston <user-ce4d79d99bab@xymon.invalid>

wrote:

Like I said, I haven't tried it, but it does something that  I think should
be part of Xymon - process memory monitoring - and the way it does it is
not very 'xymonish' - the xymonish way to configure thresholds is in
analysis.cfg, not in hosts.cfg.

--

Those were just 2 semi-random examples, another is probably calculation of
CPU load thresholds based off the number of reported processors:
https://wiki.xymonton.org/doku.php/monitors:cpu-load-calc
Something _like_ this should be in Xymon, because otherwise the default CPU
load thresholds are more or less meaningless and have to be configured for
each server class / function intersection.  But it should be in the core
code, not a shell script that operates differently and independently of the
core CPU calculation code.

For things that <40% users don't want, they shouldn't be integrated - I'm
with you on that John - and what I suggested about Xymondash being more
like a suggested optional package is maybe a middle-ground.  But if the
core function is something >40% users would want, then the feature should
be integrated, because it lowers the barriers to entry for users and adds
to the core feature list / reduces the core annoyance list.  I've not tried
any of these 3 add-ons because they are add-ons, and because the desire for
them is relatively recent or intermittent, but I would have implemented
them if they were part of the core package.  (I've tried other add-ons of
course, and created a few of my own over the years.)

Kind regards,

SebA

On 3/26/19 11:49 AM, SebA wrote:

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.

hi all,

xymondash author here.

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.

it was a conscious decision to have everything display related in client JS
while the JSON filter logic is in server-side python.

even Debian stretch has python 3.5 out of the box. Interesting definition of

'bleeding edge'.

the interface is fully usable on any recent browser. Safari and Edge just
render the background gradient a little uglier than the rest.


I'd be happy to work with the xymon team to streamline things if there's
sufficient interest to get xymondash mainlined. In particular, having the JSON
source fully integrated would eliminate the service side headache and allow
for static xymondash hosting.


cheers,
-Christian

On Tue, 26 Mar 2019 at 23:15, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid> wrote:

I didn't say it should be merged.  I was just giving a few examples of
add-ons that cover functionality that should be considered for merging /
adding to the Xymon core package.  Maybe the subject of the thread and
initial wording was misleading, and I apologize for that.

Well, maybe we could just monitor the memory usage of all processes on the
same rrd chart - that way it shouldn't get too big - is that correct?

How did you do the diagnosis of how often it would need restarting?
Process memory monitoring is what you need to determine how bad the memory
leak is and how often something would need restarting.  Maybe you ran ps
via cron and put that into a log file and then analysed that - but it's
easier to look at a chart.

Kind regards,

SebA

On 3/27/19 3:59 AM, SebA wrote:

Actually, I did use a chart, the same chart that was already logging overall memory use (all processes in aggregate)... The existing memory monitor RRD chart.

I knew WHEN I'd begun use of devmon and until that point it was clear there had been no problem.  Using that chart, while not exact, it was a good indicator of what the rate of change was due to devmon and what interval I might want to use to keep the system functional.

It was already giving me what I needed, a chart of memory use. I did of course have to find WHAT process was causing the issue... And it's clear procmem doesn't do diagnosis, just charts problem activity once identified.

In your scenario, we'd see the issue in the main chart, do the diagnosis, configure procmem, and then collect and chart a separate set of data to reflect ONLY the problem process?  More work for me and additional load on my system. Yes it's small, but, again, why? What is the gain?

In the job that pays my bills, I often encounter people who do very similar things to what you suggested... Monitoring the memory of every process as though it were of free all "costs". And as long as the amount of monitoring isn't too large, it IS effectively free of "cost".  So it works, until it doesn't... Things become slower and slower, system loads go higher and higher and they wonder why.  It becomes like the story of a frog in a pot.  If the water is boiling, it will jump right out...  If the temperature is slowly raised, it will sit there fat, dumb and happy and cook to death.

And now I will return to my original question:

     If you've not used the tools, WHY are they good tools?  To use your own words, "examples of add-ons that cover functionality that SHOULD be considered for merging" to xymon.

I've pointed out why I feel, at least one, does NOT actually add anything but "make work" at both the development level for xymon and for systems admins.  I think we all have more than enough to do. Thats why we use tools like xymon.  To lighten that load.

Plug-ins/extensions work well and have nearly twenty years, why does bloating the core mean better?