Thank you for Xymon software and to the Xymon community.
I wanted to send a quick note saying that a month doesn't go by, sometimes not even a week, I think to my self or slip and say "but Xymon does that" when asking why some other monitoring solution doesn't catch something that seems trivial.
The list of things that Xymon detects that other solutions have failed to detect:
- incorrect time - CPU test
- lack of reports a la. PURPLE
- TLS certificate expiration - sslcert
- HTTP reply status codes - http
I'm sure there are many other things that have made me mumble to myself.
Yes, I know that other things can be configured to monitor some or all of these things, but that requires additional effort. Conversely Xymon just does it with no more effort than configuring it to look at a port.
But the incorrect time has been a BIG problem for many of of the other monitoring solutions that my employer uses.
Xymon has made it extremely easy to monitor these things and has proven to be EXTREMELY useful.
Thank you.
-- Grant. . . .
Yes,
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). But I want to add the huge advantage of the Xymon philosophy to collect a lot of data at low level (small client, limited client permissions needed, mostly out-of-the-box tools used) and do all the evaluation at the server side. So all the information is available for further evaluation at the Xymon server. Seldom need to touch the clients to change thresholds or add a graph. 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. (Btw: As feature request: it would be nice to have a RestAPI to get those info from the Xymon server.)
Glad to see progress in Xymon development!
Norbert
Am So., 1. März 2026 um 19:11 Uhr schrieb Grant Taylor via Xymon < xymon@xymon.com>:
Thank you for Xymon software and to the Xymon community.
I wanted to send a quick note saying that a month doesn't go by, sometimes not even a week, I think to my self or slip and say "but Xymon does that" when asking why some other monitoring solution doesn't catch something that seems trivial.
The list of things that Xymon detects that other solutions have failed to detect:
- incorrect time - CPU test
- lack of reports a la. PURPLE
- TLS certificate expiration - sslcert
- HTTP reply status codes - http
I'm sure there are many other things that have made me mumble to myself.
Yes, I know that other things can be configured to monitor some or all of these things, but that requires additional effort. Conversely Xymon just does it with no more effort than configuring it to look at a port.
But the incorrect time has been a BIG problem for many of of the other monitoring solutions that my employer uses.
Xymon has made it extremely easy to monitor these things and has proven to be EXTREMELY useful.
Thank you.
-- Grant. . . .
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@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.
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. . . .
On 3/1/26 3:56 PM, Grant Taylor via Xymon wrote:
xymon.1.html has the following:
Norbert, you might want to check out the following, especially if you are wanting to gateway to ReST API data:
/path/to/xymon ${XYMON_HOST} "xymondxlog host.name.test"
I had used query and xymondlog in the past. But I suspect that I'll
be using xymondxlog in the future as I'm doing more with XML+XSLT.
-- Grant. . . .
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
On 3/2/26 2:42 AM, nor krie wrote:
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.
ACK
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.
My first hand experience questions the veracity of that statement.
I've been able to collect the data from other Xymon clients in addition to just the Xymon server.
I also question if the Xymon client command is actually needed. Looking at tcpdump, it seems like it's basically just text that's sent via a TCP connection.
I strongly suspect you can retrieve data using the same method as you can send status updates without the Xymon commands; e.g. telnet / raw TCP connection. -- I don't have time to get to poke this at the moment.
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.
I think you can get the information in a standard way. It's just not the standard that I think you're referring to.
Obligatory xkcd:
Link - xkcd: Standards
-- Grant. . . . unix || die
participants (2)
-
Grant Taylor
-
nor krie