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

In Checkmk you can monitor your infrastructure in many different ways. Monitoring by means of agents or SNMP are only two of a number of methods. What both have in common is that they only report states as the host sees them from the inside, but you will probably be aware of some services that can only be monitored effectively from the outside. Whether the web server is functioning can still be verified from the inside, but however, the accessibility and response times of the actual user cannot be determined in this way.

Checkmk provides its Active Checks for such situations. These checks allow you to monitor network services directly and conveniently from the outside, and to display the information in your monitoring. Active checks are small programs or scripts that connect to a service in the network or the internet, and then provide the user with the monitoring data. Many of the scripts and programs you will find in Checkmk are originally from Since Checkmk is generally compatible with Nagios, you can also use all of the plug-ins that work under Nagios.

The most important of these programs and scripts are available in Checkmk directly in the web interface. Here is a small selection:

2. Setting up active checks

2.1. Setting up regular active checks

In WATO you can — as already mentioned above — set up the most important and most frequently used checks directly in the web interface. To do this, go to the WATO > Host & Service Parameters entry for Active Checks (HTTP, TCP, etc.). Here you will find the rule sets with which you can set up these checks:

active checks rulesets

Most options in the rule sets are self-explanatory. However if something is unclear you can also refer to the icon help online help for explanations of the many options.

2.2. Assigning Active Checks to a host

For some rules, it is necessary to specify an IP address or host name in the options. In many places it is possible to leave this option empty, so that the host name or the IP is adopted of the hosts for which this rule applies. In this way you can easily use just one rule to provide a whole group of hosts with an active check. Therefore always make sure — also with the aid of the already-mentioned icon help online help — whether this option is available in the specific rule set. You may thus save yourself a lot of configuration work.

Here is an example using the HTTP check: Let’s assume you want to monitor the validity of the certificates for all of the web servers in your infrastructure, but do not want to create dozens or even hundreds of rules:

active checks http conf

To accomplish this with a single rule, first think about how best to fill the Conditions. In the following example we use the function of labels. In our case, we have previously set the label webprotocol:https for all our web servers. Using this label we can now create a rule and set the Conditions to this label:

active checks http conditions

After you have activated the rule you have just created, search in the Quicksearch for the service name Certificate. In the following example the label has been set on four hosts. In the Status Details you can then actually see that several websites were checked, because the expiration dates of their certificates are slightly different:

active checks http services

Important: Note that for active checks, not only the first rule to which the conditions apply is evaluated, but rather all rules for which the conditions for a host apply! Only in this way is it possible to set up multiple services on one host.

2.3. Integrating other Nagios-compatible plug-ins

Not only the active checks which you can find as rule sets in the web interface are available to you in Checkmk of course. In addition to these check plug-ins, you will find many more in your instance. To simplify the example overview here, only selected relevant lines are displayed in the following sample output:

OMD[mysite]:~$ ll ~/lib/nagios/plugins/
total 2466
-rwxr-xr-x 1 root root   56856 Feb  3 00:45 check_dig
-rwxr-xr-x 1 root root    6396 Feb  3 00:45 check_flexlm
-rwxr-xr-x 1 root root    6922 Feb  3 00:45 check_ircd
-rwxr-xr-x 1 root root   60984 Feb  3 00:45 check_ntp_peer
-rwxr-xr-x 1 root root   78136 Feb  3 00:45 check_snmp

Each of these check plug-ins also offers a help option (-h), which allows you to learn more about how to use the respective plug-in without having to visit the monitoring-plugins website.

Checkmk offers the special rule set Classical active and passive monitoring checks to make these plug-ins convenient to use. The two most important options here are the specification of a service description and a command line. The latter can be written as if you are already in the correct directory:

active checks custom config

Note that the above-mentioned macros, such as $HOSTNAME$ or $HOSTADDRESS$ are also available here. A list of all of the available macros can be found as always in the icon help online help. After you have activated the changes, you can see the new service on the assigned host:

active checks custom service01

Using your own plug-ins

In some cases, you will have already written your own plug-ins and now want to use them in Checkmk. In this case the procedure is largely identical. The only requirement is that the plug-in is compatible with Nagios. This includes a single line output with the details of the status and an exit code describing the status. This must be 0 for OK, 1 for WARN, 2 for CRIT or 3 for UNKNOWN. A short example to illustrate the very simple to understand syntax can be found here:

echo "I am a self written check and I feel well."
exit 0

Place the plug-in in your instance’s local file path:

OMD[mysite]:~$ cp ~/local/lib/nagios/plugins/

And then make the script executable:

OMD[mysite]:~$ chmod 755 ~/local/lib/nagios/plugins/

The rest of the procedure is then identical to other plug-ins which are created via the Classical active and passive monitoring checks rule set, so that you can see the new service at the end:

active checks custom service02

3. Special features of active checks

Services that were created by active checks behave differently in some respects than other services. So the services of an active check…​

  • …​ continue to be checked even if a host is DOWN.

  • …​ execute independently of other (passive) services. This also allows you to set your own interval.

  • …​ are always executed by the Checkmk instance’s server. Exceptions are MRPEs, which are executed directly on a host.

  • …​ are not incorporated via Service Discovery, but are generated automatically.

4. Running Active Checks on a host (MRPE)

To run a classic Nagios plug-in on a host being monitored, we provide MK’s Remote Plugin Executor (abbreviated: MRPE). Depending on whether you want to run such a plug-in on a unix-like system or on a Windows system, place it in the appropriate location in the respective agent’s installation directory. In addition you will need a configuration file that determines how the plug-in is to be executed, and what the specific command line for the call looks like.

Detailed instructions can be found in the respective articles on Windows and Linux.

5. Files and directories



Here you will find all plug-ins that are delivered with Checkmk. No distinction is made between plug-ins that are written by and those that are written specifically for Checkmk.


You can store your own plug-ins here. They are then dynamically read in, and will also survive an update of the Checkmk instance.

On this page