Best practices, tips & tricks

Checkmk automatically sets up a service under both Linux and Windows that monitors the average CPU usage over the course of the last minute. On the one hand, this makes sense, but on the other hand it does not recognize some errors, for example, that a single process runs amok and continuously utilizes one CPU at 100 %. In a system with 16 CPUs, however, a CPU only contributes 6.25 % to the overall performance, and so even in the extreme case described, a total utilization of only 6.25 % is recorded — which does not trigger a notification.

For this reason, Checkmk provides the option (for Linux and for Windows) of monitoring all available CPUs individually and determining whether any of their cores is constantly busy over a longer period of time. Setting up this check has turned out to be a good idea.

To set up this check for your Windows servers, you need for the CPU utilization service the CPU utilization for simple devices rule set, which you can find under the Service monitoring rules. This rule set is responsible for monitoring all CPUs — but it also has this option: Levels over an extended time period on a single core CPU utilization.

Create a new rule and activate only this option in it:

Define the condition so that it only applies to the Windows servers, for instance by using a suitable folder or host tag. This rule will not affect other rules of the same rule set if they set other options, such as the thresholds for the total CPU utilization.

For Linux servers, this is the responsibility of the CPU utilization on Linux/UNIX rule set, in which you can set the same option.

By default, Checkmk does not monitor any services on your Windows servers. Why not? This is simply because Checkmk does not know which services are important to you.

If you do not want to go to the trouble of manually determining for each server which services are important, you can also set up a check that simply checks whether all services with the start type "automatic" are in fact running. In addition, you can be informed whether services are running that were started manually — out of order, so to speak. These will no longer run after a reboot — which could be a problem.

To implement this, you first need the Windows Services rule set which you can find under the Service monitoring rules, by using the search function Setup > General > Rule search, for example. The crucial option in the new rule is Service states. Activate this and add three new elements for the states of the services:

This allows you to implement the following monitoring:

However, this rule only applies to services that are actually being monitored. Therefore, we need a second step and a second rule, this time from the Windows service discovery rule set, with which you define which Windows services Checkmk should monitor as services.

When you create this rule, you can first enter the regular expression .* in the Services (Regular Expressions) option, which will then be applied to all services.

After saving the rule, switch to the service configuration for a suitable host. There you will find a large number of new services — one for each Windows service.

To limit the number of monitored services to those of interest to you, return to the rule and refine the search terms as needed. This is case-sensitive. Here is an example of a customized service selection:

If you have previously included services that do not match the new search expressions now in the monitoring, they will appear as vanished in the service configuration. With the Rescan button you can clear the air and have the entire service list recreated.

Your organization’s access to the Internet is certainly very important to everybody. Monitoring the connection to 'the Internet' is a bit difficult to implement, as it involves the billions of computers which could (hopefully) be accessible — or not. Nevertheless, you can still set up an efficient monitoring system, based on the following construction plan:

If you now activate the changes, you will get the new host internet with the single service Internet connection in the monitoring.

If at least one of the ping destinations is reachable, the host will have the state UP and the service will have the state OK. At the same time, the service provides you with performance data for a typical packet — its round trip time — and packet loss for each of the specified IP addresses. This will give you an indication of the quality of your connection over time:

The fourth and final step is necessary so that the host does not enter the DOWN state if the first IP address is not reachable via ping. Instead, the host will acquire the state of its only service.

Important: Since a service basically does not notify when its host is DOWN, it is important that you control the notifications via the host — and not via the service. As well, in this particular case, you should use a notification method that does not require an internet connection.

Let’s say you want to check the accessibility of a website or web service. The Checkmk agent does not offer a solution here, as it does not display this information — and besides, you may not even have the possibility of installing an agent on the server.

The solution is a so-called active check. This is one that is not performed by an agent, rather by directly contacting a network protocol at the target host — in this case HTTP(S).

The procedure is as follows:

You will now have a new host with a service that checks access via HTTP(S).

You can of course also perform this check on a host that is already being monitored with Checkmk via an agent. In this case, you will not need to create the host, and you will only need to create this new, additional rule for the host.

Finding good thresholds for monitoring file systems can be tedious. After all, a threshold of 90 % is much too low for a very large hard disk and is perhaps already too marginal for a small one. We have already introduced the facility for setting thresholds depending on a files system’s size in the chapter on fine-tuning monitoring — and hinted then that Checkmk has another, even cleverer option on offer — the magic factor.

You set up the magic factor like this:

The result will look like this:

If you now save this rule and activate the change, you will have threshold values that vary automatically depending on the size of the file system:

Exactly how high the threshold values are is, well — magical! The factor (here 0.8) determines how much the values are adjusted. A factor of 1.0 changes nothing, and all file systems get the same values. Smaller values have a greater effect on the adjustment of the values. The default values for Checkmk used in this chapter have proven themselves in practice with very many installations.

You can see exactly which thresholds apply for each service in its Summary:

The following table shows some examples of the effect of the magic factor (mf) with a reference value of 20 Gbyte / 80 %:

With this chapter on the magic factor, we conclude our Beginner’s Guide. We hope that you have been able to set up a solid foundation for your Checkmk system — with or without magic. For nearly all the topics we have covered in this Beginner’s guide, you will find more in-depth information in other articles in the User guide.

We wish you every success with Checkmk in the future!