Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1345 discussions

[2.4.0] Checkmk Werk 16566 created: Standardize notification spooler log level configuration

by Checkmk werks level 2

[//]: # (werk v2) # Standardize notification spooler log level configuration key | value ---------- | --- date | 2024-09-02T09:16:08+00:00 version | 2.4.0b1 class | fix edition | cee component | notifications level | 2 compatible | yes The notification spoolers log level was configured differently than other services. Previously users had the choice between: * Normal logging (only startup, shutdown and errors) * Verbose logging (also spooled notifications) * Debugging (log every single action) This was changed to the standard log levels which we also use in all other services. The command line flag `-v` of the `mknotifyd`, which could be used to override the configured log level was replaced with the `--log-level=LEVEL` argument. While the change to this command line flag is an incompatible change, we don't rate this as a change that is worth marking the werk to be incompatible. In the end it's only an option used for manual debugging.

4 days, 12 hours

[2.4.0] Checkmk Werk 16565 created: Introduce distributed tracing of Checkmk

by Checkmk werks level 2

[//]: # (werk v2) # Introduce distributed tracing of Checkmk key | value ---------- | --- date | 2024-08-09T06:32:56+00:00 version | 2.4.0b1 class | feature edition | cre component | core level | 2 compatible | yes With this change, we aim to improve our capabilities as Checkmk developers to understand the performance and behavior of Checkmk in a distributed environment better. This will help us to identify issues and bottlenecks and improve the performance of Checkmk in the future. Besides logging, metrics and profiling, it is another tool which gives us great insights. This change is not meant as a new user feature, e.g. to do distributed tracing of another software with Checkmk. Nevertheless, we feel it makes sense to document it here so that you are aware of it when you see the new related configuration options. ## Goal & requirements Developers can get easier and better insights into complex and large-scale production and test environments of Checkmk. 1. The solution shall be usable in a production environment without major performance impact. 2. No extra complex setup, such as installation of software in addition to Checkmk, shall be required for the traces to be captured and visualized. 3. The solution shall capture execution steps and collect timing information of them. 4. For each invocation of these program flows a supporter can visualize traces including the nested spans across components. 5. The data can be visualized right in the production environment. 6. No data is sent to any external system except it is explicitly configured by the user. ## High level concept We use OpenTelemetry as the underlying technology for distributed tracing. The Checkmk applications are instrumented to send traces. Those traces are sent to a collector, which is running in every Checkmk site or just in the central site, in case of a distributed Checkmk environment. This collector is Jaeger, which is a popular open-source distributed tracing tool. The traces are stored in memory and can be viewed in the Jaeger UI. ## Configuration Sending and receiving traces is configured through `omd config`. The two options `TRACE_RECEIVE` and `TRACE_SEND` are used to enable or disable the receiving and sending of traces. The `TRACE_RECEIVE` option will tell the Checkmk applications to send traces via OTLP to a collector, which can be the local Jaeger instance or any other OTLP collector of your choices. The option `TRACE_SEND` enables the sites local Jaeger instance. The site apache enables the exposure of the Jaeger UI via `http://checkmkhost/site_id/jaeger/`. ## Example If you have just one site and want to enable tracing, set `TRACE_RECEIVE` to `on`. Secondly set `TRACE_SEND` to on and set `TRACE_SEND_TARGET` to `local_site`. Then start your site again. You can now access the Jaeger UI via the URL `http://checkmkhost/site_id/jaeger/`. After a few seconds you should see the first traces in the UI. In a distributed setup, you would enable `TRACE_RECEIVE` on the central site and `TRACE_SEND` on all other sites and point `TRACE_SEND_TARGET` to the central site's collector (`TRACE_RECEIVE_ADDRESS:TRACE_RECEIVE_PORT`). Even if tracing is not much overhead locally, and of course some overhead in the distributed setup, because the traces need to be sent to the central site, we recommend enabling tracing only when you need it and disable it again when you don't need it anymore.

1 week, 3 days

[2.4.0] Checkmk Werk 17056 created: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk werks level 2

[//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`.

1 week, 3 days

[2.4.0] Checkmk Werk 16846 adapted: The custom instances of the MS SQL Server plugin are configured correctly

by Checkmk werks level 2

Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 version | 2.4.0b1 class | fix edition | cee component | checks level | 2 compatible | yes Previously, configuring custom instances, WATO used wrong key names: `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, If you are using custom instances you need to bake and deploy new agent package ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) - # The custom instances of the MS SQL Server plugin are configured correctly ? - + # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 - version | 2.3.0p12 ? ^ ^ - + version | 2.4.0b1 ? ^ ^ class | fix edition | cee component | checks level | 2 compatible | yes Previously, configuring custom instances, WATO used wrong key names: - `conn` instead of a correct `connection` and `auth` instead of ? - + `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, - If you are using custom instances you need to bake and deploy new ? - + If you are using custom instances you need to bake and deploy new agent package

1 week, 3 days

[2.1.0] Checkmk Werk 14101 adapted: Add InfluxDB exporter

by Checkmk werks level 2

Werk 14101 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Add InfluxDB exporter Class: feature Compatible: compat Component: wato Date: 1650970100 Edition: cee Knowledge: undoc Level: 2 Version: 2.1.0b7 With Checkmk 2.1 we introduce the new option to configure InfluxDB connections. With this option you are able to send metrics directly from Checkmk to the REST-API of InfluxDB. More information on how to configure the connection can be found here: https://docs.checkmk.com/master/en/metrics_exporter.html Please note: The integration is only compatible with InfluxDB 2.0 or later. If you're using InfluxDB <= 1.8 you need to use the option "Send metrics to Graphite" as described in the Checkmk docs. ------------------------------------<diff>------------------------------------------- Title: Add InfluxDB exporter Class: feature Compatible: compat Component: wato Date: 1650970100 Edition: cee Knowledge: undoc Level: 2 - Version: 2.1.0b1 ? ^ + Version: 2.1.0b7 ? ^ With Checkmk 2.1 we introduce the new option to configure InfluxDB connections. With this option you are able to send metrics directly from Checkmk to the REST-API of InfluxDB. More information on how to configure the connection can be found here: https://docs.checkmk.com/master/en/metrics_exporter.html Please note: The integration is only compatible with InfluxDB 2.0 or later. If you're using InfluxDB <= 1.8 you need to use the option "Send metrics to Graphite" as described in the Checkmk docs.

1 month, 1 week

[2.2.0] Checkmk Werk 15714 adapted: Add support for Checkmk Appliance 1.7+

by Checkmk werks level 2

Werk 15714 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Add support for Checkmk Appliance 1.7+ Class: feature Compatible: compat Component: distros Date: 1701285077 Edition: cre Level: 2 Version: 2.2.0p16 ------------------------------------<diff>------------------------------------------- Title: Add support for Checkmk Appliance 1.7+ Class: feature Compatible: compat Component: distros Date: 1701285077 Edition: cre Level: 2 - Version: 2.2.0p17 ? ^ + Version: 2.2.0p16 ? ^ -

1 month, 1 week

[2.2.0] Checkmk Werk 14875 adapted: shadow hosts custom attributes doesn't disappear anymore

by Checkmk werks level 2

Werk 14875 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: shadow hosts custom attributes doesn't disappear anymore Class: fix Compatible: compat Component: config Date: 1666099210 Edition: cee Knowledge: doc Level: 2 Version: 2.2.0b1 Previously, shadow hosts custom attributes were ignored during config generation. With this release the problem has been eliminated. ------------------------------------<diff>------------------------------------------- Title: shadow hosts custom attributes doesn't disappear anymore Class: fix Compatible: compat Component: config Date: 1666099210 Edition: cee Knowledge: doc Level: 2 - Version: 2.1.0p15 ? ^ ^ - + Version: 2.2.0b1 ? ^ ^ - Previously, shadow hosts custom attributes were ignored during ? - + Previously, shadow hosts custom attributes were ignored during config generation. With this release the problem has been eliminated. -

1 month, 1 week

[2.3.0] Checkmk Werk 15714 adapted: Add support for Checkmk Appliance 1.7+

by Checkmk werks level 2

Werk 15714 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Add support for Checkmk Appliance 1.7+ Class: feature Compatible: compat Component: distros Date: 1701285077 Edition: cre Level: 2 Version: 2.3.0b1 ------------------------------------<diff>------------------------------------------- Title: Add support for Checkmk Appliance 1.7+ Class: feature Compatible: compat Component: distros Date: 1701285077 Edition: cre Level: 2 - Version: 2.2.0p17 ? ^ ^ - + Version: 2.3.0b1 ? ^ ^ -

1 month, 1 week

[2.3.0] Checkmk Werk 16846 adapted: The custom instances of the MS SQL Server plugin are configured correctly

by Checkmk werks level 2

Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 version | 2.3.0p12 class | fix edition | cee component | checks level | 2 compatible | yes Previously, configuring custom instances, WATO used wrong key names: `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, If you are using custom instances you need to bake and deploy new agent package ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 - version | 2.3.0p11 ? ^ + version | 2.3.0p12 ? ^ class | fix edition | cee component | checks level | 2 compatible | yes Previously, configuring custom instances, WATO used wrong key names: `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, If you are using custom instances you need to bake and deploy new agent package

1 month, 2 weeks

[2.3.0] Checkmk Werk 16846 adapted: The custom instances of the MS SQL Server plugin are configured correctly

by Checkmk werks level 2

Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 version | 2.3.0p11 class | fix edition | cee component | checks level | 2 compatible | yes Previously, configuring custom instances, WATO used wrong key names: `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, If you are using custom instances you need to bake and deploy new agent package ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) - # WATO configures correctly custom imstances for MS SQL Server plugin + # The custom instances of the MS SQL Server plugin are configured correctly key | value ---------- | --- date | 2024-07-19T11:09:57+00:00 version | 2.3.0p11 class | fix edition | cee component | checks level | 2 compatible | yes - Previously, configuring custom instances, WATO used wrong names: + Previously, configuring custom instances, WATO used wrong key names: ? ++++ `conn` instead of a correct `connection` and `auth` instead of a correct `authentication`. With this release the problem has been eliminated, If you are using custom instances you need to bake and deploy new agent package

1 month, 2 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2