This article does not yet show and describe the graphical user interface of Checkmk version 2.0.0. We will update this article as soon as possible.

1. Introduction

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:

agent access


Checkmk accesses the target device’s existing SNMP-agent. With active queries (GET) it collects details on the system’s condition.

SNMP-Agent enabled


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.

Checkmk-Agent installed

Special Agent

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

Active Checks

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, check_http is very popular for querying websites. These are described as Active Checks.


1.1. Monitoring by events

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.

2. The Checkmk agent

2.1. Download and installation

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.

2.2. Installation via the download page

The agents are accessed via the WATO-module icon agents Monitoring agents. In the Enterprise Editions, you will be brought to the Agent bakery. From there the icon agents 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:

agent download

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.

2.3. Details of agents for specific operating systems

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

3. Installation via the Agent Bakery

3.1. Introduction

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)

CEE If you have one of the CEE 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 > icon agents Monitoring agents:

agent bakery main

If you have not yet made settings for specific hosts, there is only a single default agent configuration. With the Bakery Checkmk 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 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.

3.2. Configuration via Rules

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 button rules Rules button you can access a page which lists all rule sets that affect the agents:

agent rules

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:

agent rule ipaccess

After saving with button monitoring agents, return to the Agent Bakery. The button bake agents button ensures that the agent will be freshly baked. The result — you now have two configurations:

agent bakery agentlist

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 button monitoring agent Monitoring Agent button:

download host agent

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.

3.3. Plug-ins

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:

agent rule mysql

3.4. Customising agents manually

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.

4. When should an agent be updated?

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 CEE 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: newer versions of Checkmk can fundamentally handle the output of older agents.

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):

crashed check

5. Error diagnosis

5.1. Testing agents via the command line

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:

OMD[mysite]:~$ telnet 6556
Connected to
Escape character is '^]'.
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

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:

OMD[mysite]:~$ nc 6556
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 <<< 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 via WATO, allows for a possibly reconfigured port number, and also the case of a special agent:

OMD[mysite]:~$ cmk -d myhost123
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 tmp/check_mk/cache directory:

OMD[mysite]:~$ cat tmp/check_mk/cache/myhost123
Version: 1.6.0

5.2. Diagnosis via the GUI

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 icon diagnose Diagnostic button in WATO:

host diag

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

On this page