[Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?)

[Adam Thorn]

On 17/08/2023 19:21, J.C. Cleaver wrote:

> As it currently stands, xymon is already very efficient, so it's worth
> pointing out that the complexity really doesn't have to come in until you
> start hitting things at scale. If you're on a modern core and handling 90
> msg/s, xymond is going to be just fine. If you're trying to push 9000
> msg/s, more needs to be taken into consideration.

We see about ~100 msgs / second and CPU load on xymond has never even 
crossed our radar (we run xymond on a relatively low-spec VM with a 
single virtual CPU)

The place where we have historically encountered performance-related 
issues was writing data to rrd files. We have a lot of custom tests and 
like being able to store and graph numerical data. My colleague thus 
implemented a custom xymond_channel listener which lets us take all our 
custom messages that come in a whole range of different formats, parse 
the messages to extract the numerical fields we're interested in, and 
then store them in a postgresql backend database rather than rrd files. 
This did also mean a moderate amount of custom development work for the 
web frontend (including some external js libs to draw graphs) to extract 
the data from the backend.

That wouldn't have been possible without the xymond_channel architecture 
along with the simple and well-defined format of the xymon messages 
themselves.

Adam