1. Introduction
A Checkmk site requires all kinds of services, first and foremost the monitoring core, but also an Apache web server for the web interface, Cron for scheduling tasks, and many others.
You can see all of these services when you start a site using omd start in the terminal — some services are present in all editions and by default, others only in certain editions and/or when their corresponding functions are activated.
The command omd status in a commercial edition could result in the following output:
2. Overview of services
The following table provides a brief overview and shows the following for each service
the displayed process name,
whether it exists in
Checkmk Raw and/or in the commercial editions,whether it exists by default without explicit configuration, and
a brief description of what the service actually does.
Most services are explained in more detail in the linked articles, while others are largely self-explanatory (such as the Apache service). We will discuss a few other services that only perform their tasks in the background in the following chapter.
| Service |
Checkmk Raw
|
Commercial editions | Enabled by default | Description |
|---|---|---|---|---|
|
Yes |
Yes |
Yes |
Endpoint for communication with the Checkmk agent |
|
Yes |
Yes |
Yes |
Web server |
|
Yes |
Yes |
Yes |
Helper service for improving performance for GUI and REST API requests, more details below |
|
No |
Yes |
Yes |
Checkmk Micro Core — Monitoring core in the commercial editions |
|
Yes |
Yes |
Yes |
Crontab file for internal task scheduling |
|
No |
Yes |
Yes |
Dynamic Configuration Daemon for dynamic host management of transient hosts (such as containers) |
|
No |
Yes |
No |
Analysis tool for traces received via OpenTelemetry — for internal bug fixing, more details below |
|
Yes |
Yes |
Yes |
Interface for retrieving status data via Livestatus |
|
Yes |
Yes |
Yes |
Service for processing events with the Event Console |
|
No |
Yes |
No |
Notification spooler for asynchronous delivery and distributed environments |
|
Yes |
No |
Yes |
Monitoring core of Checkmk Raw and old commercial edition installations (can be there migrated to CMC) |
|
Yes |
No |
Yes |
Nagios Performance C Daemon for processing Nagios performance data in Checkmk Raw |
|
Yes |
Yes |
No |
Piggyback hub in distributed monitoring, more details below |
|
No |
Yes |
No |
Message broker RabbitMQ, more details below |
|
Yes |
Yes |
Yes |
In-memory database as temporary storage (provides the search index, for example) |
|
Yes |
Yes |
Yes |
RRD cache daemon for temporary storage of measured values |
|
Yes |
Yes |
No |
Builds in distributed monitoring a tunnel from a local, unencrypted Livestatus port to a remote encrypted one |
|
No |
Yes |
No |
Scheduler for asynchronous tasks of the web interface, more details below |
|
Yes |
Yes |
No |
Service for providing agent output |
Incidentally, most of the services listed here are automatically included in monitoring as part of Checkmk’s self-monitoring along with several others. If you notice performance issues, it may be worthwhile to further expand the monitoring of the Checkmk server itself.
3. Services in detail
3.1. Jaeger
Jaeger is an analysis tool for tracking, analyzing, and visualizing requests in a complex system. In Checkmk, these could be the individual parts of a network scan, i.e., requests to the internal database, pings, file operations, and so on. All of these small elements require time, and Jaeger can help to understand performance issues and detect bottlenecks.
Jaeger was primarily added for the development of Checkmk and is only active if the sending and receiving of traces has been explicitly enabled in the site configuration via omd config in the menu Addons > TRACE RECEIVE or TRACE SEND.
When enabled, you can access the Jaeger web interface via http://mycmkserver/mysite/jaeger.
For more information, see the related Werk 16565.
Jaeger should be disabled during normal operation.
3.2. RabbitMQ and piggyback hub
RabbitMQ is basically a message broker that is suitable for sending any form of message by using queues. In Checkmk, RabbitMQ is currently used as a function in conjunction with the piggyback hub. Briefly explained: When piggyback data is generated in distributed monitoring, RabbitMQ ensures that the data is forwarded from the sites where it is generated to the sites where it is needed/evaluated. A detailed technical explanation of how this works can be found in the presentation Piggyback unleashed — a new way for intersite communication from the 11th Checkmk conference.
For information on how to activate piggyback hub and RabbitMQ, refer to the article on distributed monitoring.
3.3. ui-job-scheduler
The ui-job-scheduler service organizes asynchronous tasks that occur in the web interface.
The most prominent example is probably the activation of changes.
This involves updating the web interface, displaying an animated progress bar, applying changes, and finally updating the view again and displaying any resulting status messages.
During these activities, additional child processes appear and disappear, and the processor load increases briefly.
3.4. automation-helper
The automation-helper service speeds up some GUI interactions, such as service discovery and activating changes,
especially in small to medium-sized installations (see also Werk 17678).
The service can be disabled via omd config in the menu Basic > AUTOMATION HELPER.