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

[SebA]

On Tue, 26 Mar 2019 at 19:52, John Thurston <john.thurston at alaska.gov>
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    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:
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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190326/9416b77c/attachment.html>