Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

by Ronny Bruska

ID: 7408 Title: Splunk Monitoring Component: Checks & agents Level: 2 Class: New feature Version: 1.6.0i1 A special agent and checks to support monitoring of splunk instances. With the first checks it is possible to monitor: LI: Licenses on their state and expiration LI: License usage LI: Splunk system messages LI: Splunk jobs LI: Splunk health (component monitoring) LI: Splunk alerts (fired alerts within splunk)

5 years, 3 months

Checkmk Werk 7339: Fixed broken mail notifications with Nagios core (1.5.0p14 regression)

by Lars Michelsen

ID: 7339 Title: Fixed broken mail notifications with Nagios core (1.5.0p14 regression) Component: Notifications Level: 2 Class: Bug fix Version: 1.6.0i1 Unfortunately, version 1.5.0p14 contained a bug that prevented mail notifications when using the Nagios core. According to our knowledge users of the Microcore are not affected. The error is displayed as follows in var/log/notify.log: C+: 2019-04-17 09:15:19 Preparing rule based notifications 2019-04-17 09:15:19 Found 0 user specific rules 2019-04-17 09:15:19 Global rule 'Notify all contacts of a host/service via HTML email'... 2019-04-17 09:15:19 -> matches! 2019-04-17 09:15:19 - adding notification of lm via mail 2019-04-17 09:15:19 Executing 1 notifications: 2019-04-17 09:15:19 * notifying lm via mail, parameters: host_subject, from, service_subject, disable_multiplexing, bulk: no 2019-04-17 09:15:19 executing /omd/sites/stable/share/check_mk/notifications/mail 2019-04-17 09:15:19 Output: Cannot send HTML email: empty destination email address 2019-04-17 09:15:19 Plugin exited with code 2 C-:

5 years, 3 months

Check_MK Werk 7344: Changing all setuid root binaries to use linux capabilities

by Lars Michelsen

ID: 7344 Title: Changing all setuid root binaries to use linux capabilities Component: Core & setup Level: 2 Class: Security fix Version: 1.6.0i1 In Linux there is the option to give a binary a SETUID bit. This bit gives the processes created by the binary all privileges of the binary file owner. There is also a more advanced concept called "linux capabilities" which makes it possible to give these processes only a specific set of permissions. In past versions Check_MK used SETUID root binaries in several places for different reasons. <ul> <li>check_dhcp / check_icmp: Active check plugins which need this permission to be able to open their raw sockets for sending and receiving their packets.</li> <li>bin/mkeventd_open514: Open SNMP trap or sylog ports for receiving messages.</li> <li>lib/cmc/icmpsender / lib/cmc/icmpreceiver: CEE/CME only: Open raw sockets for sending and receiving packets.</li> </ul> SETUID root binaries are problematic in terms of security, because they could be used for getting root privileges in case an attacker finds an attackable security flaw in them. Once exploited the attacker would gain full root access on the Check_MK system. Because all of these binaries need the privilege for a very specific known reason, we have now removed the SETUID bit from these binaries and are now setting individual linux capabilities to them. The capabilities have the advantage that they don't give full root access to the processes created with the binary. Instead they give only a defined set of permissions.

5 years, 4 months

Check_MK Werk 7474: check_mk_agent: Cache information for local checks

by Moritz Kiemer

ID: 7474 Title: check_mk_agent: Cache information for local checks Component: Checks & agents Level: 2 Class: New feature Version: 1.6.0i1 For local checks running asynchronously the cache age information is now included in the agent output. Services corresponding to outdated check data will become stale. Previously the user was not able to recognize outdated data in this case.

5 years, 4 months

Check_MK Werk 7415: Extensions for the Kubernetes special agent and checks

by Tom Baerwinkel

