[Xymon] Technical questions regarding message flow
jlaidman at rebel-it.com.au
Thu Dec 13 02:54:46 CET 2012
On 12 December 2012 02:17, Michael Beatty <Michael.Beatty at sherwin.com>wrote:
> What does the message look like and how big is it (excluding message
> text) ?
> Is it XML?
No, it's raw text. When you send a status message from the command-line or
in a script, the content of the text is sent to the server. There's no
encoding, no compression, no conversion, no (added) headers, nothing but
what you send. So a shell-based Xymon client clone can be constructed
using telnet like so:
( echo "MSG"; sleep 1 ) | telnet $HOST $PORT
And the message on the wire looks like (depending on the test and message
status the,host,name.conn Thu Dec 25 00:00:01 UTC 2012
In standard Xymon/BB messages, there's no text sent back from the server.
A "central" mode client is different - see later. There are different
message types, which you can read about in the man page for the "xymon"
How is the connection made between the client and host? Are sockets made?
Yes, as per above. Also see other examples:
> How does the server handle large volumes of connections. One thing I have
> read is that any bottle necks will be more likely with disk I/O than
> network traffic, is this fair?
Probably, but I can't comment with any authority. I know that the Xymon
daemon (xymond) keeps a lot of stuff in memory, with periodic snapshots
written to disk, and so this probably improves performance significantly
compared to Big Brother.
> The next part I'm not sure I understand correctly.... The sever then sends
> a response to the client that contains data that instructs the client what
> information it wants next time (this is taken from hosts.cfg?) The client
> then uses this response to determine which information to collect and send
> the next time the client is launched.
There are potentially two parts to the client-server interaction. A client
can have its own "ext" scripts that connect to the server and send an
update on a single client-side test. This is not the default, and would
need to be added on top of a standard Xymon client installation. For
instance, my systems all have checks on the SMART disk status, which can
only be done on the client side, and are not included in the standard
The rest of the data sent to the server are concatenated into one long
"client" message. This is all driven by the "xymonclient.sh" script, which
in turn runs xymonclient-linux.sh (or whichever) and logfetch. The client
connects to the server and sends a client data message looking like so:
client the,host,name.linux linux
Thu Dec 25 00:00:01 UTC 2012
Linux the.host.name 126.96.36.199-1.2.3-smp x86_64
This is exactly what you see when you click on the "Client data available"
link at the bottom of some of the status pages (eg "conn").
Now, if the client is in "local mode", that's the end.
However, in "central mode", the client script wait for Xymon to send back
some logfetch info. This is stored in the temporary logfetch configuration
file, typically /tmp/logfetch.<name of server>.cfg. This contains the
sections of client-local.cfg on the server that are relevant to the client.
You can see the logfetch configuration by catting the temporary file, or
you can fetch it yourself with the following command:
printf "[dummy]\ntesting\n" | $XYMON $XYMSRV 'client/dummyID
Each time the xymonclient.sh script runs, it launches logfetch, which uses
this temporary logfetch configuration to determine what to append to the
client message to be sent back to Xymon. On each run, the configuration
being used is from the last time xymonclient.sh was run, which is why there
is a delay (of 5 to 10 minutes) in changes to client-local.cfg being picked
up on the client.
The client knows nothing of the contents of hosts.cfg. (I think there's a
way it can get it with a "hostinfo" message, but I don't believe any of the
standard client scripts and binaries use this.) The content of the client
message is pretty much governed by the commands in the xymonclient-linux.sh
(or whatever) script, and logwatch and its configuration derived from
> So, aside from the server's ping test, all traffic is initiated by the
Well, aside from the other network tests (ssh, telnet, http, etc) and other
"ext" tests, yes that is correct.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xymon