Update auf Version 2.3.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.3.0 erfordert etwas höhere Systemressourcen als 2.2.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. Alleine das Update des Python-Interpreters von Version 3.11 auf 3.12 verursacht eine Lastzunahme im einstelligen Prozentbereich. Umfangreichere Checks gerade im Cloud-Bereich können je nach Anteil an der Gesamtmenge der Checks für typischerweise 10–15 % (in Extremfällen um 20 %) mehr Last sorgen.

Was müssen Sie tun? Stellen Sie sicher, dass genügend freie Kapazitäten vorhanden sind. Als Faustregel gilt: Liegt die Load unter Zahl der Prozessorkerne × 0,8 und die CPU Utilization unter 70 %, sind keine Probleme zu erwarten. Liegt einer der beiden Werte oder beide höher, schaffen Sie genügend freie Kapazitäten, beispielsweise indem Sie Test-Instanzen auf demselben Server deaktivieren oder Hosts auf andere Instanzen verschieben.

In der Checkmk Version 2.3.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.2.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.2.0 und 2.3.0 unterstützt wird. Welche Linux-Distributionsversionen Checkmk unterstützt, erfahren Sie in der Update-Matrix für 2.3.0 und auf der Download-Seite nachdem Sie die Checkmk-Version und Ihre Linux-Distribution ausgewählt haben.

Kurz nach Erscheinen von Ubuntu 24.04 LTS werden wir Pakete von Checkmk 2.2.0 und 2.3.0 für diese Distributionsversion bereitstellen. Dies erlaubt es Ihnen, zunächst auf die neueste Patch-Version von Checkmk 2.2.0 zu aktualisieren, dann das Update von Ubuntu 23.10 STS nach 24.04 LTS durchzuführen und hier schließlich auf die neueste Patch-Version von Checkmk 2.3.0 zu aktualisieren.

Mit Checkmk Version 2.3.0 (und 2.2.0p21) wird unter SUSE Linux Enterprise Server 15 Service Pack 3 und 4 die Abhängigkeit zur Laufzeitumgebung der Programmiersprache PHP von Version 7 auf Version 8 angehoben.

Betrifft Sie das? Ja, als Nutzer von SLES 15 SP3/SP4. Das Update ist etwas aufwendiger, da Paketquellen für die veraltete Version 7 deaktiviert und für die neue Version 8 aktiviert werden müssen.

Was müssen Sie tun? Falls Sie neben Checkmk Anwendungen auf Ihrem Server nutzen, welche die Programmiersprache PHP verwenden, stellen Sie vorbereitend sicher, dass diese problemlos mit PHP 8 zurecht kommen. Bereiten Sie dann das bereits für das Update auf 2.2.0p21 (oder höher), welches für die Installation von Checkmk 2.3.0 obligatorisch ist, die Änderung der Paketquellen vor, wie sie in Werk #16025 beschrieben wird.

Checkmk 2.3.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.

Checkmk 2.3.0 liefert erstmals OpenSSL in Version 3.0 statt bisher 1.1 mit. Diese Änderung hat Auswirkungen auf fast alle Komponenten, welche Secure Socket Layer oder Transport Level Security nutzen.

Betrifft Sie das? Da OpenSSL 3 mittlerweile eine weite Verbreitung erlangt hat, sind kaum Überraschungen zu erwarten. Zu Problemen – vor allem bei aktiven Checks – kann es kommen, wenn Verbindungen zu Geräten hergestellt werden sollen, die alte Ciphers erwarten oder Renegotiation versuchen. Meist handelt es sich um alte Netzwerkgeräte (Switches, Drucker…​), die keine Updates mehr erhalten. In einigen Fällen sind ältere Dienste auf Linux-Distributionen oder Unix-Versionen betroffen, die immer noch mit Updates versorgt werden.

Was müssen Sie tun? Versuchen Sie möglichst im Vorfeld, Geräte ausfindig zu machen, bei denen Probleme zu erwarten sind. Gute Indikatoren hierfür sind Alter und wie lange Updates zurück liegen. Testen Sie diese Geräte mit Checkmk 2.3.0. Treten Probleme auf, haben Sie zwei Möglichkeiten:

