Checkmk werks level2 July 2019

checkmk-werks-lvl2@lists.checkmk.com

6 participants
16 discussions

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, 2 months

Checkmk Werk 7893: systemd_units: filter out disabled services from summary monitoring

by Wontek Hong

ID: 7893 Title: systemd_units: filter out disabled services from summary monitoring Component: Checks & agents Level: 2 Class: Bug fix Version: 1.7.0i1 This fix solves the permanent crit status of the systemd summary checkup. Disabled (explicit & implicit) services are now excluded from the summary but still mentioned in the overall message

5 years, 2 months

Checkmk Werk 8780: mknotifyd: fix race condition in distributed setups

by Tom Baerwinkel

ID: 8780 Title: mknotifyd: fix race condition in distributed setups Component: Notifications Level: 2 Class: Bug fix Version: 1.7.0i1 In a distributed setup a slave site may try to deliver notifications locally during an activate changes even though the slave site should forward notifications to the master site. This effect appears when the option "Notification Spooling" is set to "Asynchronous local delivery by notification spooler" in the global settings and to "Forward to remote site by notification spooler" in the "Site specific global settings" of the slave site. This werk fixes this issue by locking the Checkmk configuration when a configuration snapshot is installed on the remote site. This way the "cmk --notify" command and the mknotifyd cannot use a partially installed Checkmk configuration. As a workaround the "Notification Spooling" can be set to "Forward to remote site by notification spooler" in the global settings and to "Asynchronous local delivery by Notification spooler" in the "Site specific global settings" of the slave site.

5 years, 2 months

Checkmk Werk 7967: Fix blocked liveproxy after executing livestatus commands

by Lars Michelsen

ID: 7967 Title: Fix blocked liveproxy after executing livestatus commands Component: Livestatus Proxy Level: 2 Class: Bug fix Version: 1.7.0i1 The 1.6.0b3 release introduced an regression which made the liveproxyd treat channels to sites as blocked after executing a livestatus command. When executing multiple commands this resulted in a busy site and finally GUI timeouts, because all channels were blocked.

5 years, 2 months

Checkmk Werk 7262: Initial version of new Business Intelligence visualization

by Andreas Boesl

ID: 7262 Title: Initial version of new Business Intelligence visualization Component: BI Level: 2 Class: New feature Version: 1.7.0i1 This werk introduces the initial version of the new business intelligence visualiziation, which was mentioned at our last conference https://www.youtube.com/watch?v=zYfIBJkbKxA You can navigate to the new visualization through an icon, which is shown in the classical view. The new visualization enables you to view aggregations in a different perspective. A more elaborate documentation will be provided later on. Some first notes. You can create layout templates for a group of aggregations. These templates can be assigned in the aggregation configuration. You can also specifically assign a layout to one aggregation.

5 years, 2 months

Checkmk Werk 7429: pushover: fix broken error handling

by Tom Baerwinkel

ID: 7429 Title: pushover: fix broken error handling Component: Notifications Level: 2 Class: Bug fix Version: 1.7.0i1 Since its introduction in version 1.2.8 the error handling of the pushover notification script is broken. Notifications were always handled as successful even if the Pushover API returned an error. Version 1.5.0 introduced another bug that printed an error message to the notify.log for successful notifications.

5 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 July 2019