ID: 7415 Title: Extensions for the Kubernetes special agent and checks Component: Checks & agents Level: 2 Class: New feature Version: 1.6.0i1 This werk introduces multiple extensions for the Kubernetes special agent, new checks and inventory plugins: - The special agent now provides piggyback data for Pods, Deployments and Services. - The piggyback output is optional and can be configured via the rule for the special agent. - The special agent now outputs the Kubernetes labels for piggyback hosts. They are shown in the HW/SW invenotry and on the host detail page of the hosts. You can add the labels to other views and use the labels to filter your views. The labels will be used in more upcoming features in the future. - The check k8s_resouces is now used for Pods as well. - The new summary check k8s_pod_container for the Pods of a container is added. - The new inventory plugin k8s_pod_info shows Pod information in the HW/SW inventory. - The new check k8s_replicas monitors the replica sets of Deployments. - The new inventory plugin k8s_service_info shows information about Kubernetes Services. - The new inventory plugin k8s_selector shows the selectors of Kubernetes Services. - The new check k8s_service_port monitors the Ports defined for Kubernetes Services.

5 years, 4 months

Check_MK Werk 7407: check_elasticsearch_query: New active check to query elasticsearch

by Ronny Bruska

ID: 7407 Title: check_elasticsearch_query: New active check to query elasticsearch Component: Checks & agents Level: 2 Class: New feature Version: 1.6.0i1 You can now query the occurrence of log messages in elasticsearch for a specified interval. It is possible to set warn/crit level on the message count. It is possible to use free-text search or set a defined index and/or fieldname to search.

5 years, 4 months

Check_MK Werk 7341: Web-API: Add API calls for the new Grafana datasource

by Lars Michelsen

ID: 7341 Title: Web-API: Add API calls for the new Grafana datasource Component: Multisite Level: 2 Class: New feature Version: 1.6.0i1 We'll release a Grafana datasource for Check_MK shortly. To be able to use the datasource with the current stable version of Check_MK we backport the API calls that are needed for this datasource with this werk. If you are curious, you can have a look at the code of the datasource: https://github.com/tribe29/grafana-checkmk-datasource You could even setup the datasource with a daily build or starting with 1.5.0p16 from now. We are heading to make this plugin directly available via grafana.com as official plugin in the next couple of days.

5 years, 5 months

Check_MK Werk 7406: Opsgenie: Notification plugin

by Ronny Bruska

ID: 7406 Title: Opsgenie: Notification plugin Component: Notifications Level: 2 Class: New feature Version: 1.6.0i1 Check_MK now supports integration with Opsgenie. You can create, close and acknowledge alerts. It is possible to set optional parameter via the associated WATO rule, eg. "Responsible Team", "Actions", "Tags" and "Entity".

5 years, 5 months

Check_MK Werk 7336: labels: New inventory script to discover generic host labels

by Lars Michelsen

ID: 7336 Title: labels: New inventory script to discover generic host labels Component: HW/SW Inventory Level: 2 Class: New feature Version: 1.6.0i1 A new HW/SW inventory script has been added that works on a generic "<<<labels>>>" section. It is used to discover host labels from this section. The first agent that produces this section is the Kubernetes special agent. It creates the label sections for all kind of objects that are monitored by Check_MK. This makes Check_MK automatically import the labels configured in Kubernetes. You can now use them to filter your views, dashboards and in the future also create rules in WATO based on them.

5 years, 5 months

Check_MK Werk 7333: Introduce predefined conditions for rulesets

by Lars Michelsen

ID: 7333 Title: Introduce predefined conditions for rulesets Component: WATO Level: 2 Class: New feature Version: 1.6.0i1 In the rule-based configuration of Check_MK ("Host & Service Parameters" and "Manual Checks") it often happens that rules with the same conditions have to be created in different rule chains. With a larger number of rules, this quickly becomes confusing. To improve this situation we have now added a feature called "Predefined conditions". The idea is to preconfigure conditions in a central place, to which you can later refer in the individual rule chains. A predefined condition currently always consists of a full set of conditions (folder, tags, host specification, service specification). A rule can either use explicit conditions, as before, or refer to a predefined condition now. You access the predefined conditions via a context button from the pages on which you manage your rule chains.

5 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2