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