For a monitoring system to receive more information from an endpoint other than that it is accessible, help is required from the target system. For example — how else can Checkmk know how full a server’s storage volume is without that system somehow providing the information? The component that provides this information is always an active piece of software — namely an agent.
There are situations where one does not need to install an additional agent — since one that can be used is already present. The best example here is SNMP. All manageable network devices and appliances have a built-in SNMP agent.
As always, there is an exception: the monitoring of network services. For example — by its nature a web application can be accessed via HTTP and be monitored over the same connection. But even in this case there is usually an additional agent in use which provides further server data to the monitoring.
The following table shows the four different ways that Checkmk can access services to be monitored:
Checkmk accesses the target device’s existing SNMP-agent. With active queries (GET) it collects details on the system’s condition.
Checkmk has its own agents for servers and workstations. Eleven different operating systems are supported — from the commonplace like Windows and Linux to exotics such as OpenVMS. The agents are passive and connect to TCP Port 6556. Only on receiving a Checkmk server query will they be activated and respond with the required data.
Some systems allow neither an agent installation, nor do they support SNMP in a usable form. Instead of these they offer Management-APIs based on TELNET, SSH or HTTP/XML. Checkmk queries these interfaces via special agents that run on the Checkmk-Server
Create an API account for Checkmk
Network-based services such as HTTP, SMTP or IMAP can by their very nature be queried via the network. For this Checkmk sometimes uses its own, sometimes existing plug-ins originally developed for Nagios. For example,
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 this entire subject Checkmk has the Event console which is described in its own article.
As described, you require a Checkmk agent in order to monitor servers and workstations. Agents for eleven different operating system families are currently maintained in the Checkmk-Project. All of these agents are components in Checkmk, and are available for downloading via the Checkmk-Server’s Web-GUI. Additionally, in the Enterprise Editions there is the Agent Bakery. This enables you to ‘bake’ your own agents containing a personalised configuration and collection of plug-ins. This can even be done individually and differently for each host.
The agents are accessed via the WATO-module Monitoring agents. In the Enterprise Editions, you will be brought to the Agent bakery. From there the Agent files button then takes you to the download page for the agents and their plug-ins. The Raw Edition takes you directly to the download page:
The packeting agents for Windows (
check_mk_agent.msi) and Linux
.deb or `.rpm`u files) are found right in the first section.
After installing these packages the agent is basically ready to run,
and you can begin monitoring. All further configuration is achieved via
configurations data, and plug-ins are installed by downloading them from
the same page and copying them into the appropriate folder.
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:
Restriction of access to specific IP-Addresses
Monitoring of ORACLE data bases (plug-in and configuration are required)
Monitoring of text log files (plug-in, data names and text-pattern required)
Utilization of the Checkmk inventory system (plug-in required)
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. These packages are ideal for automatic-distribution, however, they can also be installed manually. You can even create personalized agents for specific groups of hosts. This allows great flexibility through the use of the automated agent deployment.
The bakery is accessed via WATO ⇒ Monitoring agents:
If you have not yet made settings for specific hosts, there is only a single
default agent configuration. With the Bakery
Checkmk version VERSION[1.6.0] supports the Windows, Linux, Solaris and AIX
operating systems. For Linux you have a choice between the packet formats RPM
(SUSE, RedHat, CentOS), and DEB (Debian, Ubuntu), as well as a tarball that
is simply unpacked as
/. Likewise, a tarball
is available for AIX, however this does not include automatic integration into the
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. Via the Rules button you can access a page which lists all rule sets that affect the agents:
Let’s take the following example: you wish to limit the list of IP Adresses that are permitted to access the agent. For this you select the Generic Options ⇒ Allowed agent access via IP address rules set. Enter one or more IP adresses as the rule’s value:
After saving with , return to the Agent Bakery. The button ensures that the agent will be freshly baked. The result — you now have two configurations:
In the Hosts column you will find a list of hosts associated with the relevant configuration. For space reasons the full list is abbreviated here. The VANILLA and GENERIC names have a special role. These two pseudo-hosts are always present and have the following functions:
A virtual host whose agent contains only the default configuration, to which therefore none of the agent rules apply.
A virtual host to which ALL rules with no defined additional conditions apply. The GENERIC entry is especially useful for installing agents on hosts that have not yet been incorporated in the monitoring.
The more host-specific rules you deploy, the more different versions of agents will be built. The 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, in WATO you can also easily access a host’s agent packages via the host’s Details and the Monitoring Agent button:
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 data bases, 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 Bakery. This will work at first, but the next update of the agent will cause the the changes to be lost. However it is possible to install additional plug-ins without problems.
Regardless of whether you monitor only a handful — or even thousands of hosts — management of the Checkmk agents on all hosts is always a larger operation. The automatic update of the agents in the Checkmk Enterprise Editions is however a big help. Nonetheless, you should really only update the agents when:
the update solves a problem affecting you, or
the update includes required new functions.
In order for this to be possible a general rule applies in Checkmk: <b>newer Checkmk-versions can fundamentally handle the output of older agents</b>.
Note: the reverse is not necessarily true. If an agent’s Checkmk version is newer than that of the monitoring server it is possible that the output of the target agent’s existing check plug-ins cannot be properly interpreted. In such a case the affected services go into an UNKNOWN (please do not send a Crash-report in such a situation):
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 is directly from the Checkmk instance 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 10.1.1.2 6556 Trying 10.1.1.2... Connected to 10.1.1.2. Escape character is '^]'. <<<check_mk>>> Version: 1.6.0 AgentOS: linux AgentDirectory: /etc/check_mk DataDirectory: /var/lib/check_mk_agent SpoolDirectory: /var/lib/check_mk_agent/spool PluginsDirectory: /usr/lib/check_mk_agent/plugins
netcat the data is returned ‘naked’. This is
useful for example, if you wish to use a script to process the data:
nc 10.1.1.2 6556 <<<check_mk>>> Version: 1.6.0 AgentOS: linux AgentDirectory: /etc/check_mk DataDirectory: /var/lib/check_mk_agent SpoolDirectory: /var/lib/check_mk_agent/spool PluginsDirectory: /usr/lib/check_mk_agent/plugins
The output always begins with the line
<[check_mk]>. Lines included in
>>> 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
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 via WATO, allows
for a possibly reconfigured port number, and also the case of a special agent:
cmk -d myhost123 <<<check_mk>>> Version: 1.6.0
If monitoring is already running regularly for the host in question a current
copy of the output can always be found in the
cat tmp/check_mk/cache/myhost123 <<<check_mk>>> Version: 1.6.0
You can also conduct a diagnosis of the agents via the GUI. 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 details of a host’s diagnosis with the Diagnostic button in WATO:
You can try out quite a few of the settings (e.g., the SNMP community) right away, and save them when successful.