Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# WATO configures correctly custom imstances for MS SQL Server plugin
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.3.0p17
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong 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
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
- version | 2.3.0p16
? ^
+ version | 2.3.0p17
? ^
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong 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
[//]: # (werk v2)
# Make Synthetic Monitoring available on Linux
key | value
---------- | ---
date | 2024-09-17T11:45:40+00:00
version | 2.4.0b1
class | feature
edition | cee
component | checks
level | 2
compatible | yes
Synthethic monitoring is now available for deployment on Linux systems. Previously, only Windows
systems were supported. In terms of functionality, there is one difference between Linux and
Windows: Testing applications on the Desktop is not supported on Linux systems. All other
functionality is available on both systems.
[//]: # (werk v2)
# Synthetic Monitoring: Re-work Keyword Monitoring
key | value
---------- | ---
date | 2024-09-17T09:43:05+00:00
version | 2.4.0b1
class | feature
edition | cee
component | checks
level | 2
compatible | no
Version 2.3 offered the option to monitor the runtime of Robot Framework (RF) keywords. This was
possible via the option _Maximum Keyword runtime_ in the ruleset _Robotmk test_. However, this
option was hard to use because the resulting metric names were not robust to modifications of
the test definition. Moving, adding or deleting keywords resulted in shifting metric names, which
rendered the recorded metric histories hard to interpret.
To address this issue, the monitoring of keywords (formerly as an accessory to test monitoring)
has been expanded into an independent Key Performance Indicator (KPI) monitoring in version 2.4. The
option _Maximum Keyword runtime_ has been removed from the _Robotmk test_ ruleset. Instead, Checkmk
now offers two distinct mechanisms for monitoring KPIs:
1. **Pattern-based approach**: There is a new service discovery ruleset called _Robotmk KPI
discovery_. This ruleset offers the option to discover keywords based on regular expressions.
However, contrary to before, the matched RF keywords must be unique per RF test. Furthermore, each
matched keyword now results in a separate service.
2. **Marker-based approach**: To overcome the limitation of unique keywords per RF test, version 2.4
additionally introduces the option to mark RF keywords directly in the test definitions as KPIs to
be monitored by Checkmk. To this end, we introduce a
[dedicated RF keyword library](https://pypi.org/project/robotframework-robotmklibrary). For now,
this library exposes one keyword only, namely `Monitor Subsequent Keyword Runtime`. This keyword
marks the subsequent keyword as a KPI that will be monitored with a separate service by Checkmk.
Users can optionally specify an identifier for this KPI that will be used in the corresponding
service name. This enables monitoring multiple KPIs that are based on the same underlying RF
keyword.
In both cases, thresholds for the KPI runtime are configurable via the new ruleset _Robotmk KPI
monitoring_.
These changes are marked as incompatible because no automatic migration from 2.3 to 2.4 is possible.
When updating to 2.4, the patterns previously configured below the _Maximum Keyword runtime_ option
will be dropped.
[//]: # (werk v2)
# WATO configures correctly custom imstances for MS SQL Server plugin
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.3.0p16
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong 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
[//]: # (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.
[//]: # (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.
[//]: # (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`.
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
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.
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
? ^
-