<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 3/27/19 3:59 AM, SebA wrote:<br>
<blockquote type="cite"
cite="mid:CAOGA4509J1HDhZdY-wh3C-M9h4AtLHgc9idHZi+ME5p2oKxeHw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2019 at
23:15, Bruce Ferrell <<a
href="mailto:bferrell@baywinds.org" moz-do-not-send="true">bferrell@baywinds.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 3/26/19 11:49 AM, SebA
wrote:<br>
> 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.<br>
><br>
> 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 <br>
> certain processes):<br>
> <a href="http://tools.rebel-it.com.au/xymon-procmem/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://tools.rebel-it.com.au/xymon-procmem/</a><br>
> 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.<br>
><br>
> Another example is Xymondash:<br>
> <a href="https://github.com/daduke/Xymondash"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/daduke/Xymondash</a><br>
> 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 <br>
> 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?<br>
> It would be good to be able to present a more modern
GUI as part of Xymon.<br>
><br>
> Kind regards,<br>
><br>
> SebA<br>
><br>
<br>
If you've not tested the functionality, why on earth would
you think it should be merged? *just* because it's JS/JSON?<br>
</blockquote>
<div> </div>
<div>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.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
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 <br>
process that needs fixing? Ya know, memory leaks ARE kind of
considered very to be bad form, or maybe that's just me.<br>
</blockquote>
<div><br>
</div>
<div>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?<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
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 <br>
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 <br>
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 <br>
do they start falling off.<br>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<div>
<br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr"><span>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div style="text-align:left"><span
style="font-size:12px"><span
style="font-family:arial,helvetica,sans-serif">Kind
regards,<br>
<br>
SebA<br>
</span></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</span></div>
</div>
</div>
<br>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
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.
<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
And now I will return to my original question:<br>
<br>
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. <br>
<br>
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. <br>
<br>
Plug-ins/extensions work well and have nearly twenty years, why does
bloating the core mean better?<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>