Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

Check_MK Werk 6014: Fixed handling of expected regular messages

by Sven Panne

ID: 6014 Title: Fixed handling of expected regular messages Component: Event Console Level: 2 Class: Bug fix Version: 1.6.0i1 If expected regular messages did not arrive at the event console and the resulting new event was not merged with a previous one, the EC could go into an endless loop, logging Python exceptions all the time. This has been fixed.

6 years, 2 months

Check_MK Werk 6283: New mode "omd cleanup" for removing unused Check_MK versions

by Lars Michelsen

ID: 6283 Title: New mode "omd cleanup" for removing unused Check_MK versions Component: Site Management Level: 2 Class: New feature Version: 1.6.0i1

6 years, 2 months

Check_MK Werk 6191: Configure additional Windows eventlogs with keyword 'logfile'

by Jukka Aro

ID: 6191 Title: Configure additional Windows eventlogs with keyword 'logfile' Component: Checks & agents Level: 2 Class: Bug fix Version: 1.6.0i1 Werk #3106 (Check_MK 1.4.0i1) introduced the possibility of configuring additional eventlogs with the keyword 'logname'. However, this was not supported by the Agent Bakery that only knew the keyword 'logfile'. Now, additional, non-standard eventlogs that are not found in Windows registry, can be configured for monitoring with the ordinary keyword 'logfile', e.g. "logfile Microsoft-Windows-GroupPolicy/Operational = warn" so that they can also be configured normally through the Agent Bakery. Note that non-standard eventlogs also require the option vista_api to be set to 'yes.' Using the keyword 'logname' is strongly discouraged and that keyword should be considered deprecated. It will remain functional only for compatibility with old, manually configured check_mk.ini files.

6 years, 2 months

Check_MK Werk 5823: New Feature: SLA reporting

by Andreas

ID: 5823 Title: New Feature: SLA reporting Component: Multisite Level: 3 Class: New feature Version: 1.6.0i1 SLA reports are a continuation of the already existing availability reports. The data from the availability feature can be additionally modified, before it is evaluated by the SLA requirements. Currently these two SLA requirements are implemented <ul> <li>State Percentage: The service state OK/WARN/CRIT/UNKNOWN is lower/higher than x percent</li> <li>Outage count: Maximum number of outages with a length of x minutes</li> </ul> Note: An upcoming SLA requirement will be "Minimum time between outages" Before the availability data gets forwarded to the computation plugins (which check the actual requirements) it is <li>further shortened by applying timeperiods, for example "Only check weekdays"</li> <li>cut into mulitple timeframes (daily/weekly/monthly), specified by period in the SLA definition</li> </ul> Each timeframe is computed separately, so you will get several SLA results, if the timerange you are interested in spans multiple SLA periods. Configuration First of all you need to configure a SLA definition. Just like views and reports, SLA definitions are configured per user, so you can setup a SLA and publish it to other users. SLA definitions are not inherently bound to services. A SLA definition can be assigned to a service, via the WATO rule <tt>Assign SLA to service</tt>. For views, the multisite GUI currently offers two different painters to display SLA information <ul> <li>SLA - Service specific: This painter renders SLA definitions, which were assigned by WATO rule. Therefore, one table column in a view can display multiple SLA definition types. The timerange, however, is fixed for all SLAs and can be configured in the painter</li> <li>SLA - Column specific: This painter renders the same SLA definition for all services in the table</li> </ul> There are several configuration options for both painters. <ul> <li>SLA timerange: The timerange specifies the start and end date you are interested in. A SLA definition only has a recurring period (e.g. weekly). So if you have a SLA definition with a monthly period and set the timerange from 01.01.2018 to 31.03.2018, you will get three separate SLA results, one for each month</li> <li>Layout options: With these options you can configure the content of the painter. You may also choose only to display the SLA name, which means no actual SLA computation, hereby saving performance</li> <li>Plugin display options</li>Allows you to configure the precision of percentage (float) values and additional layout options</li> </ul> There is also a SLA details page available. This page offers detailed information regarding the computation. <ul> <li>Availability rawdata used in computation</li> <li>Aggregated results (the actual SLA outcome) over all computation plugins</li> <li>Subresults for each used computation plugin</li> <li>SLA specification: Includes all settings which were used to create this report</li> </ul> Please note that this feature is quite new and still under heavy development. The goal in version 1.5 is to get some hands on experience and add some minor improvements and bugfixes over time. Exporting the SLA data into PDF reports is currently only supported within views. Later on, the SLA details page will also receive a "Export to PDF" button.

