Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15865 discussions

[2.3.0] Checkmk Werk 17229 created: CPU utilization checking: Alert if utilization is exactly at threshold for too long

by Checkmk werks level 1

[//]: # (werk v2) # CPU utilization checking: Alert if utilization is exactly at threshold for too long key | value ---------- | --- date | 2024-08-07T07:03:40+00:00 version | 2.3.0p13 class | fix edition | cre component | checks level | 1 compatible | yes Many CPU utilization checks can be configured to alert if the utilization is too high for too long (configuration options _Levels over an extended time period on total CPU utilization_ and _Levels over an extended time period on a single core CPU utilization_). Before, Checkmk alerted only if the utilization was above the threshold for too long. As of this werk, Checkmk alerts if the utilization is above or exactly at the threshold for too long. This is consistent with the general behavior of Checkmk to check against upper thresholds with a "greater than or equal to" operation.

3 weeks, 1 day

[2.3.0] Checkmk Werk 17226 created: Fix ValueErrors when rendering graphs

by Checkmk werks level 1

[//]: # (werk v2) # Fix ValueErrors when rendering graphs key | value ---------- | --- date | 2024-08-05T18:01:16+00:00 version | 2.3.0p13 class | fix edition | cre component | multisite level | 1 compatible | yes In certain cases, rendering graphs crashed with a `ValueError` such as ``` Traceback (most recent call last): ... File "...", line 615, in _compute_labels_from_api raise ValueError((min_y, max_y)) ValueError: (0.0, 1.75828125) ```

3 weeks, 1 day

[2.3.0] Checkmk Werk 17205 created: agent_netapp_ontap: KeyError: 'rpm' and KeyError: 'temperature'

by Checkmk werks level 1

[//]: # (werk v2) # agent_netapp_ontap: KeyError: 'rpm' and KeyError: 'temperature' key | value ---------- | --- date | 2024-08-01T14:51:58+00:00 version | 2.3.0p13 class | fix edition | cre component | checks level | 1 compatible | yes This change affects users, which monitor NetApp via Ontap REST API. Previously, the special agent could crash with the following error: ``` File "/omd/sites/nyccheckmk2/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 28, in write_section for element in generator: File "/omd/sites/nyccheckmk2/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 471, in fetch_fans rpm=fan["rpm"], ~~^^^^^^^ KeyError: 'rpm'CRIT ``` This would occur, if either a fan or temperature sensor had an error, and thus did not report any rpm/temperature value. This has been fixed.

3 weeks, 1 day

[2.3.0] Checkmk Werk 17225 created: Custom graphs: Respect "Metrics with all zero values" setting

by Checkmk werks level 1

[//]: # (werk v2) # Custom graphs: Respect "Metrics with all zero values" setting key | value ---------- | --- date | 2024-08-05T06:51:13+00:00 version | 2.3.0p13 class | fix edition | cee component | multisite level | 1 compatible | yes The custom graph setting _Metrics with all zero values_ was not persisted and not taken into account when rendering the graph.

3 weeks, 1 day

[2.3.0] Checkmk Werk 17206 adapted: omd update: Log "Verifying site configuration"

by Checkmk werks level 1

Werk 17206 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # omd update: Log "Verifying site configuration" key | value ---------- | --- date | 2024-08-05T08:59:03+00:00 version | 2.3.0p13 class | fix edition | cre component | omd level | 1 compatible | yes If a user runs `omd update`, then the output is written to both `$OMD_ROOT/var/log/update.log` and stdout. However, the output of site configuration verification <a href="https://checkmk.com/werk/16408"> Werk #16408</a> was missing. This has been fixed. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # omd update: Log "Verifying site configuration" key | value ---------- | --- date | 2024-08-05T08:59:03+00:00 - version | 2.3.0p12 ? ^ + version | 2.3.0p13 ? ^ class | fix edition | cre component | omd level | 1 compatible | yes If a user runs `omd update`, then the output is written to both `$OMD_ROOT/var/log/update.log` and stdout. However, the output of site configuration verification <a href="https://checkmk.com/werk/16408"> Werk #16408</a> was missing. This has been fixed.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16889 adapted: ewon: KeyError (device)

by Checkmk werks level 1

Werk 16889 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # ewon: KeyError (device) key | value ---------- | --- date | 2024-08-06T07:48:07+00:00 version | 2.3.0p12 class | fix edition | cre component | checks level | 1 compatible | yes An existing rule for `check_ewon` without the mandatory key `device` would result in an exception `KeyError (device)`. This change makes the check function use a default, if `device` is not set. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # ewon: KeyError (device) key | value ---------- | --- date | 2024-08-06T07:48:07+00:00 - version | 2.3.0p13 ? ^ + version | 2.3.0p12 ? ^ class | fix edition | cre component | checks level | 1 compatible | yes An existing rule for `check_ewon` without the mandatory key `device` would result in an exception `KeyError (device)`. This change makes the check function use a default, if `device` is not set.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16890 adapted: check_ewon: ValueError (incomplete format)

by Checkmk werks level 1

Werk 16890 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # check_ewon: ValueError (incomplete format) key | value ---------- | --- date | 2024-08-06T07:52:50+00:00 version | 2.3.0p12 class | fix edition | cre component | checks level | 1 compatible | yes Formatting a value with unit `%` would result in an invalid format-string making `check_ewon` crash with an exception `ValueError (incomplete format)`. This change makes `check_ewon` use f-formatting instead of `%`-formatting. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # check_ewon: ValueError (incomplete format) key | value ---------- | --- date | 2024-08-06T07:52:50+00:00 - version | 2.3.0p13 ? ^ + version | 2.3.0p12 ? ^ class | fix edition | cre component | checks level | 1 compatible | yes Formatting a value with unit `%` would result in an invalid format-string making `check_ewon` crash with an exception `ValueError (incomplete format)`. This change makes `check_ewon` use f-formatting instead of `%`-formatting.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16889 created: ewon: KeyError (device)

by Checkmk werks level 1

[//]: # (werk v2) # ewon: KeyError (device) key | value ---------- | --- date | 2024-08-06T07:48:07+00:00 version | 2.3.0p13 class | fix edition | cre component | checks level | 1 compatible | yes An existing rule for `check_ewon` without the mandatory key `device` would result in an exception `KeyError (device)`. This change makes the check function use a default, if `device` is not set.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16890 created: check_ewon: ValueError (incomplete format)

by Checkmk werks level 1

[//]: # (werk v2) # check_ewon: ValueError (incomplete format) key | value ---------- | --- date | 2024-08-06T07:52:50+00:00 version | 2.3.0p13 class | fix edition | cre component | checks level | 1 compatible | yes Formatting a value with unit `%` would result in an invalid format-string making `check_ewon` crash with an exception `ValueError (incomplete format)`. This change makes `check_ewon` use f-formatting instead of `%`-formatting.

3 weeks, 1 day

[2.3.0] Checkmk Werk 17227 created: Synthetic Monitoring: Avoid crash in scheduler (client side) during RCC setup

by Checkmk werks level 1

[//]: # (werk v2) # Synthetic Monitoring: Avoid crash in scheduler (client side) during RCC setup key | value ---------- | --- date | 2024-08-06T05:54:33+00:00 version | 2.3.0p13 class | fix edition | cee component | checks level | 1 compatible | yes In one specific scenario, the Robotmk scheduler crashed during the RCC setup step. This happened if if all plans using RCC were configured to run under a specific user instead of under the system user. Users have to update the agent on affected hosts to benefit from this werk.

3 weeks, 1 day

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1