Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

Checkmk Werk 13139: Add Alertmanager special agent and check plugins

by Lukas Lengler

ID: 13139 Title: Add Alertmanager special agent and check plugins Component: Checks & agents Level: 2 Class: New feature Version: 2.1.0i1 Add special agent and check plugins for Alertmanager. The special agent retrieves information from the Alertmanager rules API. It retrieves information about: <ul> <li>alert rule groups</li> <li>alert rules</li> <ol> <li>name</li> <li>status</li> <li>severity</li> <li>message</li> </ol> </ul> The check plugin monitors <ul> <li>Individual alert rules</li> <li>Alert rule groups</li> <li>Alert rule summary</li> </ul> For more information look at the respective manpages

3 years, 1 month

Checkmk Werk 12328: Add possibility to change Windows Agent WMI timeout in WATO

by Sergey Kipnis

ID: 12328 Title: Add possibility to change Windows Agent WMI timeout in WATO Component: Setup Level: 2 Class: New feature Version: 2.1.0i1 On heavy loaded systems the Windows WMI subsystem may not respond in time thus some WMI based services will be switched into the stale state. Since this release, the user can leverage above mentioned problem by setting a higher value in wmi_timeout via the ruleset "Windows WMI Timeout". Acceptable range is 2-12 seconds, default value is 3 seconds.

3 years, 1 month

Checkmk Werk 12850: Migrating Checkmk configurations during site renamings

by Lars Michelsen

ID: 12850 Title: Migrating Checkmk configurations during site renamings Component: Core & setup Level: 2 Class: New feature Version: 2.1.0i1 Users which execute <tt>omd mv</tt> or <tt>omd cp</tt> expect Checkmk to not only rename the site, but also migrate the Checkmk configuration in a way that they can continue seamlessly with their existing Checkmk configuration. This feature did not exist before and was a common misunderstanding. The commands listed above did not take care of the Checkmk configuration files. In fact the site management, which is realizing the renaming of a site, does not know anything about the Checkmk configuration files. However, with this change we create the integration of both worlds. In the moment a site renaming or copy is performed, the site management informs Checkmk about this action and gives it the chance to update it's configuration files. The most important parts of the Checkmk configuration are now updated: <ul> <li>Distributed monitoring (sites) configuration</li> <li>Host & folder site attributes</li> <li>Dynamic host configuration site attribute</li> </ul> The new logic is also trying to detect specific situations and displays warnings about things that can (currently) not be migrated automatically. For example, if the renaming of a distributed remote site is detected, a warning is now displayed that you also have to update the distributed monitoring configuration in the central site of your setup. Details: OMD, which is responsible for providing the site management of Checkmk, itself is only caring about migrating the files and file parts that are initially installed when creating a new Checkmk site. Clearer: If you create a clean site and then execute <tt>grep -r $OMD_SITE etc</tt> in your site, you can see a lot of files which contain the ID of the site. These things are already migrated by OMD. But OMD is not aware of the configuration files of the applications shipped with OMD. For example the Checkmk configuration files are not understood by OMD. And that's totally fine from an architectural point of view, because OMD is an separate component that manages installation of different applications, but must not mess with their individual files. However, from a users perspective it's clear that you also want the application files to be migrated during site renaming. This change introduces the general mechanism: <ul> <li>OMD detects changes of the site ID (mv, cp or restore)</li> <li>Then it executes the command <tt>post-rename-site -v -o [OLD_SITE_ID]</tt></li> <li>The command <tt>post-rename-site</tt> then takes care of the Checkmk configuration updates</li> <li>It can also detect some situations it can not solve on it's own and warns the user about potential manual steps to do afterwards.</li> </ul> The migration steps are realized in so called rename action plugins which can easily be extended. In the git you can find them at <tt>cmk/post_rename_site/plugins/actions</tt>.

3 years, 1 month

Checkmk Werk 12326: Windows agent binary files are code signed

by Sergey Kipnis

