In the previous article we had a look at extracting status-data from Xymon via the CLI. That status-data represents processed data — like color, status message, IP the message was received from, … This is the data that is (mostly) shown on the status-columns of the web interface.

But there is more: The Xymon clients do send raw data to the server that gets evaluated and processed into the status-data we already know. This raw data can be viewed on the web interface by following the Client data link on the built-in status columns (e.g. disk). This article shows how to query this data from the CLI, similar to the “already processed” status data.

The first lines of the Client data on my test system look like this:

[collector:]
client bb,local.linux linux
[date]
Tue Mar  3 17:16:00 MSK 2015
[uname]
Linux bb 3.2.0-4-amd64 x86_64

The data-format is INI-style for the sections where each section basically contains the output of one command (date, uname, …)1. The contents is generated by the xymonclient-<os>.sh script run periodically by the Xymon client.

We can access that raw data from the CLI with the clientlog (syntax: clientlog HOSTNAME [section=SECTIONNAME[,SECTIONNAME...]]) message:

root@bb:~# /usr/lib/xymon/client/bin/xymon 127.0.0.1 "clientlog bb.local" | head -n5

[collector:]
client bb,local.linux linux
[date]
Tue Mar  3 17:10:59 MSK 2015

Or access one specific section:

root@bb:~# /usr/lib/xymon/client/bin/xymon 127.0.0.1 "clientlog bb.local section=date"
[date]
Tue Mar  3 17:16:00 MSK 2015

This allows to extract data that is not shown by default on the Xymon web interface, e.g.

  • kernel-versions (uname)
  • MAC-addresses (ifconfig)
  • routing table (route)
  • who is logged in (who)

Or generate reports for all — or a group of — hosts with, e.g.

  • OS-type and level from uname and osversion sections
  • used filesystems from mount section
  • running processes (ps), established/listening/waiting connections (ports), …

A Practical Example

We are going to extract the default GW and the corresponding interface for one host. This information is in the [route]-section:

root@bb:~# xymon 127.0.0.1:1984 "clientlog bb.local section=route"
[route]
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.34.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1

The default GW is identified by the destination 0.0.0.0, so we filter for that line and print the 2nd and last field:

root@bb:~# xymon 127.0.0.1:1984 "clientlog bb.local section=route" \
    | grep "^0.0.0.0" | awk '{ print $2, $NF }'
10.0.2.2 eth0

And we are done.

For only one host that report is pretty much useless in most cases. But executed for a bunch of machines we can quickly verify the default GW is configured correctly on all of them.

We do this by combining the above with a xymondboard-query from the previous article to loop over all hosts (only one in case of my test-system)::

root@bb:~# for my_host in $(xymon 127.0.0.1 "xymondboard page= test=info fields=hostname"); do \
    echo -ne "$my_host\t"; \
    echo -n $(xymon 127.0.0.1:1984 "clientlog $my_host section=route" \
        | grep "^0.0.0.0" \
        | awk '{ print $2, $NF }'); \
    echo; \
done
bb.local        10.0.2.2 eth0

Note the trick in the xymondboard-section to generate the list of hosts:

  • The page= filter returns all hosts. Alternatively a host=<hostname-regex> could be used.
  • Filter for test=info: This is a (virtual) test that exists for every host.
  • Only print the hostname field.

The above pipeline might look a bit ugly (after all it is a quick shell one-liner for demo purposes) but you get an idea of the possibilities.


  1. If you wondered about the collector-setion: This is added on the xymon server side by xymond and contains information about the origin of the data and the reported host-class.