Update auf Version 2.4.0

Wie vor jedem Update einer produktiven Software sollten Sie auch vor dem von Checkmk die Aktualität Ihrer Backups prüfen.

Betrifft Sie das? Ja.

Was müssen Sie tun? Wenn Sie Ihre Backups automatisiert über Setup > Maintenance > Backups erstellen, prüfen Sie dort, ob die letzten Backup-Aufträge fehlerfrei durchgelaufen sind.

Weitere Informationen finden Sie in den Artikeln zu Backups und zum Thema Instanzen sichern und wiederherstellen.

Checkmk 2.4.0 erfordert in einigen Bereichen höhere Systemressourcen als 2.3.0. Daher ist es ratsam, vor dem Update zu ermitteln, welche freien Kapazitäten für Checkmk verwendete Server noch haben.

Betrifft Sie das? Ja. Allerdings hängt es stark von der Art der Nutzung von Checkmk ab, wie stark Sie betroffen sind.

Was müssen Sie tun? Stellen Sie sicher, dass genügend freie Kapazitäten vorhanden sind. Eine etwas höhere Prozessorlast ist bei Verwendung vieler aktiver Checks zu erwarten. Andere Bereiche konnten im Gegenzug optimiert werden, was in vielen Fällen zu einer Reduzierung der Prozessorlast führt. Als Faustregel gilt: Liegt die CPU load unter Zahl der Prozessorkerne × 0,8 und die CPU utilization unter 70 %, sind keine Probleme zu erwarten.

Die Arbeitsspeichernutzung von Checkmk 2.4.0 ist verglichen mit 2.3.0 etwa 30 % höher. Grund dafür ist umfangreicheres Caching häufig benötigter Daten, was zu geringeren Latenzen und höherer Performance auf Kosten der Arbeitsspeichernutzung führt.

Bei Verwendung von Piggyback im verteilten Monitoring benötigt der Message Broker RabbitMQ weiteren zusätzlichen Arbeitsspeicher und CPU Ressourcen. Gleiches gilt für den Open Telemetry Receiver.

Der Bedarf an Festplattenplatz steigt mit Checkmk 2.4.0 um bis zu 5 MB pro Host, die direkt nach dem Update belegt werden.

In Checkmk-Version 2.4.0 werden einige veraltete Distributionen nicht mehr unterstützt werden.

Betrifft Sie das? Das betrifft Sie, wenn auf Ihrem Checkmk-Server eine der folgenden – in der 2.3.0 noch unterstützten – Linux-Distributionen installiert ist:

Was müssen Sie tun? Führen Sie vor dem Update von Checkmk zuerst ein Versions-Upgrade der Linux-Distribution durch. Achten Sie darauf, dass die Zielversion der Linux-Distribution von Checkmk 2.3.0 und 2.4.0 unterstützt wird. Welche Linux-Distributionsversionen Checkmk unterstützt, erfahren Sie in der Update-Matrix für 2.4.0 und auf der Download-Seite nachdem Sie die Checkmk-Version und Ihre Linux-Distribution ausgewählt haben.

Kurz nach Erscheinen von Red Hat Enterprise Linux 10 werden wir Pakete von Checkmk 2.3.0 und 2.4.0 für diese Distributionsversion bereitstellen. Dies erlaubt es Ihnen, zunächst auf die neueste Patch-Version von Checkmk 2.3.0 zu aktualisieren, dann das Update von Red Hat Enterprise Linux 9 nach 10 durchzuführen und hier schließlich auf die neueste Patch-Version von Checkmk 2.4.0 zu aktualisieren.

Checkmk 2.4.0 nutzt neue JavaScript-Funktionen, die in älteren Browsern nicht zur Verfügung stehen. Welche Browser in welchen Versionen unterstützt werden, steht in den Release notes.

Betrifft Sie das? In der Regel werden Sie auf Desktop-Systemen automatische Updates auf die neueste Version aktiviert haben.

