ID: 14175
Title: Setup/Move folder: Fixed unknown folder exception after moving folder
Component: Setup
Level: 1
Class: Bug fix
Version: 2.2.0i1
Moving a folder always lead to an exception stating the location of the target folder was not found.
The actual move operation always worked.
However, this exception prevented an entry in the audit log and the <tt>Activate changes</tt> page showed no changes to be activated on any site.
ID: 14567
Title: KUBE agent_kube: Handle custom Pod condition on GKE
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
Previously, the Kubernetes special agent would exit with the following message:
C+:
[special_kube] Agent exited with code 1: Can not convert to timestamp: 'None' of type <class 'NoneType'>
C-:
This would occur if there was a custom Pod condition present in the cluster with type
<tt>cloud.google.com/load-balancer-neg-ready</tt>. With this werk, the error no longer occurs.
ID: 15011
Title: email notifications set auto submitted headers
Component: Notifications
Level: 1
Class: New feature
Version: 2.2.0i1
When we send a notification email to a recipient that set an "out of office" reply an automatic response would be
created by the receiver. This is suppressed now. To achieve this notification emails now set the following headers.
LI: Auto-Submitted, see RFC 3834
LI: X-Auto-Response-Suppress, see MS Exchange documentation
ID: 14829
Title: Monitoring of Elasticsearch indices: Rework grouping of individual indices
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
Elasticsearch can be configured to automatically add a timestamp to index names, see
<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/date-index-…" target="_blank">the documentation</a>.
This results in index names such as my-index-2018.09.12, my-index-2018.09.13, my-index-2018.09.14
etc. In Checkmk, users will most likely not want to monitor such indices as individual services.
Instead, users want to monitor a service called "my-index", which accumulates data accross the
individual sub-indices.
Before this werk, Checkmk identified matching indices by cutting off index names after the first
"-". This is far too restrictive. For example, the indices "customer-a" and "customer-b" were
accumulated into one combined index called "customer", which is most likely unwanted. Also, this
grouping was not configurable.
As of this werk, Checkmk no longer does any grouping by default. Instead, the grouping can now be
configured via the discovery ruleset <i>Discovery of Elasticsearch indices</i>. See the help texts
in the user interface for details regarding the configuration options.
This werk is marked as incompatible because it will result in changed service configurations (new
and vanished services) if the index names contain "-". Using the new discovery ruleset, users can
however reproduce the old behaviour before this werk. This can be achieved by grouping indices
according to the regular expression <tt>[^-]+</tt>.
ID: 12525
Title: Improve label colors
Component: Multisite
Level: 1
Class: Bug fix
Version: 2.2.0i1
For the violet <i>explicit</i> labels the label color was too dark in the dark theme and the font color too dark in the light theme. Both stylings are fixed.
ID: 14972
Title: mk_oracle.ps1: Oracle SID not correctly set as connection property "TNS alias"
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
The agent plugin for Oracle on Windows, "mk_oracle.ps1", is able to connect to
multiple Oracle instances. If the plugin was configured to connect to these
instances with a specific user, the Oracle SID was not included in the settings
for TNS alias, which meant the plugin could not connect to the relevant
instances. This has been fixed.
ID: 14880
Title: kube_cronjob_status: remove exception raise when job has more than one pod
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
Prior to this werk, the check kube_cronjob_status raised an error when the job
had multiple pods. This werk removes this restriction but does not change the
behaviour that only the latest pod is used to determine the status.
ID: 13963
Title: REST API will no longer fail handling folders with the "bake agent package" attribute
Component: REST API
Level: 1
Class: Bug fix
Version: 2.2.0i1
The endpoints regarding folders would fail with a 500 status code if a folder had the "bake agent package" attribute set.
This is no longer the case.