Checkmk werks level1 October 2020

checkmk-werks-lvl1@lists.checkmk.com

14 participants
63 discussions

Checkmk Werk 11532: filestats: fix crash when no files are found

by Lisa Pichler

ID: 11532 Title: filestats: fix crash when no files are found Component: Checks & agents Level: 1 Class: Bug fix Version: 2.0.0i1 The filestats check has a new feature "Additional Rules for Files". The check crashed when this feature was enabled and all files within the file group matched to one of the additiional rules specified. This has been fixed.

3 years, 11 months

Checkmk Werk 11531: filestats: missing information in service output

by Lisa Pichler

ID: 11531 Title: filestats: missing information in service output Component: Checks & agents Level: 1 Class: Bug fix Version: 2.0.0i1 The filestats check did not show all results when the feature "Additional Rules for Files" was activated and multiple subgroups were defined within the file group with this feature. This has been fixed.

3 years, 11 months

Checkmk Werk 10291: New Checkmk REST-API introduced

by Christoph Rauch

ID: 10291 Title: New Checkmk REST-API introduced Component: Core & setup Level: 3 Class: New feature Version: 2.0.0i1 With the Checkmk REST-API you can execute tasks you would normally perform manually in Checkmk's GUI on the Checkmk server via custom made scripts. REST stands for REpresentational State Transfer and describes an architecture for the exchange of data on distributed systems - especially for Web services. The implementation of this REST-API is done via the HTTP/1.1 protocol, where resources are addressed via URIs and accessed with HTTP methods (GET, PUT, POST, DELETE). The API is documented in a machine-readable schema and a human-readable document in English, with all resources, their input and output parameters and the associated value ranges. The API is specified in the OpenAPI 3.x specification format. The documentation for the API can be accessed in Checkmk's GUI under "Navigation > Help > REST-API Documentation". The specification file can be downloaded by clicking on the "Download OpenAPI Specification" button at the top of the documentation. A chapter in the Checkmk Manual specific to the REST-API is currently being created and will be ready for the 2.0.0 release.

3 years, 11 months

Checkmk Werk 11333: aws_agent: enable cache to reduce live data requests

by Lisa Pichler

ID: 11333 Title: aws_agent: enable cache to reduce live data requests Component: Checks & agents Level: 1 Class: Bug fix Version: 2.0.0i1 The first time the AWS agent is executed, it stores data in a cache file and only retrieves live data from the AWS API once the data in this file is considered out-of-date, or the configuration of the agent has changed. This is especially useful, because AWS charges a fee for each query to the API. The mechanism for determining whether the configuration of the agent has changed contained a defect, leading to undeterministic configuration signatures, which the agent erroneously interpreted as a configuration change. This has been fixed.

3 years, 12 months

Checkmk Werk 10315: Remove Support for SLES SP1, SP2 and SP3

by Alex Zurhake

ID: 10315 Title: Remove Support for SLES SP1, SP2 and SP3 Component: Linux Distributions Level: 3 Class: New feature Version: 2.0.0i1

3 years, 12 months

Checkmk Werk 11375: oracle_performance: Optionally new statistics for IO and system wait

by Marcel Arentz

ID: 11375 Title: oracle_performance: Optionally new statistics for IO and system wait Component: Checks & agents Level: 1 Class: New feature Version: 2.0.0i1 With this change, new statistics for IO and system waits are added optionally. These statistics need to be activated through the rule "Oracle performance discovery". They are not automatically available since the activation of these statistics may produce a lot of additional metric data. So this data will created only, if you decide so. To use the feature, you need to replace the agent plugin with the newest version and activate the new services through the mentioned ruleset above. You will be able to add up to three new services: LI:oracle_performance.iostat_ios: IO statistics displayed as raw IOs. LI:oracle_performance.iostat_bytes: IO statistics displayed in bytes. LI:oracle_performance.waitclasses: Details about the reasons the DB spends time waiting. <b>Important</b>: As fetching statistics about IOs may take a long time in some configurations, these data is fetched through the agent plugin asynchronously by default with section name iostats. If you change this section to synchronously, which is recommended in most cases, please check if you are able to optimize you indexing if needed to avoid such problems.

3 years, 12 months

Checkmk Werk 11374: oracle_performance: Optionally split services

by Marcel Arentz

ID: 11374 Title: oracle_performance: Optionally split services Component: Checks & agents Level: 1 Class: New feature Version: 2.0.0i1 The services created by the check plugin oracle_performance included several groups of performance data. To be able to create more detailed views, the information provided by this check plugin can now be splitted in up to three different services: LI:oracle_performance: Statistics for the buffer pool and library cache are still in the main service and cannot be moved into a separate service. LI:oracle_performance.dbtime: Statistics for the used DB times (CPU and Non-Idle Wait) may be isolated as a separate service. LI:oracle_performance.memory: Memory information may also be isolated. If so, additionally statistics for PGA will be computed and displayed. To use this new feature, the ruleset "Oracle performance discovery" has been implemented. The isolation of DB times or memory statistics can be configured independently to represent your specific requirements. If this ruleset is not used, all behaviour will stay the same as before - there is no need for interaction in this case. <b>Important</b>: Please be aware, that there is no automatic conversion of rrd data in case, you split up the services. This means, that you need to convert them manually, if you are using the single rrd format. Otherwise the historic metric data will still be available through the main service only while the new metric data will be stored in the newly created services.

3 years, 12 months

Checkmk Werk 11330: nimble_latency: changed metric unit to percent of total volume

by Lisa Pichler

ID: 11330 Title: nimble_latency: changed metric unit to percent of total volume Component: Checks & agents Level: 1 Class: Bug fix Version: 2.0.0i1 The check nimble_latency measures the latency of read and write I/O operations. The data is captured as the number of operations within several latency ranges (e.g. 1-2 milliseconds, 2-5 milliseconds, etc.). The data was reported as a time interval, rather than a count. This has been fixed, so that the number of operations within each range is now now shown as a percentage of the total number of operations across all the ranges.

3 years, 12 months

Checkmk Werk 11503: IPMI management board: Fix UDP file descriptor leak

by Lars Michelsen

ID: 11503 Title: IPMI management board: Fix UDP file descriptor leak Component: Core & setup Level: 1 Class: Bug fix Version: 2.0.0i1 In previous versions the IPMI management board monitoring could make the Checkmk or fetcher (in Checkmk 2.0) helper processes use more and more UDP sockets.

3 years, 12 months

Checkmk Werk 11502: Dynamic host configuration: Fix config activation on WATO enabled remote sites

by Lars Michelsen

ID: 11502 Title: Dynamic host configuration: Fix config activation on WATO enabled remote sites Component: DCD Level: 1 Class: Bug fix Version: 2.0.0i1 The dynamic host configuration is working in a special mode in distributed setups. The dcd on the remote site is executed to collect the information about the hosts locally and the dcd on the central site is processing this information and applies the changes in the central configuration. There was a case where the remote DCD operated in central mode, instead of remote site mode which made the DCD activate change on the remote site. This might result in pending changes on the remote site which in turn prevents an activation of changes from the central site. Technical details: This was caused by a "config reload" command being sent to the DCD before the DCD configuration was completely synchronized.

3 years, 12 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 October 2020