Was müssen Sie tun? Prüfen Sie die verwendete Browser-Version und installieren Sie gegebenenfalls einen aktuelleren Browser. Wenn Sie für die Anzeige von Dashboards Single Board Computer, Smart TVs oder Digital Signage Lösungen verwenden, auf deren Systembrowser Sie keinen Einfluss haben, testen Sie vor dem Update, ob benötigte Dashboards korrekt angezeigt werden. Kontaktieren Sie gegebenenfalls den Hardware-Hersteller für Updates.

Bis Checkmk 2.2.0 konnte jeder Automationsbenutzer mit per GET-Parameter übergebenem Benutzernamen und Passwort angemeldet werden. Diese Möglichkeit wurde ab Checkmk 2.3.0 zurückgefahren und wird in Version 2.5.0 ganz abgeschafft werden (Werk #16223). Mittelfristig müssen Sie daher Skripte oder automatische Logins auf Authentifizierung per HTTP-Header umstellen.

Zunächst machte 2.3.0 die Möglichkeit des Logins per GET-Parameter konfigurierbar. Die globale Einstellung Automation user authentication via HTTP parameters verwendete jedoch als Standard on. In Checkmk 2.4.0 wechselt der Standard nun zu off.

Betrifft Sie das? Auch diese Änderung betrifft vor allem Benutzer, die für die Anzeige von Dashboards Single Board Computer, Smart TVs oder Digital Signage Lösungen ohne angeschlossene Tastatur verwenden.

Was müssen Sie tun? Falls Sie automatisches Login per GET-Parameter verwenden, müssen Sie die globale Einstellung Automation user authentication via HTTP parameters auf on ändern. Da die Möglichkeit des Logins per GET-Parameter mit Checkmk 2.5.0 ganz wegfallen wird, sollten Sie das Login solcher Dashboards auf Basic Auth umstellen (beispielsweise per Browser-Erweiterung).

Checkmk 2.3.0 ist die letzte Version, die ntopng in den Versionen 5.x und 6.x unterstützt (Werk #16483). Mit Checkmk 2.4.0 wird die Unterstützung für ntopng 5.x eingestellt und nur noch ntopng 6.x unterstützt.

Betrifft Sie das? Diese Änderung betrifft Benutzer der kommerziellen Editionen, welche die Integration mit ntopng verwenden.

Was müssen Sie tun? Aktualisieren Sie vor dem Update von Checkmk auf 2.4.0 Ihre ntopng-Installationen auf 6.x.

Sind für einen Host Spezialagenten konfiguriert, werden in Checkmk 2.4.0 alle diese Spezialagenten ausgeführt. In früheren Versionen wurde nur ein Spezialagent ausgeführt, und zwar der erste in der alphabetischen Sortierung.

Betrifft Sie das? Diese Änderung ist nur relevant für Hosts, in deren Eigenschaften das Attribut Checkmk agent / API integrations auf API integrations if configured, else Checkmk agent gesetzt ist.

Es ist möglich, dass Sie versehentlich Regeln erstellt haben, die Hosts mehr Spezialagenten zugeordnet haben als benötigt. Diese zusätzlichen Regeln wurden bisher ignoriert, wenn sie alphabetisch hinter der ersten lagen. Beispiel: Sie haben Regeln für agent_acme und Regeln für agent_cyberdyne erstellt, und diese Regeln durch eine kleine Nachlässigkeit denselben Hosts zugeordnet. In Checkmk 2.4.0 wird nun nicht nur agent_acme sondern auch agent_cyberdyne für diese Hosts ausgeführt.

Was müssen Sie tun? Bei Verwendung von Spezialagenten, die auf APIs zugreifen, die Kosten verursachen können oder in ein Rate Limiting laufen, müssen Sie vorbereitend aktiv werden und die korrekte Zuordnung sicherstellen. Achten Sie auch bei Spezialagenten, die eine hohe CPU-Last oder viel Netzwerkverkehr verursachen, auf korrekte Zuordnung. Bedenken Sie auch, dass durch falsche Zuordnung von Spezialagenten bei Hosts plötzlich Services auftauchen, die dort nicht hingehören.

Checkmk 2.4.0 aktualisiert Python auf 3.12.3. Diese Aktualisierung betrifft in einer Instanz nachinstallierte Module. In vielen Fällen sind nachinstallierte Module mit Python 3.12.3 inkompatibel. Schlimmstenfalls überschreiben veraltete Module Funktionalität der von Checkmk mitgelieferten Module.

Betrifft Sie das? Dies betrifft Sie in der Regel nur, wenn Sie für selbst geschriebene oder aus der Exchange bezogene Spezialagenten oder agentenbasierte Check-Plugins explizit Python-Module nachinstalliert haben. Wenn Sie unsicher sind, führen Sie die im folgenden Schritt beschriebene Prüfung durch.

Dies betrifft Sie aber auch, wenn Sie den aktiven Check check_sql zur Überwachung von Oracle Datenbanken nutzen. Bis Checkmk 2.3.0p27 mussten Sie das Modul oracledb nachinstallieren, um diesen Check nutzen zu können. Seit 2.3.0p28 wird dieses Modul von Checkmk mitgeliefert (Werk #17370).

Was müssen Sie tun? Finden Sie zunächst heraus, ob und – wenn ja –, welche Python-Module in der Instanz installiert sind. Suchen Sie hierfür die Verzeichnisse dist-info und egg-info:

Notieren Sie die installierten Module und deinstallieren Sie diese anschließend:

Wie Sie mit deinstallierten Python-Modulen nach dem Update umgehen, erfahren Sie weiter unten.

Mit lokalen Dateien können Sie die von Checkmk bereitgestellte Funktionalität anpassen und erweitern. Diese Dateien befinden sich im lokalen Teil der Instanzverzeichnisstruktur, d.h. in ~/local und können in Erweiterungspaketen organisiert sein oder einfach so „herumliegen“. Lokale Dateien können bei einem Update Probleme bereiten, wenn sie nicht mehr zur neuen Checkmk-Version passen.

Betrifft Sie das? Da es für Checkmk bei einem Update nicht möglich ist, die Kompatibilität von lokalen Anpassungen vollständig sicherzustellen, sollten Sie Ihre Checkmk-Instanz vor einem Update daraufhin überprüfen, ob lokale Dateien bei Ihnen verwendet werden, welche das sind und wie sie organisiert sind.

Was müssen Sie tun?

Bereits in Checkmk 2.3.0 wurden einige Programmierschnittstellen (APIs), die in älteren Versionen ad-hoc definiert waren, durch versionierte, wohl spezifizierte ersetzt. Die älteren APIs konnten parallel weiter genutzt werden. Mit Checkmk 2.4.0 werden keine Maßnahmen mehr getroffen, Kompatibilität zu den alten APIs zu bewahren (Werk #17201). Das bedeutet, dass Plugins, welche die alten APIs nutzen, mit Checkmk 2.4.0 nicht mehr funktionieren werden.

Betrifft Sie das? Das Thema APIs betrifft Sie, wenn Sie die mit Checkmk ausgelieferten Check-Plugins um Ihre eigenen, selbst geschriebenen Plugins erweitert haben und/oder wenn Sie Plugins aus anderen Quellen nutzen.

Was müssen Sie tun? Stellen Sie vor dem Update auf 2.4.0 zunächst sicher, dass Sie auf die letzte Patch-Version von 2.3.0 aktualisiert haben. Vorhandene Erweiterungen, die nach einem Update auf 2.4.0 nicht mehr funktionieren werden, führen dann bei allen Benutzern mit der Berechtigung, MKPs zu verwalten zu Meldungen in der GUI, die wiederholt angezeigt werden (Werk #17649).

Überprüfen Sie selbst geschriebene Erweiterungen und solche von Drittanbietern auf die vollständige Verwendung der aktuellen APIs (cmk.agent_based.v2, cmk.server_side_calls.v1, cmk.graphing.v1 und cmk.rulesets.v1). Werden die älteren, nicht versionierten APIs oder cmk.agent_based.v1 verwendet, migrieren Sie diese auf die neuen APIs und die neue Ordnerstruktur. Informationen zur Migration finden Sie in Werk #16259 und in den Artikeln zur Entwicklung von Check-Plugins. Zudem stellen wir Skripte bereit, die bei der Migration helfen können.

Abgekündigte Endpunkte oder Parameter der Checkmk REST-API werden in der API-Dokumentation mit dem Symbol gekennzeichnet.

Betrifft Sie das? Das kann Sie betreffen, wenn Sie die Checkmk REST-API zum Beispiel in eigenen Skripten nutzen.

Was müssen Sie tun? Öffnen Sie die REST-API-Dokumentation mit Help > Developer resources > REST API documentation. Suchen Sie im Browser auf der Seite nach Deprecated, überprüfen Sie, ob Sie abgekündigte Elemente in Ihren Skripten verwenden, und ersetzen Sie diese vor dem Update. In der REST-API-Dokumentation finden Sie gewöhnlich Hinweise, wie Sie die in der neuen Version nicht mehr existierenden Funktionen ersetzen können.

Wie in jeder Checkmk Version, so gibt es auch in der aktuellen Version 2.4.0 Änderungen der Software – bei Checkmk in sogenannten Werks organisiert und dokumentiert –, die Rückwirkungen auf Ihre Checkmk-Installation haben können. Eine sogenannte inkompatible Änderung erfordert, dass Sie manuelle Anpassungen durchführen, um bestehende Funktionen weiterhin wie gewohnt ablaufen zu lassen und/oder neue Funktionen nutzen zu können.

Betrifft Sie das? In aller Regel wird es inkompatible Änderungen geben, die auch Ihre Checkmk-Installation betreffen. Eine generelle Aussage ist aber leider unmöglich. In diesem Artikel haben wir diejenigen Themen zusammengetragen, die für alle oder die meisten Checkmk-Installationen zutreffen. Es kann aber sein, dass es darüber hinaus weitere, für Sie relevante Änderungen gibt, zum Beispiel bei Checks, die Sie in Ihrer Installation verwenden.

Was müssen Sie tun? Nach jedem Update – auch solchen auf Patch-Versionen – zeigt Ihnen Checkmk Anzahl und Inhalt der inkompatiblen Änderungen und fordert Sie auf, diese zu prüfen und zur Kenntnis zu nehmen. Vor dem Update ist der richtige Zeitpunkt, liegen gebliebene Änderungen der Version 2.3.0 daraufhin abzuklappern, welche Auswirkungen diese auf das Update haben können. Seit Checkmk 2.3.0 werden solche Werks nämlich nicht mehr weitergeschleppt, sondern beim Update nach Zustimmung in einem Bestätigungsdialog gelöscht (Werk #15292).

Es ist zudem eine gute Idee, wenn Sie sich bereits vor dem Update einen Überblick über die inkompatiblen Änderungen der Version 2.4.0 verschaffen: Öffnen Sie die Liste der Werks auf der Checkmk-Webseite. In der Beschreibung eines Werks finden Sie Hinweise, was gegebenenfalls zu tun ist, um die Änderung kompatibel zu machen.

Nachdem Sie das Update durchgeführt haben, werden Ihnen in der Checkmk-Oberfläche Anzahl und Inhalt der inkompatiblen Änderungen angezeigt, und Sie werden aufgefordert, diese zu prüfen und zur Kenntnis zu nehmen. Bei der Prüfung helfen Links, so dass Sie mit wenigen Klicks herausfinden können, ob Sie eine betroffene Komponente nutzen. Haben Sie sichergestellt, dass ein Werk keine Auswirkungen hat oder Sie haben benötigte Änderungen vorgenommen, bestätigen Sie das Werk mit Acknowledge.

Im Folgenden beschreiben wir bewährte Vorgehensweisen (best practices), welche wir selbst bei Updates von großen Checkmk-Umgebungen befolgen. Diese sind sicherlich nicht in jeder Umgebung Pflicht, Sie können Ihnen den Prozess des Updates jedoch erleichtern.

Es gibt zwei unterschiedliche Vorgehensweisen, um das Update aller in einem verteilten Monitoring beteiligten Instanzen durchzuführen:

Insbesondere, wenn Sie die Aktualisierung im laufenden Betrieb anstreben, sollten Sie die Hinweise im allgemeinen Artikel zu Updates und Upgrades lesen.

Am eigentlichen Update der Software hat sich in Checkmk 2.4.0 nichts Grundlegendes geändert, d.h. Sie installieren die neue Version, führen das Update der Checkmk-Instanz durch, kümmern sich um Konflikte (falls es denn welche geben sollte) und überprüfen und bestätigen die inkompatiblen Änderungen.

Führen Sie die Update-Prozedur so aus, wie sie im Artikel zu Updates und Upgrades beschrieben ist.

Die Benutzeroberfläche (GUI) von Checkmk, die mit Version 2.0.0 komplett neu gestaltet wurde, hat sich auch in der 2.4.0 nicht grundlegend verändert. Die generellen Abläufe, die Sie aus den Versionen 2.0.0 bis 2.3.0 kennen, können Sie auch in der 2.4.0 unverändert anwenden. Allerdings haben sich Menüs, Menüeinträge, Symbole und andere Details geändert, um neue Funktionen verfügbar zu machen — und bestehende zu verbessern.

In den Artikeln dieses Handbuchs stellen wir Ihnen diese Änderungen vor - und im Leitfaden für Einsteiger finden Sie eine ausführliche Einführung, unter anderem in die wichtigsten Elemente der Benutzeroberfläche.

Wie jede Hauptversion, so bringt auch Checkmk 2.4.0 eine ganze Reihe neuer Check-Plugins mit sich. Sollten Sie den „Discovery Check“ nicht einsetzen, d.h. das automatische Update der Service-Konfiguration über die periodische Service-Erkennung, werden Sie auf einer ganzen Reihe von Hosts die Suche nach Services durchführen müssen.

Wenn Ihre Hosts entsprechend organisiert sind (z.B. in Ordnern), können Sie hierfür zumeist mit der Funktion Bulk discovery arbeiten. Diese finden Sie unter Setup > Hosts > Hosts und dann im Menü Hosts > Run bulk service discovery.

In einigen Fällen mussten Check-Plugins ausgelagert werden, oder Check-Plugins müssen auf neue APIs wechseln.

Betrifft Sie das? Das Risiko, davon betroffen zu sein, ist vorhanden, wenn Sie Hardware mit sehr langem Lebenszyklus vor allem mit Spezialagenten überwachen. Bei den Vorbereitungen des Updates von 2.3.0 nach 2.4.0 sind uns beispielsweise die Spezialagenten für viele NetApp-Geräte aufgefallen, die wir vom abgekündigten ZAPI auf das modernere REST-API umstellen mussten (Werk #16767). Den Agenten für Dell PowerConnect mussten wir aus Lizenzgründen in ein separates, in der Exchange erhältliches Paket auslagern (Werk #15359).

Was müssen Sie tun? Falls Services nach dem Update verschwinden, suchen Sie in den Werks nach dem Hersteller der überwachten Produkte. Meist werden Sie auf neue APIs umstellen oder in seltenen Fällen Pakete aus der Exchange verwenden müssen, um eine bestimmte Hard- oder Software zu überwachen.

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie für selbst geschriebene oder aus der Exchange bezogene Spezialagenten oder agentenbasierte Check-Plugins explizit Python-Module nachinstalliert hatten, und diese im Zuge der Vorbereitung des Updates entfernt haben.

Was müssen Sie tun? Finden Sie zunächst heraus, ob die zuvor deinstallierten Module bereits mit der neuen Checkmk-Version ausgeliefert werden, zum Beispiel:

Wird das Modul bereits gefunden, kennzeichnen Sie es in Ihren Notizen als nicht benötigt. Installieren Sie nicht mitgelieferte Module in Ihrer aktuellsten Version nach:

Testen Sie anschließend die Check-Plugins oder Spezialagenten, die auf in der Instanz installierte Python-Module angewiesen sind.

Checkmk enthält bereits seit 2.3.0 einen neuen aktiven Check für HTTP-Verbindungen und Zertifikate. Den Check HTTP web service finden Sie unter Setup > Services > HTTP, TCP, Email, …​ im Kasten Networking. Der neue Check ist wesentlich performanter, robuster und besser zu konfigurieren als der bisherige Check HTTP service. Zudem ist es nun mit einer einzigen Regel möglich, mehrere Dinge auf einmal zu überwachen, beispielsweise HTTP Response Code, Antwortzeit und Zertifikatsgültigkeit.

In Checkmk 2.4.0 wurden dem neuen Check einige selten benötigte Optionen des alten Checks hinzugefügt, um eine Migration zu erleichtern. Des Weiteren stellen wir ein Migrationsskript bereit, welches vorhandene Aufrufe und resultierende Services 1:1 abbildet. Verwenden Sie dieses Skript, um Services vom alten auf den neuen aktiven Check zu konvertieren, denn: Mit Checkmk 2.5.0 können keine neuen Regeln für den alten Check mehr konfiguriert werden. Später wird er komplett entfernt werden.

Nach durchgeführter Migration können Sie deutliche Performance-Vorteile erreichen, wenn Sie mehrere Regeln, die folglich mehrere Aufrufe des Checks verursachen, zusammenführen. In vielen Fällen können Sie auch aus einer Regel des neuen Checks mehrere Services generieren.

Generelle Informationen zum neuen Check finden Sie in den beiden Werks #15514 und #15515. Werk #17725 beschreibt das Migrationsskript. Ein ausführlicher Blog-Artikel erklärt die Details zu Möglichkeiten, Limitationen und Best-Practices bei der Vor- und Nachbereitung der Migration.

Sollten Sie auf Anwendungen stoßen, in denen der neue Check den alten keinesfalls ersetzen kann, können Sie sich die verwendete Kommandozeile analog zum hier beschriebenen Vorgehen anzeigen lassen. Anschließend haben Sie die Möglichkeit, via Setup > Other services > Integrate Nagios plugins den alten Check oder einen systemweit installierten check_http aufzurufen.

Die Bezeichnung Management Board steht für separate Steckkarten oder erweiterte BIOS-Funktionalität (Baseboard Management Controller/BMC, Management Engine/ME, Lights Out Management/LOM) zur Überwachung und Verwaltung der Hardware neben dem installierten Betriebssystem.

Bis Checkmk 2.4.0 können Management Boards auf zwei Arten konfiguriert werden: Als Eigenschaft eines Hosts oder als separater Host. Da die Konfigurierbarkeit als Eigenschaft eines Hosts sehr limitiert ist, wird diese Möglichkeit künftig wegfallen.

Die Unterstützung von Redfish kompatiblen Management Boards wurde in Checkmk 2.3.0 eingebaut und kontinuierlich verbessert, zunächst als optional zu aktivierendes MKP (Werk #16589). In Checkmk 2.4.0 ist Redfish-Monitoring fester Bestandteil der Software (Werk #17404). Hintergründe und Alternativen erläutern wir im Blog-Artikel Monitoring management boards.