ID: 5707
Title: Windows: allow eventlog monitoring from multiple hosts
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.5.0i4
Until now, Windows eventlogs could be monitored only from one host (Check_MK
site). Attempting to contact one single Windows agent from multiple hosts lead
to lost eventlog entries as all hosts shared one common state file for storing
the offsets of so far read eventlog entries.
Now the offsets are store in host-IP-specific state files, allowing hosts with
different IP addresses to monitor one single Windows system without loosing
eventlog entries. Note: multiple Check_MK sites running under the one and same
IP address will still suffer from lost eventlog entries as the offsets are
stored per IP address.
ID: 5783
Title: Introduced background jobs for longer running task
Component: WATO
Level: 2
Class: New feature
Version: 1.5.0i4
A new mechanism has been introduced allowing certain tasks to be run as background processes.
Currently the following areas are included
<ul>
<li>Host rennaming</li>
<li>Agent baking (Enterprise Edition)</li>
<li>Report generation (Enterprise Edition)</li>
</ul>
Once a background job is triggered, an overview page provides additional information
regarding the progress. You can also stop and delete background jobs, if applicable.
Keep in mind that some jobs - in detail host renaming and agent baking - lock certain areas
in WATO to prevent further configurations as long the background process is running.
Each background has a working directory located in <tt>~/var/check_mk/background_jobs</tt> with
a statusfile named <tt>jobstatus.mk</tt>. If the background job generates stdout data it will
be shown in the job details page. Job Exceptions are also shown in the details page and, in addition,
written to <tt>~/var/log/web.log</tt>.
Keep in mind, old background jobs will be automatically removed after 30 days or if the maximum amount
of jobs for a job type has been reached. These limits are currently not configurable and hardcoded
<ul>
<li>Reporting has a limit of 100</li>
<li>Host renaming has a limit of 50</li>
</ul>
This cleanup routine is regularly called through a multisite cronjob.
ID: 5744
Title: Export of rule packs in MKP packages
Component: Event Console
Level: 2
Class: New feature
Version: 1.5.0i4
Rule packs of the Event Console can now be exported in MKP packages, i.e. they
can be downloaded, versioned, and shared with other Check_MK installations.
This is e.g. useful in setups with independent instances where rule packs can
now be defined centrally in one instance and distributed to other instances as
predefined packages. For distributed instances the primary mechanism to
synchronize rule packs remains the synchronization via WATO.
To export a rule pack it has to be made exportable by clicking on the
corresponding action in the rule pack overview of the WATO module Event
Console. After that the rule pack is available for MKP export in the WATO
module Extension Packages, i.e. it can be seen in the packaged files when a
package is created or edited. If a rule pack is exported in a MKP it cannot be
deleted directly in the WATO module Event Console anymore and it's ID and title
cannot be changed. The rules of the rule pack can still be modified via the
edit rules menu. If a rule of a MKP rule pack is modified, deleted or a new
rule is created the MKP rule pack becomes a modified MKP rule pack. This means
that the modified version of the rule pack becomes valid, but the exported MKP
rule pack remains unchanged. To synchronize the MKP rule pack with the modified
MKP rule pack there are two options: the modified rule pack can be resetted to
the MKP version or the MKP can be updated by the modified version. Both options
are available via the corresponding action of the rule pack in the WATO module
Event Console.
If a MKP including Event Console rule packs is uploaded to a site the included
rule packs will be added to the end of the existing rule packs. They can be
moved freely between the existing rule packs without changing the MKP.
Furthermore, rule packs provided in a MKP can be enabled and disabled without
restrictions. Note however that the information if a rule pack is enabled or
disabled is persisted in the MKP. This makes it possible to ship e.g. three
rule packs for different versions of a software which are disabled by default.
After uploading the MKP the rule pack for a specific version can be activated.
If a MKP with exported rule packs is deleted the rule packs provided by that
MKP are deleted as well. To keel the rule packs and to remove the MKP the MKP
has to be dissolved. As a result the rule packs that were provided by that MKP
are still available. After dissolving a MKP the rule packs will be exportable.
In a distributed monitoring setup there are the two existing options "Replicate
Event Console configuration to this site" and "Replicate extensions (MKPs and
files in ~/local/)" which have an impact on exportable and exported rule packs.
By enabling the replication of the event console configuration all Event
Console rule packs are synchronized with slave sites, but only by enabling the
replication of MKPs the MKP information of rule packs is synchronized. This has
an implication on the representation and behaviour of rule packs of a slave
sites if the WATO configuration of the slave site is enabled. If for example
only the replication of the event console configuration is enabled the slave
site will show a synchronized MKP rule pack as exportable but not as a rule
pack provided by a MKP. Therefore, rule packs can be provided by the master and
bundled in MKPs by the slave site. If the rule pack export is used it is not
advisable to use the MKP replication without the replication of the Event
Console configuration because the rule packs are provided to the slave in .mk
files, but they WILL NOT be recognized by the Event Console. The preferred
method to share only specific rule packs is to disable both replication options
and to upload MKPs containing these rule packs to the corresponding slave
sites.
To avoid errors in a distributed monitoring setup the rule pack export SHOULD
only be used when ALL slave sites support the MKP rule pack export. If a slave
site does not support the rule pack export either the replication of the Event
Console configuration should be disabled for that site or the export of rule
packs should not be used at all.
ID: 5873
Title: IPMI Management board
Component: Core & setup
Level: 2
Class: New feature
Version: 1.5.0i4
The management board of hosts can now be configured to be monitored via IPMI
as alternative to the previous SNMP monitoring.
To configure the IPMI management board for a host, you need to edit the
host configuration. Set the addresss of the management board, choose IPMI
as management board protocol and specify the IPMI credentials.
After this, you should be able to find new services named "Management interface: ..."
using the service discovery.
To make your configuration a bit less explicit, you can specify the IPMI protocol
and credentials on folders instead of specifying it explicit for each host.
Another option is to use the ruleset "Management board config" to configure the
credentials. But you will have to set at least the protocol on host/folders and
the management board address for each host.