Checkmk werks level1 May 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
549 discussions

[2.3.0] Checkmk Werk 16015 created: ldap & saml: resolve error when connection config is edited or created

by Checkmk werks level 1

Title: ldap & saml: resolve error when connection config is edited or created Class: fix Compatible: compat Component: wato Date: 1690532069 Edition: cme Knowledge: doc Level: 1 Version: 2.3.0b1 Prior to this werk, Checkmk raised an error in the following cases: LI: when the user attempted to create a LDAP connection with a config with the customer option set to "Global" LI: when the user attempted to change a LDAP connection config with the customer option set to "Global" LI: when the user attempted to create a SAML connection config LI: when the user attempted to delete an existing SAML connection config This werk resolves these issues and Checkmk will not throw an error anymore.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16339 created: mtr: Fix section parsing error

by Checkmk werks level 1

[//]: # (werk v2) # mtr: Fix section parsing error key | value ---------- | --- date | 2024-02-25T22:30:51+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When the mtr section contained a line that started with `**ERROR**`, the parsing of the section failed. This has now been fixed. The lines starting with `**ERROR**` will be ignored.

3 months, 3 weeks

[2.3.0] Checkmk Werk 14223 created: Introduced topology visualization

by Checkmk werks level 1

[//]: # (werk v2) # Introduced topology visualization key | value ---------- | --- date | 2024-02-25T15:22:55+00:00 version | 2.3.0b1 class | feature edition | cee component | multisite level | 2 compatible | yes The topology visualization is a new feature that allows the visualization of complex interconnected networks. A simple example for this visualization is the parent/child topology. The new mechanism that comes with this werk allows the linking of external data with the data of the monitoring core. When it comes to the display, you simply define some starting points via the filter form. Based on these, the topology visualization then builds a mesh of incoming and outgoing connections. The type of external data might be * Netstat, showing connections between the interfaces/ips/ports * LLDP/CDP, showing the network neighbors There is a common data format specification for all external data. So you just can create your own data file which provides information about the relationships between hosts, services or generic objects which are not linked to the core. If you drop this file into a specific folder, the visualization will handle the rest. There is no need to write python code. Right now you can configure * Objects - either linked to an entity in the core or some standalone object * Icons/emblems which should be added to the object * Connections between objects * Line style/color of specific connections Since this is a quite visualization heavy topic and hard to explain only via text, feel free to check out the [thread](https://forum.checkmk.com/t/network-visualization-now-in-version-2-… in our checkmk forum We will also publish a blog article in the coming weeks ``` Important: The visualization only works if external data is provided in a special folder. At the moment these are not created by Checkmk, but come from external MKP developments. ```

3 months, 3 weeks

[2.3.0] Checkmk Werk 16529 created: EC: fix a wrong message on a matched rule

by Checkmk werks level 1

[//]: # (werk v2) # EC: fix a wrong message on a matched rule key | value ---------- | --- date | 2024-02-23T08:14:30+00:00 version | 2.3.0b1 class | fix edition | cee component | ec level | 1 compatible | yes Previously, the tooltip on a matched rule would say it is a cancelling rule. This message was misleading and was changed.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16521 created: bi_rule: schema update to match the api docs

by Checkmk werks level 1

[//]: # (werk v2) # bi_rule: schema update to match the api docs key | value ---------- | --- date | 2024-02-19T14:34:33+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no The Open API schema previously did not reflect the response or the request schema format that was required to create or show BI rules. This werk addresses this issue. Previously, when creating or getting a BI rule, via the REST-API, the schema for host_label_groups or service_label_groups looked similar to the following: ``` "host_label_groups": [ [ "and", [ ["and", "mystery/switch:yes"], ["or", "mystery/switch:no"], ], ], ] ``` This did not match the schema documented in the Open API docs. To fix this, we have now changed the format to the following ``` "host_label_groups": [ { "operator": "and", "label_group": [ {"operator": "and", "label": "mystery/switch:yes"}, {"operator": "or", "label": "mystery/switch:no"}, ], }, ] ``` This also aligns with other endpoints that use our new host_label_groups or service_label_groups, for example the rules endpoints. As this is a breaking change, user scripts should be adjusted accordingly.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16492 created: netapp_ontap_info: enhanced presentation of NetApp system information

by Checkmk werks level 1

[//]: # (werk v2) # netapp_ontap_info: enhanced presentation of NetApp system information key | value ---------- | --- date | 2024-02-15T10:04:03+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The version and hardware information for a NetApp system was only displayed for the first retrieved node. With this werk we now display information for each retrieved node.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16371 created: sla: range field for predefined_time_range parameter is mandatory

by Checkmk werks level 1

[//]: # (werk v2) # sla: range field for predefined_time_range parameter is mandatory key | value ---------- | --- date | 2024-02-23T08:00:57+00:00 version | 2.3.0b1 class | fix edition | cee component | rest-api level | 1 compatible | yes Before this werk, when the sla was computed for a predefined time range without specifying the range field, an error status 500 Internal Server Error was returned. This werk solves the problem by checking for the existence of the range field, and if it does not exist, the endpoint returns an error status 400 - Bad Request.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16170 created: snmp: Store OID cache per context group

by Checkmk werks level 1

[//]: # (werk v2) # snmp: Store OID cache per context group key | value ---------- | --- compatible | yes version | 2.3.0b1 date | 2024-02-07T09:54:40+00:00 level | 1 class | fix component | checks edition | cre SNMP caching didn't take contexts in consideration when storing OID data. This led to the same result being reported for the OID in different sections even if sections use different contexts. Now, SNMP caching stores fetched OID data for every group of contexts it was called with.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16524 created: apidocs: improve the request/response examples

by Checkmk werks level 1

[//]: # (werk v2) # apidocs: improve the request/response examples key | value ---------- | --- date | 2024-02-21T11:07:55+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previously the requests and urllib examples were hard coded to show the same response samples and the same response status codes in the request samples. This werk addresses this issue by showing the correct possible status codes for each endpoint.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16085 created: Agent Updater: Better detection of underlying platform

by Checkmk werks level 1

[//]: # (werk v2) # Agent Updater: Better detection of underlying platform key | value ---------- | --- date | 2024-02-21T10:36:36+00:00 version | 2.3.0b1 class | fix edition | cee component | agents level | 1 compatible | yes Previously, the agent updater used to detect the underlying platform, in terms of the combination of OS and package manager (e.g., Linux + RPM), automatically by scanning for certrain directories. As multiple package managers may be available on one system, this sometimes lead to unexpected behavior on agent updates when the update mechanism decided to switch to a different platform. Now, the platform will be specified by a file that comes with the agent installation, and the agent updater will rely on this static information instead of the dynamic detection.

3 months, 3 weeks

← Newer
1
...
39
40
41
42
43
44
45
...
55
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 May 2024