6 years, 3 months

Check_MK Werk 5816: Check parse_function is no longer called multiple times if there are several subchecks for the same section

by Andreas

ID: 5816 Title: Check parse_function is no longer called multiple times if there are several subchecks for the same section Component: Checks & agents Level: 2 Class: Bug fix Version: 1.6.0i1

6 years, 3 months

Check_MK Werk 5814: Fixed missing clustered snmp services on cluster hosts

by Andreas

ID: 5814 Title: Fixed missing clustered snmp services on cluster hosts Component: Checks & agents Level: 2 Class: Bug fix Version: 1.6.0i1 Clustered snmp services did not receive from their nodes. The data required by the cluster host was either missing or an error message was displayed, stating: "The check type filter function has not been set".

6 years, 3 months

Check_MK Werk 6107: Agent bakery signing key passphrases could be visible in access logs

by Lars Michelsen

ID: 6107 Title: Agent bakery signing key passphrases could be visible in access logs Component: WATO Level: 2 Class: Security fix Version: 1.6.0i1 When you are using the agent bakery for creating and distributing your monitoring agents it is likely that this change is relevant for you. In some parts of the GUI, after entering the passphrase of the agent signing keys, it could happen that the signing key passphrase you enter is written to the apache access log of your Check_MK server. As a result it may be visible in clear text to local system users (e.g. users with access to the command line) which scan the logs for it. This affects the access log of the system apache (normally located at /var/log/apache2) and the access log (/omd/sites/[site]/var/log/apache/*) of the sites apache (master site in distributed setups). You may want to scan the log files for the string "key_p_passphrase" to check whether or not you are affected. It can be done e.g. with: zgrep key_p_passphrase /var/log/apache2/access* /omd/sites/*/var/log/apache/access* In case you find something, you should clean it up. Delete the file or remove the secrets from that file. Even when it seems unlikely that your key has been compromised, it is recommended to stop using this signing key. Create a new key and proceed with this one.

6 years, 3 months

Check_MK Werk 6170: Raw Edition: Fixed monitoring using special agents

by Lars Michelsen

ID: 6170 Title: Raw Edition: Fixed monitoring using special agents Component: Core & setup Level: 2 Class: Bug fix Version: 1.6.0i1 When trying to monitor hosts using special agents as data sources with nagios, this failed with an error like this: "UNKN - [special_vsphere] 'vsphere'UNKN, Got no information from host, execution time 0.0 sec"

6 years, 3 months

Check_MK Werk 6154: Fixed different Check_MK calls (parent scan, baking, rrd conversion) in some cases

by Lars Michelsen

ID: 6154 Title: Fixed different Check_MK calls (parent scan, baking, rrd conversion) in some cases Component: Core & setup Level: 2 Class: Bug fix Version: 1.6.0i1 When using some check specific configuration variables (like e.g. fileinfo_groups), the mentioned Check_MK calls could not be used. An error like this was shown: Cannot read in configuration file /omd/sites/beta/etc/check_mk/conf.d/wato/rules.mk: name 'fileinfo_groups' is not defined

6 years, 3 months

Check_MK Werk 6153: Fixed broken notifications and alert handling (Regression in 1.5.0b5)

by Lars Michelsen

ID: 6153 Title: Fixed broken notifications and alert handling (Regression in 1.5.0b5) Component: Notifications Level: 2 Class: Bug fix Version: 1.6.0i1 The notifications and alert handling were not working correctly at all. Better use the 1.5.0b5 only in test environments where you don't need these features.

6 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2