ID: 7717
Title: Windows Agent 1.6 Beta 4: new features
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.6.0b4
Summary of the features introduced in Windows Agent beta 4:
- Asynchronous plugins with 'cache_age' set to 0 are supported now.
In previous version such plugins have been assumed as synchronous.
- The Uninstallation of the Windows Agent doesn't remove 'config' and 'state' directories from the Agent Data directory to prevent user data loss.
- The start of the Windows Agent may be delayed by a few seconds to allow asynchronous plugins to finish their work.
This feature has no effect for normal situation when agent is running as a service, but may be useful to test asyncronous plugins.
- Now the Agent uses next directories:
The Windows Agent installs own binary files in the directory "Program Files (x86)\checkmk\service"
For user and bakery data the Windows Agent uses the directory "ProgramData\checkmk\agent"
- The macroses used in the configuration files had been renamed
$BUILTIN_AGENT_PATH$ -> is C:/Program Files(x86)/checkmk/service/
$BUILTIN_PLUGINS_PATH$ -> is C:/Program Files(x86)/checkmk/service/plugins
$CUSTOM_AGENT_PATH$ -> is C:/ProgramData/checkmk/agent/
$CUSTOM_PLUGINS_PATH$ -> is C:/ProgramData/checkmk/agent/plugins
$CUSTOM_LOCAL_PATH$ -> is C:/ProgramData/checkmk/agent/local
- The logfile check_mk.log have been moved to the "ProgramData/checkmk/agent/log" directory
- The configuration files check_mk.user.yml and check_mk.yml had been revised, cleaned of old and unused data and better documented.
- The default timeout for all plugins is set to 60 seconds, previously the timeout was set to 30.
- Now all names in any yml configuration file with the leading underscore are considered invalid and skipped
from the output when the command showconfig is used.
ID: 7716
Title: Windows Agent 1.6 Beta 4: fixes
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.6.0b4
Summary of the fixes introduced in beta 4 for Windows Agent
- the readme file extension had been changed from .md to .txt to be more Windows-friendly
- the logwatch configuration is correctly merged, including data from the config file check_mk.user.yml
in previous version, the agent only got entries from the check_mk.user.yml
now used all configurations file are used in the correct order: check_mk.yml, check_mk.bakery.yml and check_mk.user.yml
- the msexch section no longer sends invalid formatted section data, which caused the check to crash
- The processing of plugin had been reorganised. The execution order is now strictly defined according to simple rules:
"Top-down priority of patterns" and "Duplicate executables will be skipped".
More examples can be found in the current check_mk.user.yml.
- The Agent Update plugin is now correctly started and its output is correctly processed.
Previously Agent doesn't send output from the Agent Updater to the server.
- An empty local section is no longer sent
- Fixed error 104 during connection monitoring site to the 64-bit windows client.
Previously 64-bit version of the Agent may reset connection with error 104 if any async plugin didn't stop in time.
- Fixed an error with missing 'temp' folder for Agent Updater.
Due to strange glitch in Windows Agent folder 'temp' had been renamed to 'tmp'.
Previously the Agent Updater tried to find "temp" folder and if it was not available,
the Agent Updater wrote an error message and used the global fallback folder specified in the environment variable %temp%.
The Agent Updater now uses the 'tmp' folder within ProgramData\checkmk\agent
- The 1.5 Agent Updater no longer tries to do a second installation after the windows service was updated to version 1.6
This was caused by not-updated hash values in the old windows agent directory
The 1.6 Agent is now able to patch these values in the old agent directory, hereby preventing the agent updater to trigger another update.
ID: 7717
Title: Windows Agent 1.6 Beta 4: new features
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.6.0b4
Summary of the features introduced in Windows Agent beta 4:
- Asynchronous plugins with 'cache_age' set to 0 are supported now.
In previous version such plugins have been assumed as synchronous.
- The Uninstallation of the Windows Agent doesn't remove 'config' and 'state' directories from the Agent Data directory to prevent user data loss.
- The start of the Windows Agent may be delayed by a few seconds to allow asynchronous plugins to finish their work.
This feature has no effect for normal situation when agent is running as a service, but may be useful to test asyncronous plugins.
- Now the Agent uses next directories:
The Windows Agent installs own binary files in the directory "Program Files (x86)\checkmk\service"
For user and bakery data the Windows Agent uses the directory "ProgramData\checkmk\agent"
- The macroses used in the configuration files had been renamed
$BUILTIN_AGENT_PATH$ -> is C:/Program Files(x86)/checkmk/service/
$BUILTIN_PLUGINS_PATH$ -> is C:/Program Files(x86)/checkmk/service/plugins
$CUSTOM_AGENT_PATH$ -> is C:/ProgramData/checkmk/agent/
$CUSTOM_PLUGINS_PATH$ -> is C:/ProgramData/checkmk/agent/plugins
$CUSTOM_LOCAL_PATH$ -> is C:/ProgramData/checkmk/agent/local
- The logfile check_mk.log have been moved to the "ProgramData/checkmk/agent/log" directory
- The configuration files check_mk.user.yml and check_mk.yml had been revised, cleaned of old and unused data and better documented.
- The default timeout for all plugins is set to 60 seconds, previously the timeout was set to 30.
- Now all names in any yml configuration file with the leading underscore are considered invalid and skipped
from the output when the command showconfig is used.
ID: 7716
Title: Windows Agent 1.6 Beta 4: fixes
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.6.0b4
Summary of the fixes introduced in beta 4 for Windows Agent
- the readme file extension had been changed from .md to .txt to be more Windows-friendly
- the logwatch configuration is correctly merged, including data from the config file check_mk.user.yml
in previous version, the agent only got entries from the check_mk.user.yml
now used all configurations file are used in the correct order: check_mk.yml, check_mk.bakery.yml and check_mk.user.yml
- the msexch section no longer sends invalid formatted section data, which caused the check to crash
- The processing of plugin had been reorganised. The execution order is now strictly defined according to simple rules:
"Top-down priority of patterns" and "Duplicate executables will be skipped".
More examples can be found in the current check_mk.user.yml.
- The Agent Update plugin is now correctly started and its output is correctly processed.
Previously Agent doesn't send output from the Agent Updater to the server.
- An empty local section is no longer sent
- Fixed error 104 during connection monitoring site to the 64-bit windows client.
Previously 64-bit version of the Agent may reset connection with error 104 if any async plugin didn't stop in time.
- Fixed an error with missing 'temp' folder for Agent Updater.
Due to strange glitch in Windows Agent folder 'temp' had been renamed to 'tmp'.
Previously the Agent Updater tried to find "temp" folder and if it was not available,
the Agent Updater wrote an error message and used the global fallback folder specified in the environment variable %temp%.
The Agent Updater now uses the 'tmp' folder within ProgramData\checkmk\agent
- The 1.5 Agent Updater no longer tries to do a second installation after the windows service was updated to version 1.6
This was caused by not-updated hash values in the old windows agent directory
The 1.6 Agent is now able to patch these values in the old agent directory, hereby preventing the agent updater to trigger another update.
ID: 8784
Title: bulk notifications were sent multiple times
Component: Notifications
Level: 2
Class: Bug fix
Version: 1.7.0i1
Werk #8783 introduced a bug where bulk notifications
were not cleaned up and sent multiple times. All
notification scripts that produce no plugin output
like e.g. asciimail are affected.
ID: 8783
Title: bulk notifications did not produce failed notifications
Component: Notifications
Level: 2
Class: Bug fix
Version: 1.7.0i1
If a notification script returned a non-zero exit code and was
configured for bulk notifications no failed notifications were
shown in the GUI. With this fix one failed notification will
be produced for every notification present in the failed bulk.
Furthermore the view "Host and Service notifications" now shows
a "Final notification result" for every notification in a bulk.
ID: 7986
Title: Service labels can be used as rule conditions
Component: Core & setup
Level: 2
Class: New feature
Version: 1.7.0i1
The service labels, that are introduced with Checkmk 1.6 can now be used as
conditions in service rulesets (Host & Service Parameters). These conditions
can be configured like the host labels.
The labels can not be used in the rulesets "Service labels", because that
could result in a hen egg problem.
ID: 8810
Title: systemd_services: Extension of services classification functionality
Component: Checks & agents
Level: 2
Class: New feature
Version: 1.7.0i1
The systemd services summary check plugin obtains the functionality to assess static and activatingin a separate batch. Regarding the activating services, a new WATO rule has been implemented which allows to specify "lenient" time periods.
ID: 7978
Title: Service labels can now be discovered
Component: Core & setup
Level: 2
Class: New feature
Version: 1.7.0i1
The discovery functions of Checkmk checks can now produce a collection of
service labels together with the discovered services. This makes it possible
for the check developer to mark the services of the discovered services which
can then be grouped together in a flexible way.
The discovered service labels can be listed on the service discovery page of
WATO by enabling them with the button "Show discovered labels".
These labels are attributes of the discovered service and will be handled exactly
like them. They are discovered in one step and applied to the running
configuration in the same way. The cluster handling is also equal.
How make my checks produce service labels?
Instead of producing a two element tuple of <tt>(item, parameters)</tt> to
create a new service the discovery functions can now provide objects like this:
C+:
Service(
item="Interface 213",
parameters=None,
service_labels=ServiceLabels(
ServiceLabel(u"check_type", u"network_interface"),
ServiceLabel(u"interface_type", u"uplink"),
)
)
C-:
These objects can be returned / yielded like the tuples before. Both,
the parameters and the service_labels are optional arguments.
ID: 7444
Title: Rename metric name in Filesystem checks from mount point to fs_used
Component: Core & setup
Level: 3
Class: Bug fix
Version: 1.7.0i1
Filesystem Nagios check plug-in stored the filesystem usage of every mount
points in the RRD databases under the path of each mount point. Checkmk
assigned to every mount point a service, still it kept naming the
filesystem usage with the mount point path for compatibility. Our graphing
system learned to deal with this unpractical convention, however new
features in Checkmk performing bulk access to data can't.
<ul>
<li>All sites created with Checkm 1.6.0 onwards will automatically use the
new naming convention and don't need to be migrated</li>
<li> The migration is not mandatory, your Checkmk instance will continue
working under the legacy mode until you migrate.</li>
<li>If you use CRE, you don't need to de the migration</li>
<li>If you don't plan to do bulk access to data as required by the Historic
Data Views for filesystems (see Werk #7445), you don't need to migrate your
RRD databases.</li>
<li>If you want to use the Historic Data Views for Capacity Management on
Filesystems, you need to do migration.</li>
</ul>
The incorporation of Historic Data Views, for Capacity Management,
requieres querying the filesystem usage of all host in a given time
window. It becomes prohibitive expensive to do such request since first
every service is queried for its mount point name and then every RRD is
individually queried again for the mount point name data.
In this werk we provide a migration script that would edit all meta data
files describing the RRDs that receive output from all our supported
filesystem checks. It will also set a flag in your config so that
Filesystem check plug-ins start delivering usage perfomance data under the
static name of fs_used.
You are advised to do a backup of your RRD files and journal files before
performing the migration and your Checkmk instance needs to be stopped
during the migration.
Migration is one way and needs to be performed once per site any rollback
has to be done from your own backup.