We use cookies to ensure that we give you the best experience on our website.  Visit our Privacy Policy to learn more. If you continue to use this site, we will assume that you are okay with it.

Your choices regarding cookies on this site.
Your preferences have been updated.
In order for the changes to take effect completely please clear your browser cookies and cache. Then reload the page.

Checkmk Conference #6 is coming! Learn more about it here!

Werk #7352: Changed format of rules in rules.mk configuration files

ComponentCore & Setup
TitleChanged format of rules in rules.mk configuration files
Date2019-06-04 17:54:35
Checkmk EditionCheckmk Raw Edition (CRE)
Checkmk Version1.6.0b1
LevelProminent Change
ClassBug Fix
CompatibilityIncompatible - Manual interaction might be required

The internal data format of the Checkmk rules configured via WATO on the "Host- & Service parameters" pages has been changed.

If you only use WATO for configuring Checkmk this change will not be relevant for you, since the data format will be changed automatically during update to 1.6x.

In case you edit rules.mk (or other .mk) files manually or via script, you will likely have to change your scripts.

The format changes was needed to make more flexible rule conditions possible. The new conditions for 1.6 (select multiple choices of a tag group and labels) have not been added yet. They are nearly ready and will be added in one of the next beta releases.

The automatic update mentioned before is done using the command cmk-update-config in the site. It's invoked during the omd update execution and currently simply loads all folder, host, tag and ruleset configuration files, executes the transform logic and saves again, just like you would do when working in WATO. In case your scripts created an "old style" WATO configuration file in an 1.6 site you could execute cmk-update-config another time, which would load, convert and save the configuration file. However, a better approach would be to update your scripts to write the configuration files in the new format.

In Checkmk a ruleset is represented by a list of rules. In the past these rules were represented by tuples with different elements (depending on the ruleset type). The structure of a rule has now been changed to a dictionary.

An example from the sample configuration:

Old ruleset:

rules.mk
host_contactgroups = [
('all',
[],
ALL_HOSTS,
{
'description': u'Put all hosts into the contact group "all"'
}
),
] + host_contactgroups

New ruleset:

rules.mk
host_contactgroups = [
{
'condition': {},
'value': 'all',
'options': {
'description': u'Put all hosts into the contact group "all"'
}
},
] + host_contactgroups

This shows the rough structure of the new format. Inside the condition dictionary you can have multiple optional keys which trigger different host / service filters in Checkmk.

The following examples of the condition dictionary are not covering all possible combinations, but should give you and idea of the new condition format. If you want to have a more detailed look, have a look at the tests below tests/unit/cmk/utils/rulesets/ or create rules with WATO and have a look at the resulting rules.mk.

Explicit host name conditions

If you want to make a rule match on the hosts named host1 and host2, you may use a condition like this:

rules.mk
"condition": {
"host_name": ["host1", "host2"],
}

The entries in the host list are ORed.

Exclude hosts

Match all hosts except HOST1 and HOST2:

rules.mk
"condition": {
"host_name": {
"$nor": ["HOST1", "HOST2"]
},
},

Regex on host names

Make a rule match on hosts by using a regular expression:

rules.mk
"condition": {
"host_name": [{
"$regex": "abc[12]" # It's a case sensitive prefix match
},]
},

Match using host tags

Match all hosts that are test systems connected via wan

rules.mk
"condition": {
"host_tags": {
"criticality": "test",
"networking": "wan",
},
}

The single tag conditions are ANDed.

Combine different conditions

Match test hosts that start with abc:

rules.mk
"condition": {
"host_name": [{"$regex": "abc"}],
"host_tags": {
"criticality": "test",
},
}

Different types of conditions are ANDed.

Service rulesets: Match on the description

Same syntax as host_name condition, e.g. match all services starting with CPU:

rules.mk
"condition": {
"service_description": [{"$regex": "CPU"}],
}