On 3/1/26 2:13 PM, nor krie wrote:
I absolutely agree with your remarks, Grant. Especially the purple alert for missing data is something that I miss at my current customers Icinga/Nagios implementation a lot (no news are good news does not work for a comprehensive monitoring solution).
I keep threatening to create a new test that is simply a client sending an email through it's usual email chain to a specific recipient email address for Xymon and to configure fetchmail et al. to pull messages from the mailbox and update the new tests status for the client. The idea being when did the client last successfully send an email? Some of the environments I work in have spotty email services for various reasons. So the ability to have an email test for a client go purple if no message has been received in (more than) twice the heartbeat interval would be very nice. -- The purpose for the end-to-end email test is to know that the client can successfully send email. Help thwart the "no news is (NOT) good news" mentality.
Seldom need to touch the clients to change thresholds or add a graph.
Agreed!
This also makes it easy to create individual views for the parties involved. And, this is a huge point in my opinion, evaluate the centrally available data to create all kinds of reports (SLA, management summary reports, capacity analysis, inventory) and insert this into a CMDB. With a working CMDB interconnection it is possible to automate the client rollout in case a new server is added (new entry in CMDB), and then get the inventory information from Xymon about it back into CMDB (hardware, OS, partition scheme, network, even serial numbers and firmware versions and so on). No server will be overlooked and the CMDB is always up-to-date.
I hadn't considered the CMDB linkage. I should spend some time doing so.
(Btw: As feature request: it would be nice to have a RestAPI to get those info from the Xymon server.)
It's not REpresentational State Transfer (REST) per se, but you can get
status out of the server via the xymon client's query and
xymondlog verbs.
From the few times that I've run this in the past, I was able to get the same information that the client sent to server. So it's definitely not in ReST format, but it is data that you should be able to convert to ReST relatively easily. You might even be able to host a ReST API gateway on the Xymon server to convert from Xymon native to ReST for your use case.
xymon.1.html has the following:
... query HOSTNAME.TESTNAME Query the Xymon server for the latest status reported for this particular test. If the host/test status is known, the response is the first line of the status report - the current color will be the first word on the line. Additional lines of text that might be present on the status message cannot be retrieved. ... ... xymondlog HOSTNAME.TESTNAME Retrieve the Xymon status-log for a single test. The first line of the response contains a series of fields separated by a pipe-sign: ... After the first line comes the full status log in plain text format. ...
Glad to see progress in Xymon development! Agreed.
-- Grant. . . .