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. . . .
_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com