Monitoring agents

Until now we have only discussed active monitoring — Checkmk’s showpiece discipline. There is also the reverse method: namely that by which the target system itself sends messages to the monitoring, e.g., via syslog or SNMP traps. For these functions Checkmk has the Event Console which is described in its own article.

The agents’ structure, configuration and capabilities vary depending on the operating system. For this reason, details on the agents for Linux and Windows can be found in their own articles.

While it is true that the Checkmk agent can function ‘naked’ immediately — without needing configuration, and without plug-ins — nonetheless in some cases the agent does need to be set up. Some examples:

If you have one of the Checkmk Enterprise Editions you can package personalised agents with the Agent Bakery. In this way, alongside the existing agents, you can also create agent packages that contain configurations and extra plug-ins. You can install these packages with a single command. These packages are ideal for automatic distribution and installation. You can even create personalized agents for specific groups of hosts. This allows great flexibility through the use of the automatic agent updates.

You can reach the Agent Bakery via Setup > Agents > Windows, Linux, Solaris, AIX:

If you have not yet made settings for specific hosts, there is only a single default agent configuration. Checkmk supports the Windows, Linux, Solaris and AIX operating systems. For Linux you have a choice between the package formats RPM (for Red Hat, CentOS, SLES), and DEB (for Debian, Ubuntu), as well as a so-called 'tarball' that is simply unpacked as root under /. Likewise, a tarball is available for AIX, however this does not include automatic integration into the inetd. The integration must be performed manually as a one-off action. For Solaris there is again the tarball and a PKG package.

Every agent configuration has an explicit ID: its hash. A hash’s first eight characters are displayed in the GUI. This hash will be a part of the package version and embedded in its file name. Whenever you change something in a package’s configuration or update Checkmk, the package’s hash will also be changed. In this way the operating system’s package manager recognizes that it is an update. Checkmk’s version number would not suffice in such a case.

The agent’s configuration can be altered — as is so often the case in Checkmk — via rules. These offer you the possibility of equipping different hosts with differing settings or plug-ins.

The Agent rules button takes you to a page which lists all of the rule sets that affect the agents:

Let’s take the following example: you wish to limit the list of IP addresses that are permitted to access the agent. For this you select the Generic Options > Allowed agent access via IP address (Linux, Windows) rule set. Enter one or more IP adresses as the rule’s value:

After saving, go back to the Windows, Linux, Solaris, AIX page. The button ensures that the agent will be freshly-baked. The result — you now have two individual configurations:

In the Hosts column you will find a list of hosts associated with the relevant configuration. For space reasons this list may not be complete. The VANILLA and GENERIC names have a special role. These two pseudo-hosts are always present and have the following functions:

The more host-specific rules you deploy, the more different versions of agents will be built. The Agent Bakery makes sure that only such combinations of configurations are built that will be used by at least one of the available hosts.

By the way, you can also reach a host’s agent packages conveniently via the host’s properties by clicking on the host in Setup > Hosts > Hosts and selecting the entry Monitoring Agent in the Hosts menu:

Why are packages for all operating systems offered for every host? The answer is very simple: if no agent is installed on a system Checkmk naturally cannot recognise the operating system! In any case, once automatic agent updates are activated you don’t need to do anything more.

Many rules are concerned with the installation of various plug-ins. These extend the agents for the monitoring of quite specific components. Most of these are special applications such as databases, for example. Alongside the rule that activates a plug-in you will also find the settings for configuring the plug-in. Here, for example, is the rule for monitoring MySQL:

Please note that on the target system you do not manually modify the configuration files of an agent that was created by the Agent Bakery. This will work at first, but the next update of the agent will cause the changes to be lost. However it is possible to install additional plug-ins and configuration files without problems.

Although the agents for the various operating systems were independently developed, from Checkmk’s point of view they all behave in the same way by opening the TCP port 6556 for queries from the monitoring server. The query protocol is absolutely simple: the server connects to the port and the data flows in a readable text format from the agent. As soon as the data transfer is completed the agent disconnects itself from the port. The agent basically reads no data from the network!

A correctly-installed agent can be very easily queried from the command line. The best way to do this is directly from the Checkmk site that is also actively monitoring the agent. In this way you can be certain that the server’s IP address will be accepted by agents. A suitable command is e.g. telnet:

With nc or netcat the data is returned ‘naked’. This is useful for example, if you wish to use a script to process the data:

The output always begins with the line <<<check_mk>>>. Lines included in <<< and >>> are called section headers. These divide the agent output into sections. Each section contains related information and is usually simply the output from a diagnosis command. The check_mk section plays a special role. It contains general information about the agent such as e.g., its version number.

If the host is already being monitored you can also fetch the data with the cmk -d command. This uses the IP address configured in the Setup, allows for a possibly reconfigured port number, and also for any special agent that may be present:

If monitoring is already running regularly for the host in question a current copy of the output can always be found in the tmp/check_mk/cache directory:

You can also conduct a diagnosis of the agents via the web interface. This takes all settings into consideration and also supports SNMP devices and those queried using special agents. In effect, Checkmk simply attempts to always query via TCP port 6556 and SNMP simultaneously. You can access the connection test via the properties of the host: On the Properties of host page, select Hosts > Connection tests from the menu, and start the test by clicking Run tests:

You can try out quite a few of the settings (e.g., the SNMP community) right away, and save them when successful.