Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
16006 discussions

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

by Lars Michelsen

ID: 7352 Title: Changed format of rules in rules.mk configuration files Component: Core & setup Level: 2 Class: Bug fix Version: 1.6.0b1 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 <tt>cmk-update-config</tt> in the site. It's invoked during the <tt>omd update</tt> 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 <tt>cmk-update-config</tt> 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: F+:rules.mk host_contactgroups = [ ('all', [], ALL_HOSTS, { 'description': u'Put all hosts into the contact group "all"' } ), ] + host_contactgroups F-: New ruleset: F+:rules.mk host_contactgroups = [ { 'condition': { 'host_folder': '/' + FOLDER_PATH }, 'value': 'all', 'options': { 'description': u'Put all hosts into the contact group "all"' } }, ] + host_contactgroups F-: 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 <tt>condition</tt> 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 <tt>tests/unit/cmk/utils/rulesets/</tt> or create rules with WATO and have a look at the resulting rules.mk. <h2>Explicit host name conditions</h2> If you want to make a rule match on the hosts named <tt>host1</tt> and <tt>host2</tt>, you may use a condition like this: F+:rules.mk "condition": { "host_name": ["host1", "host2"]}, } F-: <h2>Exclude hosts</h2> Match all hosts except <tt>HOST1</tt> and <tt>HOST2</tt>: F+:rules.mk "condition": { "host_name": { "$nor": ["HOST1", "HOST2"] }, }, F-: <h2>Regex on host names</h2> Make a rule match on hosts by using a regular expression: F+:rules.mk "condition": { "host_name": [{ "$regex": "abc[12]" # It's a case sensitive prefix match },] }, F-: <h2>Match using host tags</h2> Match all hosts that are <tt>test</tt> systems connected via <tt>wan</tt> F+:rules.mk "condition": { "host_tags": { "criticality": "test", "networking": "wan", }, } F-: <h2>Combine different conditions<h2> Match test hosts that start with <tt>abc</tt>: F+:rules.mk "condition": { "host_name": [{"$regex": "abc"}], "host_tags": { "criticality": "test", }, } F-: <h2>Service rulesets: Match on the description</h2> Same syntax as <tt>host_name</tt> condition, e.g. match all services starting with <tt>CPU</tt>: F+:rules.mk "condition": { "service_description": [{"$regex": "CPU"}], } F-:

5 years, 4 months

Checkmk Werk 7761: New livestatus columns tags and labels

by Lars Michelsen

ID: 7761 Title: New livestatus columns tags and labels Component: Livestatus Level: 1 Class: New feature Version: 1.6.0b1 The hosts and services tables now have two new columns named <tt>tags</tt> for fetching the configured tags and <tt>labels</tt> for fetching the configured labels. In the past one had to use the columns <tt>custom_variables</tt> to get the TAGS custom variable of a host and parse the value of this variable to get the configured host tags. This approach also had some limitations in terms of filtering by tags. The tag group information was totally missing here. The new <tt>tags</tt> column can be parsed and filtered with less trouble. If you do livestatus queries on the tags we recommend to use these fields. One example for a livestatus query and the resulting data: C+: OMD[heute]:~$ lq "GET hosts\nColumns: tags\nOutputFormat: json" [[{"snmp_ds":"no-snmp","address_family":"no-ip","networking":"lan","tcp":"tcp","site":"heute","piggyback":"piggyback","criticality":"prod","agent":"cmk-agent"}]] C-: The filtering can be done just like for other dictionary style columns.

5 years, 4 months

Checkmk Werk 7762: Aux tag IDs and tag group IDs need to be unique now

by Lars Michelsen

ID: 7762 Title: Aux tag IDs and tag group IDs need to be unique now Component: WATO Level: 1 Class: Bug fix Version: 1.6.0b1 In previous versions it was possible to configure auxiliary tags with an ID that was also used as tag group ID. This resulted in name conflicts and subtile inconsistencies in different situations. To prevent these problems Checkmk now enforces these IDs to be unique.

5 years, 4 months

Checkmk Werk 7763: Introduce labels as host and service properties

by Lars Michelsen

