ID: 8129
Title: Create log entries for acknowledgements in monitoring log
Component: cmc
Level: 2
Class: New feature
Version: 1.2.7i1
When an acknowledgement is being created or removed or an acknowledgement
ends because of a state change or expires then now an entry in made in
the monitoring log. Example:
F+:var/check_mk/core/history
[1420818703] HOST ACKNOWLEDGE ALERT: xyserver12;STARTED;omdadmin;Some comment...
F-:
These entries are visiable via Multisite and via Livestatus. This only works
with the CMC.
ID: 8130
Title: Omit output of path information in agent bakery if paths are at default settings
Component: agents
Level: 1
Class: Bug fix
Version: 1.2.7i1
ID: 8124
Title: Avoid configuration changes to be become active without activate changes
Component: config
Level: 2
Class: Bug fix
Version: 1.2.7i1
The Check_MK keepalive mode, which is used for the Check_MK helpers and for the
RRD creation helper, now uses a new method for reading the configuration from
<tt>main.mk</tt>, the other <tt>*.mk</tt> files and the <tt>autochecks</tt>. This
new method has two advantages:
<ul>
<li>Changes done to <tt>*.mk</tt> files can no longer become active unless they
are activated. This even holds for core or server restarts and for crashed check
helpers</li>
<li>Check helpers and RRD helper do not any longer need to restart themselves
after a configuration change but simply reload the changed configuration. This
has a muss smaller CPU footprint when activating changes.</li>
<li>Autochecks files are now only read for the host that is currently being
delt with. This makes the internal check table much smaller and speeds
configuration reloads.</li>
</ul>
The gross result is that configuration changes are now really automic and
also faster.
H2:Implementation details
Whenever you create the configuration for the core (options <tt>-B</tt>, <tt>-O</tt>,
<tt>-R</tt> or <tt>-U</tt> or <i>Activate Changes</i> via WATO) then the complete
configuration (the result from parsing <tt>main.mk</tt> and friends) is written to
the file <tt>var/check_mk/core/config.mk</tt>. The core then triggers the check
helpers for configuration reload. The helpers simply re-read that file and are
immediately up-to-date. At the same time copies (hard links) of the autochecks
files in <tt>var/check_mk/autochecks</tt> are being created in <tt>var/check_mk/core/autochecks</tt>.
These files are used during the monitoring.
Note: The <i>Discovery</i> check (formerly known as <i>Inventory<i> check) does <i>not</i>
use the activated configuration but still that one that is modified via WATO. That way
after doing a service discovery the discovery check will immediately be happy - without
a core restart. This is just as it used to be.
ID: 8125
Title: Fix invalid number of Alert statistics view when exported as PDF
Component: Reporting & Availability
Level: 2
Class: Bug fix
Version: 1.2.7i1
The reason was that internally a limit on the number of raw lines from
the log query was imposed. This has been fixed.
ID: 8121
Title: View PDF exports now have context infos in title
Component: Reporting & Availability
Level: 1
Class: Bug fix
Version: 1.2.7i1
The title of the PDF was showing the original view title
without user localization or context related information like
the name of the host.
ID: 8122
Title: Disabling host checks is now working correctly
Component: cmc
Level: 1
Class: Bug fix
Version: 1.2.7i1
In previous versions, when the user disabled the host checks,
it only stopped sending out ICMP requests. Processing incoming
ICMP packets and marking host as down in case of too long time
without answer still resulted in hosts getting marked as critical.
This has been fixed now. The host state won't change anymore when
disabled.
ID: 8117
Title: The "Check_MK Discovery" service is executed in a much more performant way
Component: cmc
Level: 2
Class: Bug fix
Version: 1.2.7i1
The "Check_MK Discovery" check was executed as active check, initializing the whole
python interpreter, check_mk and the whole check_mk configuration for each check,
just to perform an inventory check for a single host.
Now the "Check_MK Discovery" service also uses the permanently running Check_MK
Helper processes just like the regular Check_MK service which results in a big
performanc boosts for environments with a large number of hosts using the
"Check_MK Discovery" service.