Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

Checkmk Werk 12425: Service discovery: Handle vanished services correctly

by Joerg Herbel

ID: 12425 Title: Service discovery: Handle vanished services correctly Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 The <tt>Full service scan</tt> functionality on the service discovery page of hosts showed vanished services as still monitored. The same applied to the service <tt>Check_MK Discovery</tt>, which monitors the discovered services of a hosts. This has been fixed.

3 years, 5 months

Checkmk Werk 12320: Hosts will use Classic SNMP backend for SNMP-v1 datasource

by Sergey Kipnis

ID: 12320 Title: Hosts will use Classic SNMP backend for SNMP-v1 datasource Component: Core & setup Level: 2 Class: Bug fix Version: 2.1.0i1 It was discovered that using SNMP-v1 datasource with default(Inline) backend may lead to memory leak in fetcher processes. Since this release a host configured with datasources SNMP-v1 will use Classic SNMP backend thus eliminating the problem. To enable the fix you may need to update site configuration using WATO or command line.

3 years, 5 months

Checkmk Werk 12553: Agent bakery: Fix host label conditions in distributed setups

by Lars Michelsen

ID: 12553 Title: Agent bakery: Fix host label conditions in distributed setups Component: agents Level: 2 Class: Bug fix Version: 2.1.0i1 In previous Checkmk versions agent bakery rules that were using host label conditions could not be used correctly in distributed setups. The background is that in distributed setups the discovered(!) host labels are stored on remote sites for hosts that are assigned with a remote site. But the processing of agent bakery rules is done one the central site during agent baking. Without the discovered host labels of remote site hosts, the bakery could not compute the correct agent configuration for these hosts. The hosts were not matched based on their discovered host labels. This change now sets up a synchronization of discovered host labels from remote sites to the central site for the bakery rules to be able to match the correct hosts. The synchronization is being executed on a regular base (every 10 minutes for now) as background job. You can have a look at the state of this synchronization at "Setup > Background jobs > Discovered host label synchronization".

3 years, 5 months

Checkmk Werk 12317: Windows agent reinstalls Python module instantly

by Sergey Kipnis

ID: 12317 Title: Windows agent reinstalls Python module instantly Component: Checks & agents Level: 2 Class: New feature Version: 2.1.0i1 Previously, automatic update of the Windows agent with Python module installed has lead to long delays in the monitoring - up to few minutes, because the installation of the Python module requires a lot of CPU time. Since this release the problem is solved. Windows agent instead of the uninstalling of the Python module in it's uninstallation phase, moves the module to the temporary cache. If incoming installation of the Windows agent uses the same version og Python module, then Python module will be moved from cache to the ProgramData directory. If the versions are different, then old method will be used, i.e. full installation. Because changing of the version of the Python module happens very rarely, the usual update of the Windows agent requires no more than few seconds.

3 years, 6 months

Checkmk Werk 11855: The updating of the Windows agent no longer causes the disappearing of directories in the ProgramData

by Sergey Kipnis

ID: 11855 Title: The updating of the Windows agent no longer causes the disappearing of directories in the ProgramData Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 Previously, cleaning routine of the Windows agent was called too late: after the sending of the signal "SERVICE_STOPPED". This may lead to the disappearing of some directories in <tt>%programdata%/checkmk/agent</tt>, because deleting of directories, such as <tt>tmp</tt>, is the integral part of the cleaning phase of the update routine. If the cleaning will happen after the Windows agent restarted, then the cleaning will remove working directories and the Windows agent will not be able to function properly. With this release the error had been fixed.

3 years, 6 months

Checkmk Werk 12286: Fix GUI connection issues in distributed setups

by Lars Michelsen

ID: 12286 Title: Fix GUI connection issues in distributed setups Component: Multisite Level: 2 Class: Bug fix Version: 2.1.0i1 In distributed setups where one site has a connection problem, the number of open connections to other sites could stack up and lead to a 100% livestatus usage which may result in a not responding GUI. Normally this issue was resolved automatically after some minutes but was then causing trouble again after some time.

3 years, 6 months

Checkmk Werk 11853: Windows agent uses separate script to protect own files from unathorized access

by Sergey Kipnis

ID: 11853 Title: Windows agent uses separate script to protect own files from unathorized access Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 Previously, the protection algorithm was hard-coded into the Windows agent and it was called synchronously. Such approach may lead to some rare but important problems, because the start of the Windows agent service required a lot of time and Windows service manager may not accept this delay. Since this release Windows agent uses batch script, which runs in a separate and independent process. This script provides the identical functionality as before, but it doesn't interfere with Windows agent service thus solving the problem with delay.

3 years, 6 months

Checkmk Werk 12149: Support for Python 2 based UNIX agent plugins

by Andreas Umbreit

