[Xymon] Merging some add-ons into Xymon source code
spah at syntec.co.uk
Tue Mar 26 21:37:07 CET 2019
On Tue, 26 Mar 2019 at 19:52, John Thurston <john.thurston at alaska.gov>
> 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.
> 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
Those were just 2 semi-random examples, another is probably calculation of
CPU load thresholds based off the number of reported processors:
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.)
> 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
> > Kind regards,
> > SebA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xymon