Check_mk docker monitoring directly monitors Docker containers through a Linux agent. And, it also keeps an eye on the container itself in addition to the demon or the overall container.

Bobcares answers all questions no matter the size, as part of our Docker hosting support

Let us take a look at check_mk docker monitoring in detail.

Check_mk and Docker Monitoring

Checkmk can discover full status information for the containers in addition to status and inventory information. It is done for the node to watch the container, and list each one as a separate host in Checkmk.

Within the Checkmk Enterprise Editions, container hosts will ‘create or remove’ automatically using the dynamic configuration. Checkmk keeps track of a container’s health condition as supplied by the HEALTHCHECK API. Healthy statuses are as OK, starting statuses as WARN, and unhealthy statuses as CRIT. The health test command itself and the most recent output of the health test are on display by the plugin.

The user must install the agent plugin “mk docker.py” for this check to function. To use “Piggybacked docker containers,” the user must be employing agent bakery rules. Ensure to not omit the “docker container status” line if the user is configuring the plugin using the configuration file. The default setting is also fine.

Configuring check_mk docker monitoring

Installing the agent and plug-in

The ‘mk docker.py’ agent plug-in is required, and it may be obtained here: Configuration > Agents > Additional OSes > Plugins; in /usr/lib/check_mk_agent/plugins, install the plug-in. The user can also perform this with the Checkmk Enterprise Editions with the Agent Bakery. This has the proper rule set for monitoring Docker: containers and the Docker node.

Keep in mind that the docker ‘Python’ library is necessary (not docker-py). Version 2.0.0 is a minimum requirement. To quickly verify this, use python on the command line:

root@linux# python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker
>>> docker.version
'5.0.3'

If necessary the user can install the library with pip3:

root@linux# pip3 install docker

Important: The user must not install the ‘docker-py’ or ‘python-docker-py’ packages. Hence, the Docker library is now accessible under the same namespace in an unworkable version. A single uninstall is insufficient if ‘docker-py’ (or both variants) is installed. This is because ‘pip3’ cannot correct the namespace. The user must run the following scripts to ensure the installation of the right version in this situation:

root@linux# pip3 uninstall docker-py docker root@linux# pip3 install docker

The user should now notice a few new services that have an impact on the Docker node itself. They can note the changes by running the service discovery in Checkmk and applying the changes.

 Finetuning the plug-in

The plug-various in’s parameters are configurable. For example, the user can save resources by turning off any sections. The sections don’t require or, if necessary, configuring the Docker API Engine endpoint.

On the Docker host, create the configuration /etc/check_mk/docker.cfg. A detailed note template can be found in the Checkmk directory~/share/check_mk/agents/cfg_examples/docker.cfg. With the Agent Bakery in the Enterprise Editions, the user can quickly configure all the parameters.

 Container Monitoring

Creating the container hosts

The monitoring of the Docker containers is, of course, an interesting component. Installing the plug-ins will automatically accomplish this. It won’t allocate the services to the docker node instead Checkmk presupposes a single host per docker container.

The process, in this case, is piggyback. The plug-in or special agent will transmit data from other hosts with its own data, or “piggybacks,”. The tmp/check_mk/piggyback directory will hold this information. The services will be automatically assigned to the hosts. It will be done after the user creates them in the Setup with the proper names.

The user can have these hosts established automatically in the Enterprise Editions. Utilize the Piggyback connector when configuring dynamically. If the user constructs the hosts manually, take note of the following.

1. The hostname and the directory created in ‘tmp/check mk/piggyback’ must exactly match. This is the container’s 12-character short ID by default.
2. Set Network address > IP address family# to No IP if the containers don’t have their own IP addresses.
3. Ensure that Checkmk agent / API integrations, set to No API integrations and no Checkmk agent for monitoring agents.
4. The user can enter the hostname of the Docker node in the Parents area under Basic settings.
5. Monitor the Docker node and its containers from the same location.

After the creation of Container Hosts, and performing a service discovery, new services appear on these. New services start to show on the container hosts after creation and after a service discovery process If the user installed a Linux agent in the container, it will automatically run.

 Other names for container hosts

As previously indicated, the container host’s name is by default the 12-character short ID for the container. The user can choose to customize this differently. To accomplish this, set the container_id option in the configuration file docker.cfg to either long or name, depending on whether the user wants to utilize the container name or the full container ID as the name.

Users of Checkmk Enterprise Editions can configure this using the rule Docker node and containers, option Hostname used for containers, in the Agent Bakery.

Host name used for containers
Short - Use the first 12 characters of the docker container ID Short - Use the first 12 characters of the docker container ID
A
Long - Use the full docker container ID
'Name - Use the containers' name

Coincidentally: A user can establish rather flexible rules for renaming host names contained in piggyback data with the Access to agents > General settings > Hostname translation for piggybacked hosts rule set. The user may even fix issues like having identical containers on two distinct Docker nodes using this technique.

Host status monitoring

The host state of a container can’t truly be checked via ICMP or TCP packets. Hence another method must be used. This is made easier by the Docker container status service. It verifies that the container is running and may be used as a security tool to determine the host’s state. Create a rule in the Host Check Command rule set specifically for this purpose. Then change the choice to the indicated service under Use the status of the service… Don’t forget to configure the conditions so that they only apply to containers. In our illustration, every container is housed in a folder that has the same name.

Directly operating agent from the container

The user should ensure to install the Checkmk agent is functioning inside the container itself. It is done to monitor information there (such as active processes, databases, log files, etc.). This is particularly accurate for the implementation of agent plug-ins. However, the three plug-ins mem, cpu, and diskstat(Disk I/O) function without a container-based agent. Checkmk agent analyses them on the node.

The user might want to deploy the agent directly into the container, particularly for self-created Docker images. In this situation, the Docker node’s agent no longer analyzes the data as previously mentioned. Instead, each container runs a different agent. In this process, it will use the Docker node to call the agent in the piggyback process.

However, the agent in the container can only function if the container itself has all essential commands. It’s possible that fundamental components like Bash are absent. And, especially in containers made with care and based on Alpine Linux. In this case, the user should use the Docker node to monitor the container. In this situation, the Host Check Command rule set will only be necessary if the container can’t be pinged; otherwise, it will operate just as previously explained.

[Need assistance with similar queries? We are here to help]

Conclusion

To conclude the check_mk docker monitoring keep a close eye on the Docker containers. The check_mk docker monitoring keeps guard of it.