Simple Xymon Monitors Hosts, Services, and Network

With Xymon, you can monitor the health of thousands of servers and applications, and the network connectivity among them. Xymon presents its results in an intuitive way, which simplifies life for data center operations staff. Formerly known as Hobbit Monitor, Xymon is inspired by the monitoring tool Big Brother, but that older application is based on shell scripts and lacks a centralized location for storing configurations. Xymon, by contrast, stores its configuration information on a single Xymon server, which makes it more manageable.

You can't get Xymon from your base repository or Extra Packages for Enterprise Linux (EPEL) repository, but the project maintains its own repo. You should be able to install the software from an RPM file that you can download from that repository, but I suggest that you download and build the RPM for your server by yourself, since the RPMs do not say that they are suited for both Enterprise Linux versions 5 and 6. Follow these steps to do so:

1. Download the latest source RPM.

1. Install the rpm-build and rpmdevtools utilities with the command # yum install rpm-build rpmdevtools.

1. Set up the RPM building directory structure by running the command $ rpmdev-setuptree. This command also creates a chroot environment, which protects your system environment from getting polluted by anything that happens in the build you do. It is also good practice to build packages in a clean chroot environment, since that can make package builds more reliable.

1. Copy the downloaded Xymon SRPM package into SRPM directory, then install it in the chroot environment with the command $ rpm -ivh xymon-4.3.7-8.src.rpm.

1. Build the package for your server with the command $ rpmbuild -ba SPEC/xymon.spec

Once you have the RPM file, do a yum install with the full path of the RPM to install your Xymon server.

Xymon Configuration Files

Several config files in /etc/xymon control Xymon configuration:

• xymonserver.cfg defines a lot of environment variables for Xymon – things like your server's IP address and hostname and the location of other files. The defaults should work just fine.

• hosts.cfg contains all the hosts you want to monitor defined as IP address / hostname pairs similar to the structure of /etc/hosts file, as well as network services and URLs. You can define page, subpages, and groups to classify hosts into categories. Such groupings can be helpful if you have a large number of servers to monitor; you can keep an eye on them by category or give responsibility for monitoring separate pages to separate teams or individuals.

• alerts.cfg states who should receive alerts if any of the monitored services goes critical. The recipient can be an email ID or a script that can send SMS or voice alerts.

• tasks.cfg loads and controls the Xymon modules that provide the application's functions, and optional monitoring add-ons. It defines the frequency and parameters of the modules. Some of the programs may be run as daemons while others will be executed at regular intervals. For instance, to monitor NTP, the settings below will be executed every five minutes to run a script:
  [ntpstat]ENVFILE /etc/xymon-client/xymonclient.cfg
  CMD /my-scripts/ntpstat.sh
  LOGFILE /var/log/xymon/ntpstat.log
  INTERVAL 5m
  For an extensive list of example you can check the tasks.cfg defined at xymon.com.

• analysis.cfg: Data reported by Xymon clients is formatted in accordance with this config file, which defines the colors for the cpu, disk, memory, and procs columns.

• graphs.cfg: showgraph CGI generates graphs from RRD files based on the monitoring data Xymon collects on the basis of the definitions in this file.

• rrddefinitions.cfg defines the datapoint stores that Xymon receives from the clients. Configuration settings here are applied to new RRD files only; to change existing ones, you need to go to the traditional route and use RRDtool.

• protocols.cfg files defines how Xymon tests TCP and network services.

Monitoring Xymon Server Using Xymon Server

Let's edit some configuration files to get Xymon going with a bare minimum setup that monitors the software's own server. Open xymonserver.cfg and edit the following variables:
XYMONSERVERHOSTNAME: Define the hostname of the server here.
XYMONSERVERIP: Define the host IP address here. This address should be accessible to the operations team.
XYMONSERVERWWWNAME: Define here the name used for the web server, such as monitor.my-org.com.
Save the file, then open hosts.cfg and edit it to add the IP address and hostname of the Xymon server. Finally, start the Xymon server with the command # service xymon start. If you want to make sure that the daemon starts every time after reboot, switch it on with the command # chkconfig xymon on.

Once you have the service running, you can see the results it collects by keeping an eye on Xymon home page on the server. Xymon uses standard htpasswd for user authentication.

Of course monitoring a single server is far beneath all the Xymon can do. Its strength comes when you use it to monitor many remote hosts and services. To do so, first install the Xymon client on the remote host with the command # yum install xymon-client. Edit /etc/xymon-client/xymonclient.cfg on the remote host and specify the IP address of the Xymon server in the variables XYMSRV and XYMSERVERS. At the Xymon server, edit hosts.cfg to include the IP address and hostname of the remote server. Xymon will then begin monitoring the remote server after an interval that depends on the checks which are applied, but which is generally less than a couple of minutes.

Because monitoring a lot of hosts can be overwhelming, you can split the list of hosts into pages and subpages. Xymon gives you the option to define a critical system view where you can define which tests on which hosts need extra attention, which makes it easier to see potential problems that you might have to escalate in the middle of the night.

Xymon vs. Nagios and Big Brother

Xymon isn't the only enterprise monitoring application available, or even the most popular, but it offers administrators some useful features. One of Xymon's most significant advantages is that you can pass a lot of information with the status message. Nagios, a mostly comparable network monitoring application, is limited in the sense that you can pass on only a short message that states the status of a monitored application, although you can do more if you use Nagios plugins. Additionally, Xymon is easier to configure than Nagios because the Xymon client does a lot of work for you out of the box. Starting up Xymon get you several common checks, such as disk, CPU, and memory, that you have to set up yourself with Nagios. Xymon also supports IP SLA reports out of the box, while Nagios requires a plugin for that task. Writing custom plugins is similar for both products.

In contrast to the application that inspired it, Xymon is easier to build and install than Big Brother. Configuration files are portable and need only minor modification across hosts. Most configuration is done on server, unlike with Big Brother, where you need to install scripts on each host. Xymon's performance is much better than Big Brother's in terms of system and CPU load. And unlike Big Brother, Xymon provides trend graphs, which are helpful to visualize historic data.

Of course we've barely scratched the surface of all that Xymon can do. As you try to implement more sophisticated configurations, check out Xymon help for assistance. You're likely to find Xymon to be a useful tool for monitoring static physical and virtual machines.

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.