Mit Checkmk 2.3.0 wechselt die Managed Services Edition die Basis von der Standard Edition zur Cloud Edition. Dies bedeutet nicht nur, dass die Managed Services Edition den erweiterten Funktionsumfang der Cloud Edition erhält, sondern auch, dass das Lizenzmanagement an das der Cloud Edition angeglichen wird.

Betrifft Sie das? Dies betrifft nur Benutzer der Managed Services Edition, andere Formen des verteilten Monitorings sind nicht betroffen.

Was müssen Sie tun? Das Update einer Managed Services Edition auf 2.3.0 folgt der generellen Prozedur in verteilten Umgebungen mit verteiltem Setup. Allerdings muss sichergestellt sein, das die Zentralinstanz noch unter Checkmk 2.2.0 die Lizenzinformationen an bereits auf Checkmk 2.3.0 aktualisierte Remote-Instanzen übertragen kann.

Da die notwendigen Änderungen erst in Checkmk 2.2.0p17 (Werk #16193) implementiert sind, müssen Sie folglich die Zentralinstanz mindestens auf diese Version aktualisieren. Damit ist die Übertragung der Lizenzinformationen sichergestellt. Anschließend können die Remote-Instanzen auf 2.3.0 aktualisiert werden und abschließend die Zentralinstanz.

Unabhängig von der hier genannten Mindestanforderung an die 2.2.0p17 empfehlen wir, auf allen beteiligten Instanzen zuerst das Update auf die letzte verfügbare Patch-Version der 2.2.0 durchzuführen und erst dann mit dem Update auf 2.3.0 zu beginnen.

Checkmk 2.3.0 erstellt keine SHA1-Signaturen für Agentenpakete mehr. Die Prüfung von SHA256-Signaturen wurde mit Checkmk 2.2.0p8 eingeführt. Damit Agenten-Updates auf Version 2.3.0 automatisch stattfinden können, müssen die Agenten vorher auf Version 2.2.0p8 oder höher aktualisiert werden.

Betrifft Sie das? Dies betrifft Sie, wenn Sie automatische Agenten-Updates durchführen, aber Patch-Versionen des Agenten gelegentlich auslassen. Es betrifft Sie außerdem, wenn Ihr Deployment vorbereitete Betriebssystem-Images verwendet, die den Checkmk Agent Updater mit ausliefern und sich auf automatische Installation/Aktualisierung verlassen.

Was müssen Sie tun? Stellen Sie sicher, dass alle Agenten, die automatisch aktualisiert werden sollen, mindestens auf Version 2.2.0p8 aktualisiert wurden. Überprüfen Sie insbesondere vorbereitete Betriebssystem-Images und aktualisieren Sie den dort vorhandenen Agenten ebenfalls auf Version 2.2.0p8 oder höher. Und wenn Sie gerade mit Agenten-Updates beschäftigt sind, können Sie bereits jetzt das per Agentenbäckerei ausgelieferte Zertifikat hinzufügen,, sofern dieses später nötig ist.

Einige Plugins, die als deprecated markiert waren, wurden entfernt und erfordern gegebenenfalls manuelle Installation, falls diese noch benötigt werden. Details erläutert Werk #16359.

Der offizielle Support für den Checkmk-Agenten unter Windows Server 2008 und Windows 7 durch die Checkmk GmbH endete bereits mit der Veröffentlichung von Checkmk 2.2.0. Dennoch war der Betrieb unter Windows Server 2008 R2 und Windows 7 ohne Einschränkungen weiter möglich. Mit 2.3.0 sind Einschränkungen in Kauf zu nehmen: Die bisherige Möglichkeit, per Regel der Agentenbäckerei eine Python 3.4 Laufzeitumgebung für Windows-Agenten mitzuliefern fällt in 2.3.0 weg.

Betrifft Sie das? Hoffentlich nicht: Der Wegfall betrifft Sie nur, wenn Sie in Python geschriebene Agentenplugins auf Windows Server 2008 R2 oder Windows 7 (beide End of Life bereits in 2020) nutzen. Auf allen neueren Windows-Versionen laufen aktuelle Python-Versionen. Auf allen noch älteren Windows-Versionen – wie Windows Server 2008 R1 oder Windows Vista – konnte der Agent bereits in Version 2.2.0 nicht mehr benutzt werden.

Was müssen Sie tun? Wenn Sie diese Windows-Systeme weiterhin überwachen wollen, müssen Sie Laufzeitumgebung für Agentenplugins, die Python benötigen, selbst bereitstellen: Installieren Sie auf betroffenen Systemen Python 3.4 manuell. Stellen Sie für diese Systeme in der Regel Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Windows modules > Install Python runtime environment die Einstellung Install Python runtime environment > Installation auf Never install Python with the agent. Beachten Sie, dass wir für derart alte Windows-Systeme keinen Support garantieren können und neue Agentenversionen in Patch-Releases nicht mehr testen.

mod_auth_mellon ist ein Software-Modul für Apache, das Dienste zur Authentifizierung (authentication) über Secure Assertion Markup Language (SAML) bereitstellt. Die Anbindung an SAML-Authentifizierungsdienste war in Checkmk 2.2.0 auf zwei Arten möglich: Auf Apache-Ebene mit mod_auth_mellon (bis Version 2.1.0 die einzig unterstützte Möglichkeit) oder in den kommerziellen Editionen von Checkmk die eingebaute SAML-Authentifizierung. Mit Version 2.3.0 wird mod_auth_mellon nicht mehr mit der Checkmk-Software ausgeliefert.

Betrifft Sie das? Dies betrifft Sie, wenn Sie die SAML-Authentifizierung mit mod_auth_mellon nutzen.

Was müssen Sie tun? Nutzer der kommerziellen Editionen sollten vor dem Update auf 2.3.0 die SAML-Authentifizierung auf die in Checkmk integrierte Lösung umstellen.

Falls Sie die Raw Edition benutzen, können Sie bereits vor dem Update systemweit mod_auth_mellon nach der Anleitung auf der Projektseite installieren. Stellen Sie dann die Zeile zum Laden des Moduls in der Konfigurationsdatei ~/etc/apache/conf.d/auth.conf auf den systemweiten Installationspfad um. Das Installationsverzeichnis kann je nach verwendeter Distribution variieren:

Starten Sie Ihre Instanz nach der Änderung neu. Testen Sie schließlich – noch unter 2.2.0 – ob die SAML-Authentifizierung weiterhin funktioniert. Ist dies der Fall, sind nach dem Update keine Schwierigkeiten zu erwarten.

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

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 haben. Wenn Sie unsicher sind, führen Sie die im folgenden Schritt beschriebene Prüfung durch.

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.

Der Prometheus-Spezialagent bot kube-state-metrics als Datenquelle, dessen Checks nicht mehr unterstützt werden. Diese wurden mittlerweile durch verbesserte Gegenstücke im Kubernetes-Agenten ersetzt (siehe Werk #14572). Zudem wurden in den Regeln Prometheus und Alertmanager die Angabe von IP-Adresse/Host-Name, Port und Pfadpräfix durch ein einziges Eingabefeld Custom URL abgelöst (siehe Werk #14573).

In beiden Fällen funktionierte das alte Verfahren weiterhin in 2.2.0. Zur Verwendung in 2.3.0 müssen Sie jedoch Ihre Konfiguration auf das neue Verfahren umgestellt haben.

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?

In Checkmk 2.3.0 wurden einige intern Programmierschnittstellen (APIs) umgebaut. So werden einige bislang ad-hoc definierte APIs durch wohl spezifizierte ersetzt. Daneben wurden die bereits in 2.0.0 als deprecated gekennzeichneten Check-APIs endgültig entfernt.

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

Was müssen Sie tun? Überprüfen Sie selbst geschriebene Erweiterungen und solche von Drittanbietern auf ihre Funktionsfähigkeit. Da die neuen APIs während Checkmk 2.3.0 parallel zu den alten benutzt werden können und Änderungen an den bestehenden APIs klein ausfallen konnten, werden die meisten Erweiterungen ohne Modifikationen weiter benutzbar sein. Sollten Änderungen notwendig sein, raten wir dazu, gleich auf die neuen APIs zu migrieren, die ab Checkmk 2.4.0 die alten APIs vollständig ersetzen.

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.3.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-Releases – 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.2.0 darauf hin abzuklappern, welche Auswirkungen diese auf das Update haben können. Seit Checkmk 2.3.0 werden solche Werks nämlich nicht mehr weiter geschleppt, sondern nach Rückfrage beim Update gelöscht (Werk #15292).

Es ist zudem eine gute Idee, sich bereits vor dem Update einen Überblick über die inkompatiblen Änderungen der Version 2.3.0 zu 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. Ist sichergestellt, dass ein Werk keine Auswirkungen hat oder Sie haben benötigte Änderungen vorgenommen, bestätigen Sie es 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 der Checkmk 2.3.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.3.0 nicht grundlegend verändert. Die generellen Abläufe, die Sie aus der Version 2.0.0 und 2.2.0 kennen, können Sie auch in der 2.3.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.3.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.

Das Verhalten des Kommandozeilenparameters --trust-cert des Befehls cmk-update-agent wurde geändert. Bislang wurde die gesamte Zertifikatskette geprüft und dem in der Hierarchie höchsten gefundenen selbst signierten Zertifikat vertraut, in der Regel ist dies das Root- oder ein Intermediate-Zertifikat. Ab Checkmk 2.3.0 wird nur das Serverzertifikat importiert und diesem vertraut.

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie sich bei der Registrierung von Hosts für automatische Agenten-Updates auf --trust-cert verlassen und daneben kein Zertifikat per Agentenbäckerei bereitstellen. In diesem Fall verlieren ab Checkmk 2.3.0 Hosts bereits bei Ablauf des Serverzertifikats die Vertrauensstellung, mit Checkmk 2.2.0 registrierte Hosts erst bei Ablauf der Root- oder Intermediate-Zertifikate.

Was müssen Sie tun? Wir empfehlen, zeitnah nach dem Update auf 2.3.0 die korrekten Zertifikate per Agentenbäckerei bereitzustellen und ein Update aller Agenten durchzuführen, um so ein konsistentes Verhalten bei allen Hosts herzustellen, die den Agent Updater verwenden.

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.

Bis Checkmk 2.2.0 war der Windows-Agent auf das zusätzliche Plugin Windows: State and Performance of Network Interfaces angewiesen, um den Status von Netzwerk-Interfaces korrekt zu übermitteln. Ohne Plugin war der Status immer up. Ab Checkmk 2.3.0 kann der Agent alleine den korrekten Status übermitteln (Werk #15839).

Betrifft Sie das? Je nachdem, in welchem Umfang Sie das Plugin verteilt haben und ob Sie bei Hosts ohne Plugin das Monitoring des Zustands von Netzwerk-Interfaces deaktiviert haben, kann Sie das betreffen. Hosts, die bisher kein Plugin verwendet haben und deren Netzwerk-Interfaces ins Monitoring aufgenommen waren, werden viele Schnittstellen von up nach down wechseln, damit den Status CRIT annehmen und so Benachrichtigungen auslösen.

Was müssen Sie tun? Überprüfen Sie, ob der ermittelte Zustand der betroffenen Netzwerkschnittstellen der gewünschte ist. Führen Sie dann für betroffene Hosts die Service-Erkennung neu durch. Nutzen Sie die Gelegenheit, um zunächst wenigstens für Ihre Windows-Hosts die Empfehlungen des Blog-Artikels Netzwerk-Monitoring mit Checkmk: 3 rules to rule them all umzusetzen. Für Windows sind die erwähnten Einstellungen in der Regel Network interfaces on Windows vorzunehmen.

Bei Checkmk Cloud Edition und Managed Services Edition mit verteiltem Setup werden mitunter beim Update keine Lizenzinformationen zu Remote-Instanzen synchronisiert.

Betrifft Sie das? Falls Sie unmittelbar nach dem Update einen vollständigen Überblick über Ihre Lizenznutzung benötigen, sind Sie möglicherweise betroffen. Überprüfen Sie den Lizenzstatus und stoßen Sie gegebenenfalls die Synchronisierung manuell an.

Was müssen Sie tun? Werfen Sie unter Setup > General > Distributed Monitoring einen Blick in die Übersicht der Remote-Instanzen und suchen Sie Instanzen, welche mit License state: trial gekennzeichnet sind. Um eine unmittelbare Synchronisation für diese Instanzen zu erzwingen, führen Sie unter Setup > Licensing eine Überprüfung der Lizenz durch oder speichern Sie die Lizenzeinstellungen. Sollte dieser Schritt vergessen werden, wird in der Regel innerhalb von sieben Tagen nach dem Update eine Synchronisierung der Lizenzdaten im Hintergrund durchgeführt.

Checkmk 2.3.0 enthält einen neuen aktiven Check für HTTP-Verbindungen und Zertifikate, der wesentlich performanter, robuster und besser zu konfigurieren ist, als der bisherige check_http. Zudem ist es mit einer einzigen Regel nun möglich, mehrere Dinge auf einmal zu überwachen, beispielsweise HTTP Response Code, Antwortzeit und Zertifikatsgültigkeit.

Den neuen Check HTTP web service finden Sie unter Setup > Services > HTTP, TCP, Email, …​ im Kasten Networking. Er wird mittelfristig den alten Check HTTP service komplett ablösen, den Sie auf der gleichen Seite finden können. Aus diesem Grund raten wir dazu, beim Neuanlegen von Hosts den bisherigen Check nicht mehr zu verwenden und Hosts im Bestand nach und nach auf den neuen Check zu migrieren.

Migrationshilfen werden während des Lifecycle von Checkmk 2.3.0 bereitgestellt werden, allerdings ist eine komplett automatisierte Migration tendenziell schwierig, weil bei vielen Hosts Regeln von zwei Checks zusammengeführt werden müssen, um von der verbesserten Effizienz zu profitieren.

Weitere Informationen finden Sie in den beiden Werks #15514 und #15515.

Basisfunktionalität für die Prüfung von Zertifikaten enthielt der bisherige check_http und der im vorherigen Abschnitt erwähnte check_httpv2 verbessert sie noch einmal. Allerdings haben beide einige Gemeinsamkeiten: Zunächst sind sie eben nur anwendbar, wenn ein Zertifikat an einem HTTPS-Endpunkt verwendet wird, zudem fehlt die Möglichkeit einer detaillierten Untersuchung der Zertifikate beispielsweise auf enthaltene Certificate Subject Alternative Names oder die ausstellende Stelle.

Die hieraus resultierenden Nutzerwünsche haben wir mit dem neuen check_cert umgesetzt. Alle Einstellungen des neuen Check certificates finden Sie ebenfalls unter Setup > Services > HTTP, TCP, Email, …​ im Kasten Networking.

Weitere Informationen finden Sie im Werk #15516.

Nach Checkmk Version 2.3.0 werden nur noch die wohl spezifizierten APIs zur Programmierung von Check-Plugins, Spezialagenten, Graphing, etc. unterstützt werden. Die Änderungen betreffen die Verzeichnisstruktur, Erkennung der Plugins (Discovery statt Registry) und natürlich die Funktionen und Objekte der APIs selbst. Einen Überblick über die größten Änderungen liefert Werk #16259.

Da die bisherigen APIs ab Checkmk 2.4.0 nicht mehr unterstützt werden, müssen bis zum Update auf 2.4.0 alle Plugins, welche die älteren APIs nutzen, auf die neuen APIs migriert sein.

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.3.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 wird während des Lifecycle von Checkmk 2.3.0 eingebaut und verbessert werden, zunächst als optional zu aktivierendes MKP (Werk #16589). Weitere Hintergründe und Alternativen erläutern wir im Blog-Artikel Monitoring management boards.

Bis Checkmk 2.2.0 konnte jeder Automationsbenutzer mit per GET-Parameter übergebenen Benutzernamen und Passwort angemeldet werden. Diese Möglichkeit wird ab Checkmk 2.3.0 zurückgefahren und schließlich ganz abgeschafft (Werk #16223). Mittelfristig müssen Sie daher Ihre Skripte auf Authentifizierung per HTTP-Header umstellen.

Zunächst macht 2.3.0 die Möglichkeit des Logins per GET-Parameter konfigurierbar. Die globale Einstellung Enable automation user authentication via HTTP parameters wird jedoch zunächst als Standard enabled verwenden. In Checkmk 2.4.0 wird der Standard dann zu disabled wechseln. Schließlich wird die Möglichkeit des Logins per GET-Parameter mit Checkmk 2.5.0 ganz wegfallen.

Checkmk 2.3.0 wird die letzte Version sein, 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. Aktualisieren Sie während des Lifecycle von Checkmk 2.3.0 daher Ihre ntopng-Installationen auf 6.x.