ID: 12326 Title: Windows agent binary files are code signed Component: Checks & agents Level: 2 Class: Security fix Version: 2.1.0i1 Since this release the following binary files are code signed with tribe29 digital certificate: <ul> <li>check_mk_agent.msi</li> <li>check_mk_agent.exe</li> <li>check_mk_agent-64.exe</li> </ul> Details of the used digital certificate: Name of signer: <tt>tribe29 GmbH</tt> Digest algorithm: <tt>SHA256</tt> Timestamp: presented

3 years, 1 month

Checkmk Werk 12846: Fix inheritance of folder contact groups to services of hosts

by Lars Michelsen

ID: 12846 Title: Fix inheritance of folder contact groups to services of hosts Component: Setup Level: 2 Class: Bug fix Version: 2.1.0i1 The assignment of contact groups to hosts and services can be controlled using the folder hierarchy of WATO as described in the user manual (https://docs.checkmk.com/latest/en/wato_user.html#_allocation_via_folders). You are only affected by this change in case you use a) the WATO folder hierarchy for assigning contact groups to services. When using the assigning contact groups to services with the following settings, this could result in too many groups being assigned to a service: <ul> <li>Add these groups as contacts to all hosts in this folder: Enabled</li> <li>Add these groups as contacts to all hosts in all subfolders of this folder: Not enabled</li> <li>Always add these groups as contacts to all services in all subfolders of this folder: Enabled</li> </ul> In this situation only the groups from the nearest parent folder should be assigned to the services, just like it is done for the hosts. Instead the services got the groups assigned from all parent folders which have the service assignement enabled. We now have changed the contact groups of the services to be handled exactly like the hosts. Only the contact groups defined in the nearest parent folder with the service assignment enabled will be added to the services. Example: <code> Folder_A (Permission: group1, settings as listed above) |_Folder_B (Permission: group2, settings as listed above) </code> In this scenario, a host in the Folder_B gets the contact group "group2" assigned. Services got the "group1" and "group2" assingned in previous versions. Now the services get the "group2" assigned, just like the host.

3 years, 1 month

Checkmk Werk 13086: Log error messages from the ICMP sender again.

by Sven Panne

ID: 13086 Title: Log error messages from the ICMP sender again. Component: cmc Level: 2 Class: Bug fix Version: 2.1.0i1 The CMC didn't pick up any error messages from the ICMP sender, which could in turn result in blocking the sender. This was a regression from 1.6.0.

3 years, 2 months

Checkmk Werk 12175: Postpone notifications for passively checked objects, too.

by Sven Panne

ID: 12175 Title: Postpone notifications for passively checked objects, too. Component: cmc Level: 2 Class: Bug fix Version: 2.1.0i1 Even when a host is down, we can still receive check results for passive checks on that host, e.g. via the piggyback mechanism. Any notifications resulting from these check results should be postponed in the normal way, too.

3 years, 2 months

Checkmk Werk 12325: Stabilize Windows Agent RunAs(User/Group) plugin feature

by Sergey Kipnis

ID: 12325 Title: Stabilize Windows Agent RunAs(User/Group) plugin feature Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 Previously, Windows agent supplied as working directory the current one. This may lead to failure if the starting plugin in RunAs mode had being executed from the account without valid access rights. Since this release the problem has been eliminated. If a plugin is starting in RunAs mode, then Windows Agent supplies to the starting plugin user home directory as a working directory.

3 years, 2 months

Checkmk Werk 12324: Windows WMI timeout is increased to improve stability of WMI queries

by Sergey Kipnis

ID: 12324 Title: Windows WMI timeout is increased to improve stability of WMI queries Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 This change is intended to seriously reduce the number of undesired timeouts during the access to the WMI on heavily loaded systems.

3 years, 2 months

Checkmk Werk 12882: Host tags: Take tag groups into account when matching against rule conditions

by Joerg Herbel

ID: 12882 Title: Host tags: Take tag groups into account when matching against rule conditions Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 Up to now, the matching of host tags against rule conditions was based solely on on the tag ids. The ids of the tag groups were not taken into account. However, tag ids are not required to be unique across different tag groups. Therefore, if the same tag ids occur in multiple tag groups, ignoring the group ids can lead to wrong results. This werk fixes this issue. Tag group ids are now taken into account when checking if a rule applies to a host, both for normal monitoring rules and BI aggregations.

3 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2