ID: 15638
Title: Predictive Levels: Supress levels for constant values
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 2.3.0b1
This change affects users of the option <tt>In relation to standard deviation</tt> from
<tt>Predictive Levels</tt>.
<tt>Predictive Levels</tt> are computed by considering every data point matching the configured
reference period. If the data never changes across these points in time, then the standard deviation
is zero. Thus, the predicted levels will precisely equal to the predicted value. Previously, this
would result in a CRIT. This happened no matter the levels set via <tt>In relation to standard
deviation</tt>.
While the described behaviour is self-consistent, most of these alarms are undesired and diminish
the usefulness of <tt>Predictive Levels</tt>.
With this Werk, no levels are applied, if the standard deviation is zero.
ID: 15968
Title: host_config: update endpoint now only allows one of replace, update or delete
Component: REST API
Level: 1
Class: Bug fix
Version: 2.3.0b1
Previously when calling update host, you could pass any combination of
replace all attributes
update some attributes
delete some attributes
Some of these combinations didn't make much sense and could lead to
errors. This werk simplifies this by only allowing one of the options
when calling update host or bulk update host.
For update_host, previously you could to the following
C+:
{
"attributes": {"ipaddress": "192.168.9.123"},
"update_attributes" {"ipaddress": "192.168.0.124"},
"remove_attributes": ["tag_foobar],
}
C-:
This werk modifies this behaviour by forcing the client to select only
one action.
C+:
{
"attributes": {"ipaddress": "192.168.9.123"},
}
C-:
OR
C+:
{
"update_attributes": {"ipaddress": "192.168.9.124"},
}
C-:
OR
C+:
"remove_attributes": ["tag_foobar"],
C-:
ID: 16086
Title: Support Diagnostics: Include basic SELinux infos
Component: setup
Level: 1
Class: New feature
Version: 2.2.0p9
The Support Diagnostics dump now includes basic information about SELinux as provided by the command <code>sestatus</code>.
ID: 15941
Title: Fix possible failed notifications on appliances
Component: Notifications
Level: 1
Class: Bug fix
Version: 2.3.0b1
If one of multiple recipients had no Email address configured, sending of the
mail failed with an unhandled exception.
ID: 16077
Title: Agent Bakery: Leftover packages of non-agent hosts
Component: agents
Level: 1
Class: Bug fix
Version: 2.1.0p33
No agent should be assigned to a host when the <i>Checkmk agent / API integrations</i>
host property is configured to <i>No API integrations, no Checkmk agent</i>.
Additionally, whenever a hosts is reconfigured to not being monitored by an agent any longer,
the agent package must be unassigned from this host on next agent bakery call.
Previously, the agent bakery failed to follow these rules, while a slighly different behavior
can be observed for different versions:
In Checkmk 2.0 and Checkmk 2.1, leftover assignments to agent packages aren't cleaned up.
In Checkmk 2.1 and Checkmk 2.2, it's possible to assign agent packages to non-agent hosts
when explicitly called with a host selection.
This happens when baking agents for exlicit hosts on the commandline, and when adding new
hosts via Setup, since the agent bakery automatically creates agents for new hosts.
With this Werk, the agent bakery will follow the mentioned desired behavior.
ID: 15967
Title: event console: add site property to the event console endpoints
Component: REST API
Level: 1
Class: Bug fix
Version: 2.3.0b1
Event console IDs are integers beginning from 1, both for the main site & for
remote sites. This means that the same event console ID can exist on more
than one site at the same time. This caused problems when calling the DELETE
endpoint as we weren't sure which ID the client wanted to delete. To get around
this problem, we have introduced a "site_id" field. The site_id together with
the event console ID combination is unique and therefore solves this issue.
show_event: site_id is now mandatory
show_events: site_id is now optional
update_and_acknowlege: site_id is now mandatory
update_and_acknowledge_multiple: site_id is now optional
change_state: site_id is now mandatory
change_state_multiple: site_id is now optional
archive_events: site_id is now mandatory
ID: 15973
Title: Remove deprecated host label "resource_group" for Azure Resource Group hosts
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.3.0b1
As announced in https://checkmk.com/werk/15261, the "resource_group" host label has been replaced with the label "cmk/azure/resource_group".
Users referencing the old label have to switch to the new one since with this werk, the "resource_group" label will no longer be provided for Azure Resource Group hosts.
ID: 15981
Title: dcd: create, retrieve and delete dynamic host configurations
Component: REST API
Level: 1
Class: New feature
Version: 2.3.0b1
With this werk, the REST API supports the creation of piggyback dynamic host configurations as well as the retrieval and deletion of dynamic host configurations.
ID: 15913
Title: check_disk_smb: Fix rule transform when updating from 2.1.0p30 and lower
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.1.0p33
If the rule 'Check SMB share access' was configured with a defined 'NetBIOS name of the server' in 2.1.0p30 and lower and an update to a higher version was attempted, it caused a rule transform error.
The error looks similar to this:
C+:
-| ERROR: Failed to transform rule: (Ruleset: active_checks:disk_smb, ...) ... is not an allowed value
-| WARNING: Invalid rule configuration detected (Ruleset: active_checks:disk_smb, Title: Check SMB share access, ...)
C-:
This has now been fixed and the transformation of the rule will not cause any problems while updating.
ID: 15637
Title: KUBE: Support Tanzu Kubernetes
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.3.0b1
With this release of Checkmk, we introduce monitoring of Tanzu Kubernetes clusters. The setup is the
same as for vanilla Kubernetes:
LI: direct access to the Kubernetes API server must be provided
LI: optionally, the <tt>Checkmk collectors</tt> can be installed to provide usage data (recommended)
The details can be found in the documentation https://docs.checkmk.com/latest/en/monitoring_kubernetes.html