Checkmk werks level1 February 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
287 discussions

[2.3.0] Checkmk Werk 16390 created: notification_rule: cancel previous notifications now working with custom plugin scripts

by Checkmk werks level 1

[//]: # (werk v2) # notification_rule: cancel previous notifications now working with custom plugin scripts key | value ---------- | --- date | 2024-01-31T15:15:29+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes When creating or updating notification rules, the option to "cancel_previous_notifications" was previously not available when the plugin name selected was a custom plugin script. This werk addresses this issue and now allows for custom plugin scripts when setting the option to cancel.

7 months

[2.3.0] Checkmk Werk 16325 created: netapp_ontap_psu: fix discovery ruleset

by Checkmk werks level 1

[//]: # (werk v2) # netapp_ontap_psu: fix discovery ruleset key | value ---------- | --- date | 2024-01-31T13:08:07+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | no This problem affected users who wanted to discover the 'summary' mode of PSU service: it was not possible to configure the appropriate discovery rule. This werk fixes this behaviour. A rediscovery is required for the change to take effect.

7 months

[2.3.0] Checkmk Werk 15324 created: agent_bakery: mk_postgres.py: restore required keys

by Checkmk werks level 1

[//]: # (werk v2) # agent_bakery: mk_postgres.py: restore required keys key | value ---------- | --- date | 2024-02-01T06:19:27+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes [Werk #15645](https://checkmk.com/werk/15645) made the Inputs of "Instance settings" of the Agent rule "PostgreSQL database and sessions (Linux, Windows)" optional by accident. If you did not specify all keys, baking agents failed with a `KeyError` on the automation call.

7 months

[2.3.0] Checkmk Werk 16389 created: authentication: remove user profile dir when unknown user and failed to login

by Checkmk werks level 1

[//]: # (werk v2) # authentication: remove user profile dir when unknown user and failed to login key | value ---------- | --- date | 2024-01-26T15:59:51+00:00 version | 2.3.0b1 class | fix edition | cre component | wato level | 1 compatible | yes Previously, failed login attempts with an unknown user would create a user profile directory. This is no longer the case. The profile directory is now only created for valid users.

7 months

[2.3.0] Checkmk Werk 16364 created: tag_group: change the identification field from 'ident' to 'id'

by Checkmk werks level 1

[//]: # (werk v2) # tag_group: change the identification field from 'ident' to 'id' key | value ---------- | --- date | 2024-01-29T13:13:54+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Before this Werk, when creating a tag group, the **ident** field was used to provide its identification as well as that of the tags associated to the group, however the information was returned in the **id** field. This Werk unifies the names and now the **ident** fields are renamed to **id**. Users should adapt their scripts accordingly. For comptatibility reasons CheckMK 2.2.0 and 2.3.0 will support both **id** and **ident**, but **ident** will be removed on the next version. The following example shows the changes that need to be applied to the payload to use this endpoint: Original payload: ```json { "ident": "test_group", "title": "Test group", "help_text": "My test groupd", "tags": [ {"ident": "test", "title": "Test Tag"} ] } ``` Updated payload: ```json { "id": "test_group", "title": "Test group", "help_text": "My test groupd", "tags": [ {"id": "test", "title": "Test Tag"} ] } ```

7 months

[2.3.0] Checkmk Werk 16384 adapted: notification rule: allow for non builtin service levels

by Checkmk werks level 1

Werk 16384 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # notification rule: allow for non builtin service levels key | value ---------- | --- date | 2024-01-17T11:19:06+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When configuring a notification rule via the Rest API, you could not set the value for "match_service_levels" to anything but the default service levels. This werk addresses this issue by now allowing any of the service levels configured to be used. This change mean that there is a change to the request schema. Previously, we accepeted the service level string value, whereas now we accept the integer value. Previous schema ``` {"match_service_levels": { "state": "enabled", "value": {"from_level": "silver", "to_level": "gold"} } } ``` New schema ``` {"match_service_levels: { "state": "enabled", "value": {"from_level": 10, "to_level": 20} } } ``` ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # notification rule: allow for non builtin service levels key | value ---------- | --- date | 2024-01-17T11:19:06+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When configuring a notification rule via the Rest API, you could not set the value for "match_service_levels" to anything but the default service levels. This werk addresses this issue by now allowing any of the service levels configured to be used. This change mean that there is a change to the request schema. Previously, we accepeted the service level string value, whereas now we accept the integer value. Previous schema ``` {"match_service_levels": { "state": "enabled", "value": {"from_level": "silver", "to_level": "gold"} } } ``` New schema ``` {"match_service_levels: { "state": "enabled", - "value": {"from_level" 10, "to_level": 20} + "value": {"from_level": 10, "to_level": 20} ? + } } ```

7 months

[2.3.0] Checkmk Werk 14222 created: BI configuration: Changed element order of "restrict severity to at worst"

by Checkmk werks level 1

[//]: # (werk v2) # BI configuration: Changed element order of "restrict severity to at worst" key | value ---------- | --- compatible | yes version | 2.3.0b1 date | 2024-01-31T09:55:00+00:00 level | 1 class | feature component | bi edition | cre This werk only introduces a visual fix, so no functional changes. The order of the dropdown choice elements did not reflect the severity of the states. The correct severity order for the BI is OK->WARN->UNKNOWN->CRIT, which differs from the order of the monitoring states OK->WARN->CRIT->UNKNOWN.

7 months

[2.3.0] Checkmk Werk 14221 created: Parent/Child topology: No longer ignoring additionally configured filters

by Checkmk werks level 1

[//]: # (werk v2) # Parent/Child topology: No longer ignoring additionally configured filters key | value ---------- | --- date | 2024-01-30T14:11:43+00:00 version | 2.3.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes

7 months

[2.3.0] Checkmk Werk 16040 created: Add Top list dashlet

by Checkmk werks level 1

[//]: # (werk v2) # Add Top list dashlet key | value ---------- | --- date | 2024-01-31T07:14:24+00:00 version | 2.3.0b1 class | feature edition | cee component | multisite level | 1 compatible | yes The Top list dashlet displays the top (or bottom) X values of a selected metric. The number of values can be selected, but is limited to 50 values.

7 months

[2.3.0] Checkmk Werk 16376 created: DCD: Not respecting "Validity of missing data" setting

by Checkmk werks level 1

[//]: # (werk v2) # DCD: Not respecting "Validity of missing data" setting key | value ---------- | --- compatible | yes version | 2.3.0b1 date | 2024-01-23T14:05:03+00:00 level | 1 class | fix component | checks edition | cre This fixes disappearing hosts in case of temporarily missing data around the time when a cleanup background job is run (around midnight). In case a piggybacked host temporarily did not receive any data while the background (cron) job <code>cmk --cleanup-piggyback</code> was executed, a subsequent run of the DCD would not respect the "Validity of missing data" setting, wrongly removing the affected host from the monitoring configuration.

7 months

← Newer
1
...
10
11
12
13
14
15
16
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 February 2024