Update auf Version 2.5.0

Updates von Checkmk müssen immer vom letzten Patch Release der Ausgangsversion zum letzten Patch Release der Zielversion durchgeführt werden. Ein Update von 2.4.0p1 nach 2.5.0p1 folgt daher diesem Pfad:

2.4.0p1   2.4.0p28   2.5.0p1

Major-Versionen können nicht übersprungen werden. Sollten Sie von 2.3.0 auf 2.5.0 aktualisieren wollen, führen Sie zunächst ein Update auf Version 2.4.0 durch.

Seit 2.4.0p24 verwendet Checkmk neue Namen der Editionen, die besser den Funktionsumfang repräsentieren. Wenn Sie zwischenzeitlich bereits ein Patch Release ab 2.4.0p24 installiert haben, kennen Sie die neuen Namen bereits aus der Web-Oberfläche. Während Checkmk 2.4.0 in Paketnamen das alte Editionskürzel verwendet, wechselt Checkmk 2.5.0 zu den neuen Namen. Für Paketnamen bedeutet das die folgende Änderung:

Falls Sie Installationsskripte erstellt haben, welche das alte Schema für Paketnamen verwenden, müssen Sie diese Skripte auf das neue Schema umstellen.

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.5.0 erfordert in einigen Bereichen höhere Systemressourcen als 2.4.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. Informationen zu den zu erwartenden Veränderungen in der Nutzung der Hardware-Ressourcen entnehmen Sie der Tabelle:

Checkmk 2.5.0 wechselt zu einem neuen Metrik-Backend für die Speicherung und Abfrage von OpenTelemetry-Daten.

Betrifft Sie das? Ja, sofern Sie OpenTelemetry-Daten bereits im Monitoring mit Checkmk 2.4.0 benutzen.

Was müssen Sie tun? Zunächst ist vor dem Update für das Metrik-Backend ein zusätzlicher Bedarf an Arbeitsspeicher einzuplanen. Da weniger Umwandlungen der OpenTelemetry-Daten stattfinden, ist der CPU-Bedarf geringer als bei Checkmk 2.4.0. Der Umbau auf das Metrik-Backend bedeutet, dass sie den Großteil Ihrer Konfiguration für das OpenTelemetry-Monitoring neu erstellen müssen. Einen Überblick liefert Werk #19133, die Einrichtung erklärt der Artikel zum OpenTelemetry-Monitoring.

In Checkmk 2.5.0 wird die Lizenzierung für alle kommerziellen Editionen vereinheitlicht. Das bedeutet für Checkmk Pro, dass Sie ein Update nur dann durchführen können, wenn Checkmk Pro in Checkmk 2.4.0 bereits lizenziert ist.

Für eine nicht lizenzierte Checkmk Pro schlägt der Check vor dem Update mit folgender Meldung fehl:
Update aborted with Error: A valid and non expired license is needed before updating

Betrifft Sie das? Dies betrifft nur Benutzer von Checkmk Pro. Die anderen Editionen sind nicht betroffen.

Was müssen Sie tun? Vergewissern Sie sich in Checkmk 2.4.0, dass die Lizenzdaten eingegeben und an Checkmk GmbH/Inc. übertragen wurden. Wie Sie dabei vorgehen, erfahren Sie im Artikel zur Lizenzierung des Handbuchs für Checkmk 2.4.0.

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

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

