Checkmk werks level2 July 2019

checkmk-werks-lvl2@lists.checkmk.com

6 participants
16 discussions

Checkmk Werk 7717: Windows Agent 1.6 Beta 4: new features

by Sergey Kipnis

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.

5 years, 1 month

Checkmk Werk 7716: Windows Agent 1.6 Beta 4: fixes

by Sergey Kipnis

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.

5 years, 1 month

Checkmk Werk 8784: bulk notifications were sent multiple times

by Tom Baerwinkel

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.

5 years, 1 month

Checkmk Werk 8783: bulk notifications did not produce failed notifications

by Tom Baerwinkel

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.

5 years, 1 month

Checkmk Werk 7986: Service labels can be used as rule conditions

by Lars Michelsen

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.

5 years, 1 month

Checkmk Werk 8810: systemd_services: Extension of services classification functionality

by Wontek Hong

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.

5 years, 1 month

Checkmk Werk 7978: Service labels can now be discovered

by Lars Michelsen

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.

5 years, 1 month

Checkmk Werk 7444: Rename metric name in Filesystem checks from mount point to fs_used

by Óscar Nájera

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.

5 years, 1 month

Checkmk Werk 7445: Historic data views and painters for capacity management

by Óscar Nájera

ID: 7445 Title: Historic data views and painters for capacity management Component: Reporting & Availability Level: 2 Class: New feature Version: 1.7.0i1 Capacity management allows you to work with the service metrics historical data. When configuring a view you can select for a column the "Service Historic Metrics" option from the drop-down menu, available for the "All hosts" and "All services" data-sources. This customizable painter allows you to select, which service metric you want to analyze, over which time range should data be recovered from your RRD database, how data is to be consolidated and aggregated. Finally, you need to label this column to your best convenience. Some ideas you might want to consider when creating your views: List all your hosts Peak CPU utilization, over the last week, and also last month. Maybe you want also to create a new column corresponding to the to the times a new version of your software was deployed. Time ranges are completely flexible, and you can keep adding columns for any time window you prefer. Analyze over the same time window, the peak, average and minimum CPU utilization of all your hosts over the last week or last month. You can also get data from different services at the same time. For example showing CPU utilization, used memory and disk IO averaged over the last week. One last note. Because you will be querying from the RRD data of many hosts at the same time, query time will increase linearly with the volume of data you are processing.

5 years, 1 month

Checkmk Werk 7445: Historic data views and painters for capacity management

by Óscar Nájera

5 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 July 2019