Labels

Labels can be assigned to a host in a number of ways.

The first of these is simple: On the host properties page, which is displayed when you create or edit a host in the Setup, you can give it as many labels as you like:

Activate Labels with the checkbox, then click in the Add some label field, enter the label definition in the form key:value and finish with Enter.

You can edit an existing label by clicking it in its text, or delete it with the little cross.

Note: Both the key and the value of a label may include any character — except the colon (:)! However you should think carefully about the use of characters and upper/lower case, since if you later define conditions via labels, then the spelling of both the key and the value must be strictly observed.

Of course labels can also be inherited from a folder. Like other attributes, labels can be in subfolders or at the host, then as needed be overwritten again — individually in fact. If for example, the label location:munich is set in the folder, this will be inherited by all hosts in this folder which do not themselves already have the label location defined. Other labels a host may have will remain unaffected.

Explicitly-defined labels for hosts or folders appear violet in the list of hosts:

As usual in Checkmk, attributes can also be assigned to hosts and services by rules. This will make you independent of the folder structure, and it also applies to the labels. There is a Host labels rule set for this function, which you can quickly find via a search in the Setup menu.

The following rule adds the hw:real label to all hosts in the Bavaria folder which have the Real Hardware host tag:

You may have noticed that labels cannot be used in the conditions for this rule. This is not a mistake, but intentional, and it avoids recursive dependencies and other anomalies.

Labels added via rules appear red at the host shown, but do not appear in the host list in the Setup, instead they only appear with the status view of the host.

The third way labels can be created is fully automatically. Various data sources such as the special agents for monitoring cloud and container systems automatically generate labels. In particular, the special agents for AWS, Azure and Kubernetes should be mentioned here. Sometimes these things are also referred to as tags on the respective platforms and are created in Checkmk as host or service labels. The respective rule sets provide sufficient information about this.

The nice thing is that you do not have to configure anything at all. As soon as these data sources are active, the corresponding labels will be generated.

In the Automatically generated host labels section you will find an overview of the labels that Checkmk generates automatically.

A simple way to manipulate labels directly is to add an agent plug-in, which, analogous to local checks, creates a section called labels. In this way you can assign labels in more detail than by evaluating the HW/SW inventory alone — for example, according to nuances of the installed hardware (such as CPU features) or actually running processes (instead of just installed software).

The label output is to be formatted as a Python dictionary, as in the following example:

Avoid conflicts with the labels automatically assigned by Checkmk itself and other plug-ins, as no particular order of evaluation can be guaranteed.

If you have enabled the discovery check — which is the default for new installations — it will warn you when new host labels are found that have not yet been added to the host properties in the Setup. This will look like this, for example:

You have two options for responding to this warning. The first is to add the new labels by calling the service configuration for the host in the Setup and updating the configuration of the labels with the Hosts > Update host labels menu item. The discovery check will then be OK again the next time it runs (up to a two-hour delay), even if you have not yet activated the changes. If you don’t want to wait that long, you can also manually update the service immediately by selecting Reschedule check in the action menu of the service.

If this affects many hosts at once, you will certainly not want to visit the service configuration for each host. The best thing to do here is to run the bulk action for Run bulk service discovery and select Only discover new host labels as the mode — or alternatively Add unmonitored services and new host labels if you also want to take the opportunity to add new services.

The second way to turn the discovery check green is to reconfigure it so that it no longer warns you about new labels. To do this, go to the Periodic service discovery rule set, and edit the existing rule — there you will find the Severity of new host labels option:

This is set to Warning by default. Choose OK - do not alert, just display and the check will go silent.

Labels found via discovery check are displayed in yellow-ocher.

Theoretically, the same label may be defined with different values in multiple sources simultaneously. That’s why there is the following order of priority:

These precedence rules give you the ultimate control over the labels.

An important function of Labels is the same as for host features: Namely, their use as a condition in rules. This is especially useful for automatically generated labels, because you can adapt your monitoring fully automatically based on information from AWS, Azure, Kubernetes and co.

Add conditions with Add to condition for the host or service labels. Now select either is or not to formulate a positive or negative condition and then enter the label in the usual form key:value. Pay attention to the exact spelling here, including capitalization. As labels can be defined without specifications, Checkmk cannot recognize typos. Nevertheless: When you type in a label, Checkmk suggests existing labels if they match your previous input. No distinction is made between host and service labels in the suggestions: all matching labels are offered. Otherwise the condition will not work correctly.

Tip: If this causes difficulties in individual cases, it may be better to work with host characteristics. In the article on Structuring the hosts you will find more information on the various structuring elements.

However, the definition of the condition goes one step further: To further refine the condition, you also have the Boolean operators Not, And and Or at your disposal. Here, Not is the abbreviation for And Not.

Important: The operators are processed in exactly this priority — Not, And, Or — i.e. not necessarily in the order in which they appear in the list. This corresponds to the standard of Boolean algebra. For example, A And B Not C Or D would correspond to the parentheses (A And (B Not C)) Or D.

For example, to find hosts with the label cmk/site:today but without the label cmk/piggyback_source_today:yes, the condition could look like this:

You can refine this condition with is or not with any other specifications. Or you can add a new group of conditions with Add to condition, which makes the now more complex condition easier to read, but does not change the evaluation of the Boolean algebra:

Note: If you have defined neither Host tags nor Host labels, the rule in question is always applied to all hosts or services. If you have created several rules, subsequent rules may no longer be evaluated, see Types of rule analysis.

You can use both labels and host characteristics in a rule. These are automatically AND-linked. The rule therefore only applies if both conditions are fulfilled at the same time.

You can use labels as conditions in notification rules, too. The usage is the same as in other conditions, so you don’t need re-educate yourself to use them. Select Match host labels and simply enter which labels a host or service must have, thus triggering a notification through this rule. Again, multiple labels are connected by the AND operation.