Am So., 1. März 2026 um 22:56 Uhr schrieb Grant Taylor via Xymon < xymon@xymon.com>:
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.
This will not work in most of my environments as either there is no mail configured or the xymon user is not allowed to send them.
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
xymonclient'squeryandxymondlogverbs.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. ...
Yes, I know about this and use it heavily for my custom inventory and reporting scripts. But this works only at the Xymon server and is dependend from its binaries. The ability to get those infos by a standardized API from extern would be helpful to connect Xymon with other management tools (and would increase the acceptance of Xymon imo). But this is not of high prio from my side as I am fine with my current solutions.
Glad to see progress in Xymon development! Agreed.
-- Grant. . . .
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com