ID: 5531
Title: New WATO page "Best practices" can be used to find things to improve in your Check_MK
Component: WATO
Level: 2
Class: New feature
Version: 1.5.0i1
The new WATO page "Best practices" is meant to give you hints about your Check_MK installation
and the things you could improve in terms of performance, reliabilty and security.
In the moment you open the page, it starts analyzing your Check_MK installation and executes
different tests. Test may detect that a thing is OK and report the test to be OK. Other
tests may result in WARN state in case you could be interested in changing something.
Other tests may report a CRIT state in case we think that you have a critical situation which
should be fixed for a completely working Check_MK setup.
Please note that this feature and the implemented tests are still in an early phase of
development. Understand the test results as pointer on things you should check.
Each of the tests can be acknowledged just for a single site or all your sites. In case you
came to the decision that a reported problem is not really a problem for you, you can
acknowledge the test results.
In case you fix a problem, you won't need to acknowledge it. Just open up the page again,
which should then turn your test into OK.
ID: 5262
Title: Fix bug in agent bakery (regression #5261, since 1.4.0p17)
Component: agents
Level: 2
Class: Bug fix
Version: 1.5.0i1
Werk #5261 introduced a bug that made it impossible to bake new agents for some specific rulesets.
This would result in error messages like the following:
<pre>
"TypeError: key ('custom', 'win_certificates/lib/local/win_certificates.ps1') is not a string"
</pre>
After an update, no further action is required.
ID: 5435
Title: Fixed "omd update" problems when updating from 1.4.0p17 or older
Component: Site Management
Level: 2
Class: Bug fix
Version: 1.5.0i1
When executing "omd update" as site user to update a site from 1.4.0p17
or older an error could occur blocking the update. The message looks like
this:
<pre>
Traceback (most recent call last):
File "/omd/versions/1.4.0p17.cee/bin/omd", line 52, in <module>
import tarfile, fnmatch
File "/omd/versions/1.4.0p17.cee/lib/python2.7/tarfile.py", line 52, in <module>
import copy
File "/omd/versions/1.4.0p17.cee/lib/python2.7/copy.py", line 52, in <module>
import weakref
File "/omd/versions/1.4.0p17.cee/lib/python2.7/weakref.py", line 14, in <module>
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
</pre>
This issue was caused by a mixup of python versions during the update which has
been fixed now by using the correct libraries during the update.
To workaround this issue, you could run the "omd update" command as root user instead
of the site user.
ID: 5429
Title: Fixed broken event history expiration (when using default settings)
Component: Event Console
Level: 2
Class: Bug fix
Version: 1.5.0i1
The Event Console was not deleting outdated entries from the event history.
With the default settings it is intended to delete entries older than 365
days from the EC archive. This did not work.
A message like this can be found each "Housekeeping interval", normaly 1 minute:
[1509618281.352829] Error expiring log files: year out of range
This time window can be configured with the setting "Event history lifetime".
As a workaround you can simply open this setting and save it with the default
value. This will make the event deletion work as expected.
When you are affected, this may result in a way too huge Event Console archive
directory (<tt>~/var/mkeventd/history</tt>) which may result in slow
"Event Console History" views (depends on your filtering). You could clean up
the archive directory by hand to improve the situation.
After applying the update, the next housekeeping run will clean up all your old
archived events.
ID: 5359
Title: Reduced size of PDF exports containing graphs
Component: Reporting & Availability
Level: 2
Class: Bug fix
Version: 1.5.0i1
The size of PDF exports increased dramatically when graphs were shown. This
was caused by the gradients used in the rendered metric areas.
For example a PDF with 10 graphs had a size of 6 MB with gradients compared
to 260 KB without gradients. The gradients have now been dropped completely.
ID: 5363
Title: Exporting graph data in JSON format via GUI is now possible
Component: Multisite
Level: 2
Class: New feature
Version: 1.5.0i1
When viewing a graph in the GUI it is now possible to open the context menu
and click on "Export as JSON" to get the data that is shown in the graph as
JSON output.
ID: 5234
Title: Fixed recently introduced issue with non working WATO rules
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.5.0i1
In 1.4.0p14 an internal caching mechanism was changed.
This broke some caches and caused unexpected behaviours,
because most configurable rules were considered as empty.
ID: 5392
Title: Fixed host monitored from all sites after editing custom host attributes
Component: WATO
Level: 2
Class: Bug fix
Version: 1.5.0i1
In distributed environments it could happen that all configured hosts are monitored
from all configured sites.
The now fixed issue was triggered by saving (adding/editing/removing) custom host attributes
using the "WATO > Hosts > Custom host attributes" dialog.
Background: This editing step was undeclaring the internal "site" attribute by accident
and rewriting all hosts.mk files. These files were missing the "site:..." host tag in the
all_hosts data structure. This makes all sites think that they are responsible for these
hosts.
The configured site information of the hosts/folders was not lost because it was retained
in the host_attributes data strucuture. So the hosts.mk files could be "repaired" by
saving the hosts, parent folders or host tags.
ID: 5397
Title: Microcore can now be configured to send UNREACHABLE notifications
Component: Core & setup
Level: 2
Class: New feature
Version: 1.5.0i1
Normally you don't want to receive UNREACHABLE notifications of hosts. Configuring
client/parent relationships between your hosts is a good idea to be able to
detect network outages. DOWN states of hosts will then be translated into UNREACHABLE,
making your view clear for the real cause (e.g. a router in DOWN state).
But there may be situations where you want to be able to receive these UNREACHABLE
notifications. This was already configurable when using the Nagios core for a long
time. For the Microcore the suppression of UNREACHABLE notifications was hard coded.
This has been changed now.
The default behaviour will not be changed. New sites or updates sites will not send
out UNREACHABLE notifications by default. To enable the new feature, you will first
have to tell the core to send out UNREACHABLE notifications.
To have a seamless transition we additionally changed these things:
<ul>
<li>A default rule that disables the UNREACHABLE notifications is being created
for new sites in the ruleset "Notified events for hosts". Whenever you want
to enable UNREACHABLE notifications, simply enable them using this rule.</li>
<li>Updated sites:
<ul>
<li>If you have configured rules for all your hosts in the
"Notified events for hosts" ruleset, the core will continue working
as configured.</li>
<li>Microcore: For hosts that have no matching rule in "Notified events for hosts",
the Microcore will <i>not send</i> out UNREACHABLE notifications.</li>
<li>Microcore: If you previously had configured a rule in "Notified events for hosts"
which enabled the UNREACHABLE notifications, this rule had no effect. It will now
be working after updating.</li>
<li>Nagios: For hosts that have no matching rule in "Notified events for hosts",
the Nagios core will <i>send</i> out UNREACHABLE notifications.</li>
</ul>
</li>
</ul>