ID: 1563
Title: Reworked configuration of process monitoring
Component: Checks & Agents
Level: 2
Class: Bug Fix
Version: 1.2.5i7
The configuration of the monitoring of processes has been reworked. This was
mainly to overcome a bug: when the process check was used on a cluster then
the check parameters would be taken randomly from one of the nodes.
The new process monitoring works like this:
H2:Static checks
Statically configured checks are like before. They are configured via the ruleset
<i>State and count of processes</i>.
H2:Checks created by service discovery
The ruleset <i>Process Inventory</i> now does not set parameters (levels)
for the created services anymore. Only the settings for matching process
names and user remain - and of course the service description.
The new ruleset <i>State and count of processes</i> in the section
<i>Parameters for inventorized checks</i> (please do not mix up with static
checks here) is used for defining levels for the count, CPU usage, averaging
and all of the other parameters. The default is to make the check OK if at
least one process is being found. So from now on if you are using process
inventory with custom levels, you need to make configurations in <i>both
rulesets</i>.
On the other hand that can make things easier for you. You might have a lot
of rulesets for detecting various processes but then only need a few rules
for setting levels for these services.
In order to make the migration easier services that have already been created
with previous versions of Check_MK will remain to work as they did. But
after a new service discovery the levels will vanish and then you have to
configure them in the new extra ruleset.
Please note: the ruleset <i>State and count of processes</i> does contain the
settings for matching the process and the user even when used for discovered
checks. The reason is that it is the same ruleset as for manual checks.
Setting these parameters do not make sense here in most cases. Simply leave
them unchecked.
H2:Performance data - ps versus ps.perf
The check <tt>ps.perf</tt> is now deprecated. The normal <tt>ps</tt> check now
does <i>always</i> create performance data. For compatibility reasons the old
<tt>ps.perf</tt> is still defined but does exactly the same as <tt>ps</tt>
ID: 1562
Title: Move manual checks into a new WATO module
Component: WATO
Level: 2
Class: New Feature
Version: 1.2.5i7
The rulesets for configuration manual checks (i.e. checks not created by the service
discovery) have been moved into a new WATO module <i>Manual Checks</i>. This should
save users from accidentally using these rules instead of their counterparts for
invetorized checks.
ID: 1560
Title: Put host and service groups into one WATO menu item
Component: WATO
Level: 2
Class: New Feature
Version: 1.2.5i7
There is now a common menu item in WATO for host and service groups. It
points to the host group management where you can switch to the service
groups. This makes the WATO menu a bit more cleaned up.
ID: 1539
Title: Fixed refreshing of PNP graphs in dashboards
Component: Multisite
Level: 2
Class: Bug Fix
Version: 1.2.5i7
The PNP graphs contained in dashboards were not refreshed as intended.
Now they are refreshed in the hard coded default interval of 60 seconds.
This will be configurable soon.
ID: 1554
Title: mk_oracle: You can now monitor multiple ORACLE releases on the same host
Component: Checks & Agents
Level: 2
Class: New Feature
Version: 1.2.5i7
ID: 1553
Title: Fix deleting (acknowleding) of logfiles in logwatch
Component: Multisite
Level: 2
Class: Bug Fix
Version: 1.2.5i7
The button for deleting (i.e. acknowleding) logfile messages in the webpage
for the logwatch check did not work. This was due to a missing transaction ID,
which in turn was due to an internal code cleanup. This has been fixed now
and logfiles can now again be deleted.
ID: 1512
Title: Bulk notification can now be grouped according to custom macro values
Component: Notifications
Level: 2
Class: New Feature
Version: 1.2.5i7
When you configure notification bulking you can now let the value of
one or several host/service custom macros decide in which bulk a
notification email goes. For example you can select the variable <tt>FOO</tt>
to be used for grouping. Then for each different value of this macro
a separate bulk will be created.
ID: 1438
Title: quicksearch: fixed various non-working quicksearch filters
Component: Multisite
Level: 2
Class: Bug Fix
Version: 1.2.5i7
Some of the view filters got renamed in the latest releases.
These changes were not considered in the quicksearch plugins which refer to these filters.
As a result the hostgroup (<i>hg:</i>) search did not work properly.
Also the some multiple search filters (e.g. <i>h: test s: cpu hg: testgroup</i>) did omit the
specified host- and servicegroup patterns.