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