Bislang war das Agentenplugin für die automatischen Agenten-Updates unter Linux als Binary für die Plattformen x86_64 (64-Bit) und i586 (32-Bit) verfügbar. Mit Checkmk 2.5.0 fällt die 32-Bit-Unterstützung weg (Werk #18925).

Betrifft Sie das? Das betrifft Sie, wenn Sie den Agent Updater nutzen und wenn Sie für Hosts, die mit Linux auf 32-Bit i586 laufen, den Agent Updater als Binary ausliefern.

Mit 2.0.0 wechselte Checkmk zu Python 3 als Standardinterpreter für in Python geschriebene Agentenplugins (Werk #12149). In 2.5.0 fällt die Unterstützung für Python 2 komplett weg (Werk #16908).

Betrifft Sie das? Dies betrifft Sie, wenn Sie ältere Hosts überwachen, die noch keinen Python 3-Interpreter installiert haben.

Siehe Werk #17685, #17686, #17687, #17688, #17689, #18111 und #18112.

Checkmk 2.5.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 Systemvoraussetzungen.

Betrifft Sie das? In der Regel werden Sie auf Desktop-Systemen automatische Updates auf die neueste Browser-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 ist in Version 2.5.0 abgeschafft (Werk #16223 und #17345).

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? Lesen Sie im Artikel zu Dashboards wie Sie das Teilen einzelner Dashboards in Checkmk ab 2.5.0 aktivieren können. Alternativ zum Weg über die GUI können Sie die Tokens zum Teilen von Dashboards auch über das REST-API generieren (Werk #19334).

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

Betrifft Sie das? Dies betrifft Sie, falls in Ihrer Instanz Python-Module nachinstalliert wurden. Das kann zum Beispiel der Fall sein, weil Sie für selbst geschriebene oder aus der Exchange bezogene Spezialagenten oder agentenbasierte Check-Plugins explizit Python-Module nachinstalliert haben.

Um herauszufinden, ob in Ihrer Instanz Python-Module installiert sind, suchen Sie die Verzeichnisse dist-info und egg-info:

Falls das Ergebnis der Suche keine leere Liste ist, müssen Sie handeln.

Die Aktualisierung auf Python 3.13.9 aktiviert auch eine strengere Prüfung von Zertifikatsketten. Es werden nur Zertifikatsketten akzeptiert, bei denen Root und Intermediate Certificate Authorities (CAs) die Key Usage Extension enthalten (Werk #19034).

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie mit Spezialagenten oder aktiven Checks zu Endpunkten verbinden, deren Server-Zertifikate eine nicht konforme Zertifikatskette verwenden. In der Regel handelt es sich dabei um Zertifikate, die mit einer eigenen CA-Infrastruktur bereitgestellt wurden. Zertifikate kommerzieller CAs, von Let’s Encrypt oder mittels Step-CA erstellte sind nicht betroffen.

Verdächtige Zertifikate können Sie auf der Befehlszeile untersuchen (dazu ist OpenSSL 3 erforderlich):

In diesem Fall war das Zertifikat nicht zu beanstanden. Bei jedem anderen Problem wird openssl den Grund der Beanstandung nennen.

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.

Suchen Sie zunächst mit mkp list nach in der Instanz vorhandenen Erweiterungspaketen (MKPs).

Suchen Sie auch mit mkp find, um einen Überblick über nicht paketierte lokale Dateien Ihrer Checkmk-Instanz zu erhalten.

Falls die Ausgabe für einen oder beide Befehle nicht leer ist, müssen Sie handeln.

Der bisher in der Checkmk Exchange als MKP erhältliche Spezialagent für das Monitoring von Cisco Meraki ist ab 2.5.0 im Lieferumfang von Checkmk enthalten (Werk #19547).

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie das MKP cisco-meraki installiert haben.

Checkmk 2.5.0 führt für bisher ad-hoc definierte interne Programmierschnittstellen (APIs) versionierte Nachfolger ein (Werk #18600). Dies betrifft cmk.inventory_ui, cmk.password_store und cmk.server_side_programs. Da wir uns Änderungen vorbehalten, verwenden die genannten APIs als Versionsnummer v1_unstable. Wir bemühen uns, bis zur v1 keine inkompatiblen Änderungen vorzunehmen.

Zudem zieht die Ordnerstruktur der Bakery-API um, was aber nur in seltenen Fällen Probleme nach sich zieht.

Die internen, ad-hoc definierten Programmierschnittstellen bleiben weiterhin verfügbar, wir können jedoch keine Kompatibilität garantieren.

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? Sollten Probleme mit den alten, ad-hoc definierten internen APIs auftreten, empfehlen wir die Migration der betroffenen Plugins auf die neuen v1_unstable APIs. Die komplette API-Dokumentation können Sie sich in jeder Instanz unter Help > Developer resources > Plug-in API references ansehen. Den gleichen Inhalt finden Sie übrigens auch auf docs.checkmk.com/plugin-api.

Ab Checkmk 2.5.0 ist die REST-API versioniert. Checkmk 2.5.0 enthält zurzeit die REST-API-Version v1.

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

Die REST-API-Version 1.0, die bis Checkmk 2.4.0 ausgeliefert wurde, ist mit der neuen Version v1 kompatibel. Wir empfehlen dennoch, API-Pfade in Ihren Skripten in Bezug auf die neue Versionierung zu aktualisieren.

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

Was müssen Sie tun? Öffnen Sie die REST-API-Dokumentation mit Help > Developer resources > REST API. 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.

Es ist möglich, dass im Entwicklungszyklus von Checkmk 2.5.0 neue Major-Versionen der REST-API veröffentlicht werden. Durch die separate Versionierung von Checkmk selbst und der REST-API haben Sie die Möglichkeit, selbst zu entscheiden, wann Sie mit Ihren Skripten auf eine neuere Version der REST-API umsteigen. Abkündigungen von REST-API-Versionen — die mit genügend Vorlauf in Form von Werks bekanntgegeben werden — treten erst mit der jeweils nächsten Major-Version von Checkmk in Kraft.

Wie in jeder Checkmk-Version, so gibt es auch in der aktuellen Version 2.5.0 Änderungen der Software, die Rückwirkungen auf Ihre Checkmk-Installation haben können. Diese Änderungen werden in Checkmk in sogenannten Werks organisiert und dokumentiert. 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 bei 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.4.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, denn standardmäßig werden nur die Werks der Zielversion in Checkmk angezeigt (Werk #15292). Allerdings werden seit Checkmk 2.5.0 alle noch nicht bestätigten, inkompatiblen Werks der Ausgangsversion beim Update kopiert, so dass die Information über diese Werks mit dem Update nicht verloren geht (Werk #15365).

Es ist zudem eine gute Idee, wenn Sie sich bereits vor dem Update einen Überblick über die inkompatiblen Änderungen der Version 2.5.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, sodass Sie mit wenigen Klicks herausfinden können, ob Sie eine betroffene Komponente nutzen. Haben Sie sichergestellt, dass ein Werk keine Auswirkungen hat, oder haben Sie 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.5.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 hat in 2.5.0 eine grundlegende Überarbeitung erfahren. So gibt es beispielsweise für frisch erstellte Instanzen eine Willkommensseite, die Suche wurde neu gestaltet, die Aktivierung von Änderungen ist möglich, ohne die jeweils geöffnete Seite zu verlassen und mehr Assistenten sind vorhanden, zum Beispiel um schnell die ersten Hosts ins Monitoring aufzunehmen. Dennoch können Sie die generellen Abläufe, die Sie aus der Version 2.4.0 kennen, auch in der 2.5.0 mit moderator Einarbeitungszeit anwenden.

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.5.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.

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.

Bislang war der Agent Controller für Linux nur für die Plattform x86_64 verfügbar, in Checkmk 2.5.0 kommt aarch64 dazu.

Betrifft Sie das? Wenn Sie Hosts im Monitoring haben, die mit Linux auf 64-Bit ARM (aarch64) laufen, mussten Sie bislang die Agentenausgabe unverschlüsselt übertragen oder einen SSH-Tunnel graben. Da mit Checkmk 2.5.0 der Agent Controller für x86_64 und aarch64 verfügbar ist, ist die unterschiedliche Behandlung von Linux-Hosts für die beiden Plattformen nicht mehr notwendig.

Bisherige FreeBSD-Agenten verwendeten Standardpfade, die eher Linux- als FreeBSD-Konventionen entsprachen.

Betrifft Sie das? Dies betrifft Sie, wenn Sie Hosts im Monitoring haben, die FreeBSD oder ein darauf aufbauendes System (diverse Firewall- oder Storage-Lösungen) verwenden.

Checkmk 2.5.0 ändert das Speicherformat für Inventarbäume zu JSON. Die Konvertierung der Inventarbäume kann Performance-Gewinne bedeuten (Werk #18032, #18033 und #18034).

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie intensiv mit der HW-/SW-Inventur arbeiten.

Der Zustand von Hosts, die ausschließlich per IPv6 erreichbar sind, wurde bisher mit dem aktiven Check check_icmp ermittelt. Dieser aktive Check liefert Metriken beispielsweise zu Roundtrip-Zeiten und Paketverlusten. Ab Checkmk 2.5.0 steht für diese Hosts bei Verwendung des Checkmk Micro Core (CMC) auch Smart Ping zur Verfügung (Werk #18050), der allerdings keine Metriken liefert.

Betrifft Sie das? Hosts ohne explizite Konfiguration des aktiven Checks check_icmp werden automatisch umgestellt. Dadurch fallen der aktive Check und seine Metriken weg. Ist dies das gewünschte Verhalten, müssen Sie lediglich die Änderungen der Service-Liste akzeptieren.

Nur falls Sie für diese Hosts auf die Metriken des aktiven Checks nicht verzichten wollen, ist ein kleiner manueller Eingriff in die Konfiguration nötig.

Was müssen Sie tun? Passen Sie die Konfiguration der Service-Erkennung oder des aktiven Checks check_icmp an. Die Beschreibung dazu mit den zu ändernden Regeln finden Sie im Werk #18050.

Checkmk 2.5.0 ist die letzte Version, welche Regeln für das alte Plugin Microsoft SQL Server (Windows) unterstützt. Dieses wird in der nächsten Checkmk-Version entfernt werden. Migrieren Sie rechtzeitig auf das neue Plugin und die zugehörigen Bakery-Regeln Microsoft SQL Server (Linux, Windows). Mehr erfahren Sie in Werk #17669.

Die bisher vorhandene Option Prometheus Scrape Targets in der Prometheus-Regel wird entfernt werden. Wechseln Sie für das Kubernetes-Monitoring auf den Kubernetes-Spezialagenten und für generische Prometheus-Scraping-Endpunkte auf das OpenTelemetry-Monitoring. Details erklärt Werk #18709.

Der bisher vorhandene Spezialagent für das Monitoring von Azure wird mittelfristig durch Version 2 abgelöst. In Checkmk 2.5.0 können noch neue Regeln für den bisherigen angelegt werden, in der nächsten Checkmk-Version wird diese Möglichkeit wegfallen. Auch das Dashboard für das bisherige Azure-Monitoring wird weniger präsent im Menü sichtbar sein. Lesen Sie Werk #19467 und Werk #19282, um mehr zu erfahren.

Bislang gab es zwei Möglichkeiten, Zustände von BI-Aggregaten im Monitoring zu überwachen: einen aktiven Check und einen Spezialagenten. Der aktive Check wird in der nächsten Checkmk-Version nicht mehr enthalten sein (Werk #19340). Migrieren Sie rechtzeitig auf den Spezialagenten BI aggregations.

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. Mit Checkmk 2.5.0 können nun keine neuen Regeln für den alten Check mehr konfiguriert werden. Später wird er komplett entfernt werden. Auch das Migrationsskript wird dann nicht mehr mitgeliefert werden (Werk #19702). Führen Sie die Migration daher unter Checkmk 2.5.0 durch.

Nach durchgeführter Migration können Sie deutliche Performance-Vorteile erreichen, indem Sie mehrere Regeln zusammenführen, sodass eine einzige Ausführung des Checks mehrere Ausgaben erzeugen kann, was den CPU-Overhead reduziert. 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 Befehlszeile 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.

Seit 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.