1. Introduction
In our Beginner’s Guide, we showed you how to lay the groundwork for monitoring the Checkmk server. The following article is now about filling this monitoring with meaningful content. After all, Checkmk can not only check whether the Checkmk server is running, but there are many more parameters that can be checked—and subsequently optimized.
2. Process discovery
In process discovery, for example, there are predefined rules for specific services for self-monitoring. You can access these via Setup > Services > Discovery rules > Discovery of individual services > Process discovery.
For each host that has the cmk/check_mk_server:yes host feature, the following services will be automatically found thanks to the rules provided:
Process myhost active check helpers
Process myhost agent receiver
Process myhost alert helper
Process myhost apache
Process myhost automation helpers
Process myhost checker helpers
Process myhost cmc
Process myhost dcd
Process myhost event console
Process myhost fetcher helpers
Process myhost jaeger
(not permanently visible)Process myhost livestatus proxy
Process myhost notification spooler
Process myhost notify helper
Process myhost piggyback hub
(not permanently visible)Process myhost rabbitmq
(only when piggyback hub is enabled)Process myhost real-time helper
(only when real-time checks are enabled)Process myhost redis-server
Process myhost rrd helper
Process myhost rrdcached
You can either deactivate or delete any rules that you do not need. We recommend deactivating rules that you do not need, especially if you do not want to use any of those rules. This is because if you delete all rules instead of just deactivating them, all rules will be recreated the next time you import a Checkmk patch.
To learn what you can do with these services, read the article Understanding and configuring services. To find out exactly what the processes included in monitoring as services do, read the article on Site services.
3. Self-monitoring of the system (plugs-ins)
The catalog of check plug-ins also offers various options for self-monitoring your system. Some of these may already be activated in your system by default, meaning you do not need any additional plug-ins. The following table provides a comprehensive overview:
Plug-in name / |
Function |
Parameters |
Output |
bi_aggregation / |
Outputs the status of a BI aggregation. Also indicates whether the aggregation is currently in maintenance mode or has been acknowledged. |
Name of aggregation |
One service per BI aggregation |
bi_aggregation_connection / |
Status information for the special agent agent_bi. Includes connection errors, missing site data, and missing aggregations due to missing data. |
n/a |
One service per connection |
check-mk / |
Retrieves status information from the configured data sources, e.g., from configured agents, special agents, SNMP, piggyback data, and management boards. The overall status of the service, which depends on the results, can be configured with the rule set Status of the Checkmk services. Also updates all passive services and any piggyback data received from the host. |
n/a |
n/a |
check-mk-inventory / |
Created automatically on new sites. Automatically goes to WARN as soon as a service of the host tags changes. Configuration is possible via the rule set Periodic service discovery. An automatic update of the Checkmk configuration with the services found can also be activated here. |
n/a |
one service for each host that supports this check |
checkmk_agent / |
Ensures the proper functioning of the Checkmk agent deployment mechanism (if used). Checks the time of the last successful connection to the deployment server and the presence of error messages, displays the number of deployed agent plug-ins and local checks. Further settings are possible, see the plug-in description |
n/a |
one service |
cmk_site_statistics / |
Monitors the number of hosts and services at Checkmk sites, reporting the total number of hosts, the number of hosts that are not UP, and the number of hosts that are UP, DOWN, in maintenance mode, and UNREACH. Reports the total number of services, the number of services that are not OK, and the number of services that are OK, in maintenance mode, running on failed hosts, WARN, UNKNOWN, and CRIT. The check is always OK and cannot be configured by the user. |
Name of the Checkmk site |
One service per running Checkmk site on a Checkmk server |
livestatus_status / |
Receives various performance data from an OMD monitoring core via Livestatus. Provides information about the performance of the core, the number of checks executed per second, etc. Determines whether certain settings have been disabled (e.g., notifications). States can be configured via check parameters. |
Name of the OMD site |
One service per running OMD site. |
mkbackup / |
Checks the status of backup jobs on a Checkmk appliance. Reports CRIT if the job fails or its next execution is overdue. |
ID of the job |
one service per backup job |
mkbackup_site / |
Checks the status of the backup jobs of a Checkmk site. Reports CRIT if the job fails or its next execution is overdue. |
ID of the site, followed by |
one service per site and backup job |
mkeventd_status / |
Receives various performance values of a site of the type Checkmk Event Console. Warning for active event limits, recording of performance metrics related to the Event Console. The check is not configurable by the user. |
Name of the Checkmk site |
One service per running Checkmk site |
mknotifyd_connection_v2 / |
Checks the status of individual TCP connections from the Checkmk notification spooler to a remote spooler. A service is created for each incoming and outgoing TCP connection. The status changes to CRIT if the connection is not established. |
Name of the site followed by the name of the connected remote site, separated by a hyphen. If there is more than one incoming connection from the same remote host, an index is appended. This check is not user-configurable. |
One service per site and connection |
mknotifyd / |
Checks the status of the Checkmk notification spooler. WARN if deferred spool files remain too long or damaged spool files are found. CRIT if spooler is not running. This check is not user-configurable. |
Name of the site |
one service per site |
omd_apache / |
Creates statistics about the requests processed by the Apache web server on OMD sites. It records the number of requests, the bytes sent, and the time required to process the requests. It is grouped by request type, e.g., Checkmk table views, NagVis AJAX calls, but also by type, e.g., for images, style sheets, etc. The check uses a specific log file, which must be located under |
Name of the site |
one service per site |
omd_broker_queues / |
Monitors the number of notifications in broker queues for each site application. Service name contains the site and application name. This check is always OK. |
site and application name |
One service per site application |
omd_broker_status / |
Monitors the general status of the message broker on each site. Shows the memory used by the broker, the number of queues, and the number of shovels in running status. This check is always OK. |
site name |
One service per site on which a broker is installed and running |
omd_diskusage / |
Monitors the disk usage of a site to facilitate the search for anomalies if necessary. A list of the directories currently being monitored can be found in the plug-in description. This check is always OK, and cannot be configured by the user. |
Name of the site |
one service per site |
omd_status / |
Checks the status of the OMD sites found on the system using |
Name of the site |
one service per site on which the option Autostart is set to |
site_object_counts / |
Collects information about the number of different host types or check commands used on the Checkmk sites. The settings and functionality of the check are extensive. For more information, see the plug-in description. The check is always in OK status. |
n/a |
one service |