On Tue, 26 Mar 2019 at 19:52, John Thurston <user-ce4d79d99bab@xymon.invalid>
wrote:
Does the procmem add-on not work just fine as is?
Is it just the configuration-point which is annoying you?
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.
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
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/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