ID: 10064
Title: Windows Agent doesn't send anymore very high WMI values
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0p1
Previously, on some versions of Windows, the WMI API call may not clean
data structures correctly. As result the Agent may send extremally high
values for CPU load, RPC latency and so on.
Now Windows Agent cleans WMI data structures automatically and also cuts all
received data according to the length defined by Windows API thus preventing
such type of error.
ID: 10063
Title: FIX upgrade of the Windows Agent 1.5 to version 1.6 includes the spool directory too
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0
Previously the spool directory had been ignored during upgrade from Windows
Agent 1.5 to Windows Agent 1.6. It may lead to failing spool checks.
Now the problem has been fixed: spool directory and all its content are
copied to the working folder of the new Agent
ID: 10060
Title: Windows Agent's plugins mk_logwatch and mk_jolokia are updated
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0b12
Since now Windows Agent uses newest versions of those plugins
ID: 10061
Title: Windows Agent Installer doesn't clean ProgramData Folder anymore
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0b12
Previously the manual use of Windows Installer(check_mk_agent.msi) could lead
to strange installation errors. This happens during the cleanup of the
ProgramData folder, because some files in this folder may be locked by
other running Windows software, Windows Agent's plugins, cmk-update-agent.exe
or even by the Windows Agent itself.
Since now then the Windows Installer does not touch ProgramData anymore and
prevents such errors.
ID: 10137
Title: jolokia_jvm_memory: New check plugin
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.7.0i1
We introduce the new check plugin {{jolokia_jvm_memory}}. It replaces the old
memory subcheck {{mem}} and the permanent generation subcheck {{perm_gen}}
of the {{jolokia_metrics}} plugin.
In addition it features monitoring of the JVM memory pools in general;
including but not limited to "Code Cache", the legacy "Permanent Generation"
and the newer "Metaspace" pool.
If you are using the plugin {{mk_jolokia}}, you have to redeploy it in order
to get the new services. If you are using the special agent {{agent_jolokia}}
a rediscovery will suffice.
The applicable rulesets are called "JVM memory levels" and "JVM memory pool levels".
Note that rules that you have configured already will not be applied. Please revisit
the WATO page to reconfigure those rules.
Only values configured in percentage will be converted from your legacy rules -
absolute levels for the remaining *free* space are no longer considered,
as the maximum amount of available space may not be known.
Note that the performance data belonging to the "JVM MyInstance Memory" service
will be lost, even though the service name will not change.
ID: 10171
Title: Discovery: Fix triggering of discovery service after changing services
Component: WATO
Level: 1
Class: Bug fix
Version: 1.7.0i1
When editing services on the service discovery page it is intended that the
"Check_MK Discovery" service of the current host is retriggered to immediately
reflect the changes that have just been made to the service config.
This trigger was working as expected in previous 1.6.0 releases.
ID: 10172
Title: Discovery service is now correctly operating on the WATO config instead of core config
Component: Core & setup
Level: 1
Class: Bug fix
Version: 1.7.0i1
The Check_MK Discovery service needs to work with the WATO configuration world
instead of the "activated config" world. For example, if you edit the services
on the WATO service discovery page, you want the discovery service to be
updated right after editing the services in WATO.