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 monitoring-plugins.org. Since Checkmk is generally compatible with Nagios, you can also use all of the plug-ins that work under Nagios.
When you integrate such plug-ins, keep in mind the main purpose of active checks — in terms of end-to-end monitoring, they are supposed to check the accessibility, response time, or response status of a network-accessible service on the monitored host. Checkmk offers a range of efficient checks for many other monitoring tasks. You can find an overview in the article Developing extensions for Checkmk.
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 the Setup you can — as already mentioned above — set up the most important and most frequently used checks directly in the web interface. To do this, open Setup > Services > HTTP, TCP, Email. Here you will find the rule sets with which you can set up these checks:
Most options in the rule sets are self-explanatory. However if something is unclear you can also refer to the inline 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 blank so that the host name or its IP is used. 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 inline help — whether this option is available in the specific rule set. You may thus save yourself a lot of configuration work.
Check HTTP web service is a check that is frequently used to monitor many parameters of web servers, such as certificate validity, response time, response code or the search for character strings in delivered web pages. You can find this check under Networking > Check HTTP web service. Let’s assume you want to monitor the validity of the certificates of all web servers in your infrastructure, ensure response times of less than one second and a status code of 200, but do not want to create dozens or even hundreds of rules for this:
 |
Why, with Check certificates, is there another active check for certificates? The aforementioned Check HTTP web service check always performs one complete HTTP request, which limits its use to web servers. On the other hand, its execution is very efficient; it can perform a series of checks with just a single HTTP request. In comparison, Check certificates only checks the TLS connection setup and the certificates. This check can therefore also be applied to other services secured with TLS, such as IMAP/S. It can also examine certificates in much greater detail, for example for specific host names stored via Server Name Indication (SNI). |
To apply the just configured check to all suitable hosts with a single rule, first think about the best way to fill the Conditions.
In the following example, we use the Labels function and add the webprotocol:https label to all of our web servers.
With such a label, you can create a rule and set the Conditions to this label:
Once you have activated the rule you have just created, search in the Monitor menu for the Basic webserver health service name that you have just defined.
In the following example, you can see the hosts for which the label has been applied accordingly.
Important: Note that for the active checks, not only the first rule to which the conditions apply is evaluated, but also all rules in which the conditions for a host apply. This is the only way to create multiple active services on a 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 site. To simplify the example of an overview shown here, only selected 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_snmpEach 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.org website.
In Setup > Services > Other services Checkmk offers the special rule set Integrate Nagios plugins 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:
Note that the macros shown above, such as $HOSTNAME$ or $HOSTADDRESS$, are also available here.
A list of all of the available macros can be found as always in the inline help.
After activating the changes, you can see the new service on the assigned host:
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 syntax shows the following script that you can create e.g. in the ~/tmp subdirectory of the site directory:
#!/bin/bash
echo "I am a self written check and I feel well."
exit 0With a single action place the plug-in in the local file path for your site and make it executable:
OMD[mysite]:~$ install -m755 ~/tmp/myscript.sh ~/local/lib/nagios/plugins/The rest of the procedure is then identical to other plug-ins which are created via the Integrate Nagios plugins rule set, so that you can see the new service at the end:
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 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)
Suppose you are monitoring a host A (e.g. a web server) from your Checkmk site, which in turn accesses services from host B (e.g. a database). Monitoring the services on host B directly from the Checkmk site will most likely be corrupted by other packet run times, etc., and therefore will not give any accurate indication of how the accessibility from host A behaves in operation. Here it is convenient to have a Nagios plug-in run from the agent of the monitored host (here A), which directly checks the services on host B.
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-type 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.
5. Files and directories
| File path | Description |
|---|---|
|
Here you will find all plug-ins that are delivered with Checkmk. No distinction is made between plug-ins that are written by monitoring-plugins.org 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 site. |