ID: 7763 Title: Introduce labels as host and service properties Component: Core & setup Level: 2 Class: New feature Version: 1.6.0b1 In addition to existing mechanisms like host tags and host custom attributes that can be used to define custom host properties we have now added the labels. The labels are similar to the host tags, but not work exactly in the same way. A major difference is, that tags are based on a predefined collection of tags (tag groups, tag ids) in Check_MK. Labels are more flexible and can be created ad-hoc. The explicit labels attribute is inherited from folders to hosts. Each object may add a set of labels on it's own to the effective labels. A label has the format <tt>key:value</tt>. For example <tt>os:windows</tt>. Each host can have only one value per key. In case folders and hosts define a value for the same key, the value next to the host will win. The rulesets "Host labels" and "Service labels" can be used to assign labels to hosts and services in addition to the labels configured using the host attribute. Thes ruleset make it possible to assign lables to hosts and services based on tags and other host / service conditions. Labels can be created dynamically during runtime. Host labels can be discovered using the HW/SW inventory. To realize this a new HW/SW inventory plugin has been added that works on a generic "<<<labels>>>" section (see #7336). The first agents that produce this section are the Kubernetes, AWS and Azure special agents. They creates the label sections for all kind of objects that are monitored by Checkmk. This makes Checkmk automatically import the labels configured in the target systems. Depending on the source of a label it is now colorized in different ways to make the origin of the label transparent to the user. The effective labels of hosts and service sare currently visible on WATO "Parameters of X" page, mainly for diagnose. The labels are available on the HW/SW inventory page and can be used as painter, sorter and filter in the status views and reports. The painters have been added to the host and service detail views. The labels can currently not be used in rule conditions. This will be added in one of the next beta releases.

5 years, 4 months

Checkmk Werk 7166: Agent Bakery now supports systemd

by Andreas Umbreit

ID: 7166 Title: Agent Bakery now supports systemd Component: agents Level: 1 Class: New feature Version: 1.6.0i1 Until now, it was necessary to have xinetd installed on a host system in order to setup the CheckMK Agent coming from the agent bakery automatically. The baked .rpm and .deb installation packages will now fall back to install the Agent as a systemd-service, if no xinetd is available on the host. With this change, the baked agent package equals the vanilla agent package in its installation behavior.

5 years, 4 months

Checkmk Werk 7695: haproxy: Skip invalid lines which led to a crash while discovery

by Simon Betz

ID: 7695 Title: haproxy: Skip invalid lines which led to a crash while discovery Component: Checks & agents Level: 1 Class: Bug fix Version: 1.6.0i1

5 years, 4 months

Checkmk Werk 7346: Fix name conflict between builtin snmp tag group and aux tag snmp

by Lars Michelsen

ID: 7346 Title: Fix name conflict between builtin snmp tag group and aux tag snmp Component: Multisite Level: 1 Class: Bug fix Version: 1.6.0i1 The bultin tag group "snmp" for configuring the SNMP datasource of a host and the related auxiliary tag "snmp" used the same ID. This resulted in a name conflict between both which could cause problems e.g. in the rule editor when using the auxiliary tag as condition. The tag group has now been renamed to "snmp_ds" and the auxiliary tag ID stays "snmp".

5 years, 4 months

Checkmk Werk 7299: fireeye_mail: Fix the rate and considered time duration of received mails

by Florian Kromer

ID: 7299 Title: fireeye_mail: Fix the rate and considered time duration of received mails Component: Checks & agents Level: 1 Class: Bug fix Version: 1.6.0i1 The rate of received mails is performance data compatible and consistent to the other fireeye sub checks mails per second.

5 years, 4 months

Checkmk Werk 6971: Bump shipped Python from 2.7.15 to 2.7.16.

by Sven Panne

ID: 6971 Title: Bump shipped Python from 2.7.15 to 2.7.16. Component: Other Components Level: 2 Class: New feature Version: 1.6.0i1 Python 2.7.16 contains quite a few bug fixes compared to 2.7.15 plus some performance, library and syntax improvements.

5 years, 4 months

Checkmk Werk 7156: Dropping support for Ubuntu 17.10

by Alex Zurhake

ID: 7156 Title: Dropping support for Ubuntu 17.10 Component: Linux Distributions Level: 3 Class: New feature Version: 1.6.0i1 Ubuntu 17.10 is End of Life. Therefore we stop supporting this Distro.

5 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1