ID: 12149 Title: Support for Python 2 based UNIX agent plugins Component: Checks & agents Level: 2 Class: New feature Version: 2.1.0i1 With Werk #11080, we made the huge step to port the entire Checkmk codebase from Python 2 to Python 3. This also affects all Python based agent plugins, that can be found under <tt>~/share/check_mk/agents/plugins</tt> and that can be deployed via the agent bakery or manually. However, there are still many UNIX systems out there that don't support Python 3 yet. In order to still ensure a functional monitoring on these hosts, all builtin Python based agent plugins now also support Python 2. <h3>Automatic Python 3/Python 2 agent plugin mechanism</h3> This is realized by the following mechanism: <ul> <li>All python based agent plugins are written in Python 3 and end with <tt>.py</tt></li> <li>For all builtin Python 3 agent plugins, an additional Python 2 plugin is available, that ends with <tt>_2.py</tt>. E.g., you will find a Python 2 agent plugin named <tt>apache_status_2.py</tt> right next to it's Python 3 counterpart <tt>apache_status.py</tt></li>. <li>When deploying the agent plugin via agent bakery, both files will be deployed via the agent package. The UNIX agent will then automatically decide which file will be executed. If there is a Python installation >= 3.4 available on the system, the Python 3 variant will be executed. If there is instead a Python installation >= 2.6 available, the Python 2 variant will be executed. If none of the two variants are available, the plugin won't be executed.</li> <li>When deploying manually, the same mechanism holds true. You just have to include both files, if you want to make use of this feature. Please note that a python based plugin must end with <tt>_2.py</tt> to be executed via Python 2.</li> </ul> <h3>New agent rule "Python agent plugin execution (UNIX)"</h3> The agent will detect a Python 3 installation by the command <tt>python3</tt> and a Python 2 installation by the commands <tt>python2</tt> or <tt>python</tt>. If this mechanism is not suitable for you, or if you want to use Python 2, even if there is a Python 3 installation available, there exists a new agent ruleset called "Python agent plugin execution (UNIX)" for that purpose. Here, you can enforce either Python 2 or Python 3. Additionally, you can provide a custom Python command, if your host's Python installation differs from one of the above mentioned commands. <h3>New error communication</h3> If the Python based plugins can't be executed on a host system, either because there is no suitable Python installation available, or the manually configured command doesn't exist, you will be noticed via the Check_MK service of the host, that will show a suitable error message and yield a <tt>WARN</tt> state. This also means that the Checkmk agent package installation will no longer fail if there is no suitable Python installation available. <h3>Incompatibilities</h3> This Werk is marked as incompatible due to some circumstances: <ul> <li>Due to the fact that Python based plugins now require a <tt>.py</tt> ending, some builtin plugins had to be renamed. You'll have to consider this when deploying via a custom script that references the plugin's path on the Checkmk site. However, the agent bakery will still choose the right files.</li> <li>As Python 3 is the new default, and Python 2 was the old default, many Python based plugins will silently be executed with a different interpreter as before. If you still want Python 2, (and there is a Python 3 installation that would get chosen automatically,) you'll have to configure the above mentioned rule (if deploying via agent bakery), or explicitly deploy the <tt>_2.py</tt> version.</li> <li>When deploying your own Python based agent plugins, you have to keep in mind that a Python 3 plugin has to end with <tt>.py</tt> and a Python 2 plugin has to end with <tt>_.py</tt>. In particular, the shebang (if any) will be ignored. If you explicitly wish to disable this mechanism, you can still write your Python based plugins as an executable script without a <tt>.py</tt> suffix (Of course, the shebang will be used, then).</li> </ul>

3 years, 6 months

Checkmk Werk 11792: mail: adjustments to the number of graphs

by Tom Baerwinkel

ID: 11792 Title: mail: adjustments to the number of graphs Component: Notifications Level: 2 Class: New feature Version: 2.0.0b8 This werk affects all users who use the mail (not asciimail) plugin. If your emails contain performance graphs only the first 5 graphs will be sent by default. Additionally, if you use notification bulking only graphs for the first 5 notifications in a bulk will be sent. You can adjust these settings with the options "Graphs per notification" and "Bulk notifications with graphs" either directly in the notification rule or with the ruleset "Parameters for HTML Email". Reason behind this werk: Each graph in a bulk increases the size of the mail and takes time to render on the monitoring server. For very large bulks the mail size may exceed the maximum size for attachements or the plugin may run into a timeout so that a failed notification is produced. This werk will therefore increase the liability and performance of HTML emails. Since most services have fewer than five graphs and the most important information is displayed in the first graphs a total number of 5 graphs should be sufficient even in single notifications. Furthermore, for a detailed analysis the data displayed in emails is usually not sufficient and a look into the user interface is necessary.

3 years, 6 months

Checkmk Werk 12277: Docker container: Update base image to Debian buster

by Lars Michelsen

ID: 12277 Title: Docker container: Update base image to Debian buster Component: Core & setup Level: 2 Class: Security fix Version: 2.1.0i1 The Checkmk docker container image was previously based on the debian:stretch-slim image. The base image has now been updated to debian:buster-slim. If you build the container images on your own, based on the Dockerfile from our git, you will now have to use the Checkmk packages for Debian buster instead of the stretch packages.

3 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2