Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15974 discussions

Check_MK Werk 5950: uptime: Is now reported correctly for docker containers

by Lars Michelsen

ID: 5950 Title: uptime: Is now reported correctly for docker containers Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4 In previous versions of the linux agent the uptime of the docker node was reported by the agent when it is being executed in a docker container context.

6 years, 6 months

Check_MK Werk 5951: kernel: Disabled in docker container contexts

by Lars Michelsen

ID: 5951 Title: kernel: Disabled in docker container contexts Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4 These checks do not make sense in the context of a docker container. The agent is now skipping this section when executed in a container.

6 years, 6 months

Check_MK Werk 5948: docker_container_mem: Docker container specific memory checking

by Lars Michelsen

ID: 5948 Title: docker_container_mem: Docker container specific memory checking Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4 Instead of using the default linux memory check (mem), Check_MK is now using the container specific memory check. The main reason is that the memory information in the container is not available through <tt>/proc/meminfo</tt> as usual. The memory data is available through the kernels cgroup interface which is available in the containers context below <tt>/sys/fs/cgroup/memory/memory.stat</tt> The features of both checks are exactly the same.

6 years, 6 months

Check_MK Werk 5954: drbd: Disabled in docker container contexts

by Lars Michelsen

ID: 5954 Title: drbd: Disabled in docker container contexts Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4

6 years, 6 months

Check_MK Werk 5753: mk_postgres: reduce the amount of psql sessions opened by the plugin

by Tom Baerwinkel

ID: 5753 Title: mk_postgres: reduce the amount of psql sessions opened by the plugin Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4 Previously, the number of psql sessions scaled linearly with the number of databases. Now the number of psql sessions opened by the plugin is constant. Additionally, the sessions of some sections were combined to further reduce the total number of psql sessions.

6 years, 6 months

Check_MK Werk 5769: site_object_counts: New check which collects information about the amount of different host types or used check commands of OMD sites

by Simon Betz

ID: 5769 Title: site_object_counts: New check which collects information about the amount of different host types or used check commands of OMD sites Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4 To make this check work please install the {{mk_site_object_counts}} agent plugin and specify host tags or check commands within the {{site_object_counts.cfg}} configration file. The following options are available: <table> <tr><td>{TAGS}</td><td>global host tags</td></tr> <tr><td>{SERVICE_CHECK_COMMANDS}</td><td>global check commands</td></tr> <tr><td>{SITES}</td><td>restriction to specified sites</td></tr> <tr><td>{TAGS_$SITENAME}</td><td>site specific host tags</td></tr> <tr><td>{SERVICE_CHECK_COMMANDS_$SITENAME}</td><td>site specific check commands</td></tr> </table> The agent plugin is executed if and only if OMD is installed and there's a configuration file. Sites which provide an opened Livestatus socket {/omd/sites/$SITENAME/tmp/run/live} are taken into account. Without the restrictive option {SITES} all sites on that server are considered which satisfy above conditions. If more than one value is assigned they have to be separated by one space, eg. <ul> <li>{TAGS=prod snmp}</li> <li>{SERVICE_CHECK_COMMANDS_sitename=kernel lnx_if}</li> <ul> H3:Example 1 F+:site_object_counts.cfg TAGS=snmp SERVICE_CHECK_COMMANDS=if F-: With this configuration the agent plugin returns the amount of all SNMP hosts and the amount of all interface services of the type {if} of all sites. H3:Example 2 F+:site_object_counts.cfg SITES=site_a site_b TAGS=snmp SERVICE_CHECK_COMMANDS=if F-: With this configuration the agent plugin returns the amount of all SNMP hosts and the amount of all interface services of the type {if} of the sites {site_a} and {site_b}. H3:Example 3 F+:site_object_counts.cfg TAGS_site_a=snmp SERVICE_CHECK_COMMANDS_site_a=if TAGS_site_b=agent SERVICE_CHECK_COMMANDS_site_b=lnx_if F-: With this configuration the agent plugin returns <ul> <li>the amount of all SNMP hosts and the amount of all interface services of the type {if} of the site {site_a} and</li> <li>the amount of all agent-based hosts and the amount of all Linux interface services of the type {lnx_if} of the site {site_b}.</li> </ul> H3:Example 4 F+:site_object_counts.cfg TAGS=prod SERVICE_CHECK_COMMANDS=omd_apache omd_status TAGS_site_a=snmp SERVICE_CHECK_COMMANDS_site_a=if TAGS_site_b=agent SERVICE_CHECK_COMMANDS_site_b=lnx_if F-: With this configuration the agent plugin returns <ul> <li>the amount of all productive hosts and services of type {omd_apache} and {omd_status} of all sites.</li> <li>additionaly the amount of all SNMP hosts and the amount of all interface services of the type {if} of the site {site_a} and</li> <li>additionaly the amount of all agent-based hosts and the amount of all Linux interface services of the type {lnx_if} of the site {site_b}.</li> </ul> H3:Example 5 F+:site_object_counts.cfg SITES=site_a site_b site_c TAGS=prod SERVICE_CHECK_COMMANDS=omd_apache omd_status TAGS_site_a=snmp SERVICE_CHECK_COMMANDS_site_a=if TAGS_site_b=agent SERVICE_CHECK_COMMANDS_site_b=lnx_if F-: With this configuration the agent plugin returns <ul> <li>the amount of all productive hosts and services of type {omd_apache} and {omd_status} of the sites {site_a}, {site_b} and {site_c}.</li> <li>additionaly the amount of all SNMP hosts and the amount of all interface services of the type {if} of the site {site_a} and</li> <li>additionaly the amount of all agent-based hosts and the amount of all Linux interface services of the type {lnx_if} of the site {site_b}.</li> </ul>

6 years, 6 months

Check_MK Werk 5944: Fixed broken HTTP header auth for not yet existing users

by Lars Michelsen

ID: 5944 Title: Fixed broken HTTP header auth for not yet existing users Component: Multisite Level: 1 Class: Bug fix Version: 1.5.0i4 This was broken since ~1.5.0i3. When a user which has not been created in Check_MK before is being authenticated using the optional HTTP header authentication and logged in using the "default user profile", some host- and service views were not working as expected. They were showing some exception like "KeyError: u'<USER>'". A workaround in the affected versions is to create the user accounts before the user try to access the GUI.

6 years, 6 months

Check_MK Werk 5938: Fixed search of event console packs and rules

by Simon Betz

ID: 5938 Title: Fixed search of event console packs and rules Component: Multisite Level: 1 Class: Bug fix Version: 1.5.0i4

6 years, 6 months

Check_MK Werk 5937: apc_system_events: New check which monitors active system events on an InRow Cooling device

by Simon Betz

ID: 5937 Title: apc_system_events: New check which monitors active system events on an InRow Cooling device Component: Checks & agents Level: 1 Class: New feature Version: 1.5.0i4

6 years, 6 months

Check_MK Werk 5830: Fixed DST shift correction for downtimes, causing CMC to use 100% CPU

by Sven Panne

ID: 5830 Title: Fixed DST shift correction for downtimes, causing CMC to use 100% CPU Component: Core & setup Level: 2 Class: Bug fix Version: 1.5.0i4 When a downtime was configured to recur every hour and a 1h DST shift happened, the CMC would go into an infinite loop with 100% CPU load and no monitoring at all. If the downtime in question was set in an ad hoc fashion via the GUI (not via rules), the only way to work around this issue was to remove the state file, losing all downtimes, acknowledgements and comments.

6 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1