Update auf Version 2.1.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.

In der Checkmk Version 2.1.0 werden einige veraltete Versionen der Distribution Ubuntu nicht mehr unterstützt. Für Nutzer von Debian, SLES und RHEL (sowie binärkompatiblen Derivaten wie CentOS) ergeben sich keine Änderungen.

Betrifft Sie das? Das betrifft Sie, wenn auf Ihrem Checkmk-Server eine der folgenden, in der 2.0.0 noch unterstützten, Ubuntu-Versionen installiert ist:

Bei Veröffentlichung von 2.1.0 noch unterstützt, aber nicht empfohlen: Für Ubuntu 21.10 (Impish Indri) wurde während der Beta-Phase von 2.1.0 seitens Canonical die Unterstützung mit Sicherheits-Updates eingestellt. Auch Debian 9 (Stretch) wird kurz nach Veröffentlichung von Checkmk 2.1.0 keine Sicherheits-Updates mehr erhalten.

Neu hinzugekommen sind Debian 11 Bullseye und Ubuntu 22.04 Yammy. Für beide Distributionen bauen wir auch Installationspakete von 2.0.0, um den empfohlenen Update-Pfad zu vereinfachen.

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 Ziel-Version der Linux-Distribution von Checkmk 2.0.0 und 2.1.0 unterstützt wird.

Welche Linux-Distributionsversionen Checkmk unterstützt, erfahren Sie in der Update-Matrix für 2.1.0 und auf der Download-Seite nachdem Sie die Checkmk-Version und Ihre Linux-Distribution ausgewählt haben.

Sollte es nun notwendig sein, vor dem Update von Checkmk, ein Versions-Upgrade Ihrer Linux-Distribution vorzunehmen, so empfehlen wir die folgende Vorgehensweise:

Halten Sie sich bei der Neu-Installation von Checkmk an die jeweilige detaillierte Installationsanleitung für Ihre Distribution.

Mit 2.1.0 führt Checkmk zunächst für die Linux- und Windows-Agenten auf x86/64 die beiden Komponenten Agent Controller (auf dem Host) und Agent Receiver (auf dem Server) ein, mit denen eine TLS verschlüsselte Übertragung des Agenten-Outputs möglich ist. Der Agent Controller arbeitet zunächst in einem Kompatibilitätsmodus (Legacy-Pull-Modus), der auch den Zugriff von 2.0.0-Instanzen zulässt.

Betrifft Sie das? Ja.

Was müssen Sie tun? Identifizieren Sie diejenigen Windows-Hosts im Monitoring, welche die Windows Serverbetriebssysteme 2008 R2 und Client Betriebssysteme 7 oder höher auf x86_64 nutzen. Gleiches gilt für Linux-Hosts auf x86_64, welche zur Dienstverwaltung systemd ab Version 220 verwenden. Auf diesen Hosts registrieren Sie nach der Aktualisierung beim Monitoring-Server, um die TLS verschlüsselte Übertragung zu nutzen. Detailliertere Informationen finden sie in der ausführlichen Anleitung für Linux oder Windows.

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. Lokale Dateien können bei einem Update Probleme bereiten, da sie eventuell nicht mehr zur neuen Checkmk-Version passen.

Betrifft Sie das? Da es für Checkmk bei einem Update nicht möglich ist, die lokalen Anpassungen und jede von einem Drittanbieter hergestellte Erweiterung abzufangen und zu behandeln, sollten Sie Ihre Checkmk-Instanz vor einem Update daraufhin überprüfen, ob lokale Dateien bei Ihnen verwendet werden und gegebenenfalls welche.

Was müssen Sie tun? Verschaffen Sie sich einen Überblick über die lokalen Dateien Ihrer Checkmk-Instanz, indem Sie als Instanzbenutzer das folgende Kommando ausführen (bei dem die Option -L dafür sorgt, dass auch symbolischen Links gefolgt wird):

In einer frischen Installation von Checkmk wird Ihnen derzeit nur eine Datei namens README.TXT aufgelistet. Alles, was darüber hinaus angezeigt wird, sollte ganz oben auf Ihrer Liste zur Fehlerdiagnose stehen, falls es beim Update Probleme gibt. Besondere Aufmerksamkeit verdienen Check-Plugins, die immer noch der alten, bis zur Version 1.6.0 gültigen, Check-API folgen. Wir gehen darauf im nächsten Kapitel genauer ein.

In Checkmk 2.0.0 wurde eine neue Check-API eingeführt, die die Check-Plugins neu strukturiert, um ihre Handhabung zu vereinheitlichen und zu vereinfachen. Da es aber eine große Zahl von Checks gibt, die nach der alten, bis zur Version 1.6.0 gültige Check-API programmiert wurden, kann es sein, dass die Migration von der alten auf die neue Check-API auch in der Version 2.1.0 ein Thema für Sie ist. Die große Zahl existierender Checks ist auch der Grund, warum die alte Check-API für eine Übergangszeit weiterhin unterstützt wird.

Betrifft Sie das? Das Thema Check-API kann Sie betreffen, wenn Sie die mit Checkmk ausgelieferten um Ihre eigenen, selbst geschriebenen Checks erweitert haben und/oder wenn Sie Plugins aus anderen Quellen nutzen und diese z.B. von der Checkmk Exchange heruntergeladen haben. Das Thema betrifft Sie, wenn eines, einige oder gar alle dieser Check-Plugins noch der alten Check-API folgen. Die betroffenen Dateien finden Sie in den lokalen Dateien Ihrer Instanz.

Was müssen Sie tun? Wir versuchen Ihnen den Umstieg auf die neue Check-API so leicht und komfortabel wie möglich zu machen:

So wie beim Update auf die Version 2.0.0 versucht Checkmk auch beim Update auf die Version 2.1.0 alle lokalen Plugins aus den Verzeichnissen ~/local/share/check_mk/checks und ~/local/share/check_mk/inventory automatisch auf die neue Check-API zu migrieren. Diese „Automigration“ passiert zur Laufzeit; die Plugin-Dateien werden nicht verändert. Wie Sie sich nach dem Update die Ergebnisse anzeigen lassen können, erfahren Sie im Kapitel Automigration auf die Check-API überprüfen.

Die Chancen stehen zwar gut, dass die Automigration Ihrer Check-Plugins reibungslos funktioniert, dennoch erfordert die ebenfalls in der Version 2.0.0 durchgeführte Umstellung auf Python 3 möglicherweise einige Anpassungen. Durch die neue Check-API und die Code-Basis Python 3 gibt es gleich zwei gute Gründe, Ihre selbst geschriebenen Check-Plugins zu überarbeiten. Wir informieren Sie ausführlich über die notwendigen Schritte im Blogpost zur Migration von Check-Plugins.

Zu guter Letzt punktet die neue Check-API mit verbesserter Dokumentation: Es gibt einen einführenden Artikel zur Programmierung eigener Check-Plugins und die stets aktuelle Plugin-API-Referenzdokumentation. Beides können Sie über die Checkmk-Oberfläche aufrufen — im Help-Menü der Navigationsleiste unter Developer resources.

Über die Checkmk-Erweiterungspakete (MKPs) lässt sich Ihr Monitoring-System recht einfach und bequem erweitern. Auf der einen Seite kommt es dabei vor, dass solche MKPs nicht weiter gepflegt werden und dann ggf. mit neuen Versionen von Checkmk nicht mehr kompatibel sind. Auf der anderen Seite nehmen wir immer wieder neue Plugins und Funktionserweiterungen in Checkmk auf, weshalb MKPs mitunter obsolet werden. Ihre Funktionalität wird schlicht von Checkmk selbst sichergestellt.

Betrifft Sie das? Falls Sie MKPs installiert haben, ist aus diesem Grund eine Prüfung dieser MKPs dringend geboten — besonders vor einem umfangreichen Update. So verhindern Sie, dass inkompatible Pakete das Update behindern oder im Anschluss an das Update doppelte oder zumindest sehr ähnliche Services entstehen.

Was müssen Sie tun? Prüfen Sie hierzu Ihre installierten MKPs gegen unseren Katalog der Check-Plugins und entfernen Sie Pakete, welche inzwischen nativ von Checkmk bereitgestellt werden. Bei dieser Gelegenheit können Sie auch MKPs entfernen, die eventuell nur mal für einen Probelauf installiert worden sind. Eine Auflistung finden Sie über Setup > Maintenance > Extension packages. Auf der Kommandozeile können Sie sich installierte Erweiterungen mit dem folgenden Befehl anzeigen lassen:

Zu jedem gelistetem MKP können Sie dann in der Folge auch die Dateien anzeigen lassen, die zu dem Paket gehören:

Sollten Sie über die Prüfung der installierten MKPs und dem Abgleich mit unserem Katalog nicht alle Pakete zuordnen können, empfiehlt sich der hiernach beschriebene Probelauf des Updates, um dabei Inkompatibilitäten zu identifizieren und dann in Ihrem produktiven Monitoring vor dem Update zu entfernen.

Wie in jeder Checkmk Version, so gibt es auch in der aktuellen Version 2.1.0 Änderungen der Software, 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? 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. Also werden Sie auf jeden Fall mit diesem Thema konfrontiert werden — allerdings erst, nachdem Sie das Update durchgeführt haben.

Es ist daher eine gute Idee, sich bereits vor dem Update einen Überblick über die inkompatiblen Änderungen zu verschaffen: Öffnen Sie die Liste der Werks. (Die Software-Entwicklung von Checkmk ist in sogenannten Werks organisiert.) In der Beschreibung eines Werks finden Sie Hinweise, was gegebenenfalls zu tun ist, um die Änderung kompatibel zu machen.

Die frustrierende Nachricht: Die Werkliste einer Version ist sehr, sehr lang — selbst wenn sie nur die inkompatiblen Änderungen enthält. Die tröstliche Nachricht: An der Anzahl der Änderungen können Sie sehen, wie groß unsere Anstrengungen sind, Checkmk für Sie zu verbessern.

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 unterschiedliche Vorgehensweisen, um das Update der in einem verteilten Monitoring beteiligten Instanzen durchzuführen, d.h. der Zentralinstanz und der Remote-Instanzen.

Wichtig: Für welches Vorgehen Sie sich auch entscheiden: Sie sollten auch in diesem Szenario vorher Backups anlegen.

Das empfohlene, sichere Vorgehen ist das Update in einem Rutsch, bei dem Sie folgende Schritte ausführen:

Es gibt noch eine andere Variante: das Update im laufenden Betrieb. Dieses Vorgehen wird unter anderem dann benötigt, wenn man eine große Menge von verteilten Instanzen verwaltet, die aus technischen oder organisatorischen Gründen nicht in einem Rutsch aktualisiert werden können.

Bei einem Update im laufenden Betrieb müssen Instanzen mit unterschiedlichen Checkmk-Versionen für eine Übergangszeit miteinander kommunizieren — solange, bis das Update aller beteiligten Instanzen abgeschlossen ist. Damit diese Zusammenarbeit klappt, müssen die in diesem Mischbetrieb beteiligten Versionen kompatibel sein.

Am eigentlichen Update der Software hat sich in der Checkmk 2.1.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 wurde mit Version 2.0.0 komplett neu gestaltet. In der neuen Version 2.1.0 wird sie Ihnen dagegen sehr vertraut vorkommen, denn es hat kaum Änderungen im Vergleich zur 2.0.0 gegeben, die auf den ersten Blick sichtbar sind. Allerdings haben sich Menüs, Menüeinträge 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 Checkmk aufsetzen finden Sie eine ausführliche Einführung in die wichtigsten Elemente der Benutzeroberfläche.

Sie können überprüfen, ob alle lokalen Plugins aus den Verzeichnissen ~/local/share/check_mk/checks und ~/local/share/check_mk/inventory automatisch auf die neue Check-API migriert werden können.

Betrifft Sie das? Diese Überprüfung ist sinnvoll, wenn in Ihren lokalen Dateien Check-Plugins existieren, die nach der alten, bis zur Version 1.6.0 gültigen Check-API programmiert wurden.

Was müssen Sie tun? Führen Sie als Instanzbenutzer das folgende Kommando aus:

Die Meldung oben zeigt, dass ein Plugin nicht automatisch migriert werden konnte. Alle gelisteten Plugins müssen von Ihnen manuell migriert werden. Es gibt einige Gründe, aus denen eine Automigration nicht durchgeführt werden kann und die Sie im genannten Werk #10601 nachlesen können. Wie Sie die manuelle Migration durchführen, erfahren Sie im Blogpost zur Migration von Check-Plugins.

Wie jede Hauptversion, so bringt auch Checkmk 2.1.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 > Discover services.

Im Folgenden listen wir einige Bereiche mit den meisten Neuerungen auf.

Um die TLS-Registrierung eines Hosts im Monitoring durchzuführen, benötigt dieser Host Zugriff auf Ports des Checkmk-Servers: Port 443 (respektive 80) für REST-API-Anfragen und Port 8000 für den neuen Agent Receiver. Achten Sie gegebenenfalls darauf, Routing- und Firewall-Einstellungen dahingehend anzupassen, dass die betreffenden Hosts auf diese Ports des Checkmk-Servers zugreifen können.

Sollten Sicherheitsrichtlinien dagegen sprechen, diese Ports verfügbar zu machen, können Sie eine Registrierung im Auftrag direkt auf dem Checkmk-Server durchführen.

Nach der Aktualisierung der Agenten auf 2.1.0 nimmt der Dienst Check_MK Agent für die betreffenden Hosts den Status WARN an und zeigt die Meldung TLS is not activated on monitored Host. In den beiden Artikeln zum Linux- und Windows-Agenten beschreiben wir die Registrierung der verwendeten Zertifikate mit dem Kommandozeilenwerkzeug cmk-agent-ctl. Dieses Werkzeug stellt auch viele Optionen zur automatischen Registrierung bereit — beispielsweise per Postinstall-Snippet in Bakery Plugins.

Falls für einen Übergangszeitraum unverschlüsselte Datenübertragung für den Parallelbetrieb von 2.0.0-Servern in einer 2.1.0-Umgebung erwünscht ist, passen Sie den Regelsatz Checkmk Agent installation auditing an, damit der Service Check_MK Agent trotz fehlender Registrierung den Status OK annehmen kann.

Das Kubernetes-Monitoring wurde in Checkmk 2.1.0 von Grund auf neu geschrieben und ermöglicht nun eine vereinfachte und effiziente Überwachung. Da sich die Architektur in Version 2.1.0 grundlegend geändert hat, ist eine Übernahme oder Weiterschreibung bisheriger Monitoring-Daten Ihrer Kubernetes-Objekte aus früheren Checkmk-Versionen leider nicht möglich.

Betrifft Sie das? Das betrifft Sie, wenn Sie in der Version 2.0.0 den Checkmk-Spezialagenten zur Überwachung von Kubernetes verwendet haben. Der alte Spezialagent und die zugehörigen Check-Plugins werden zwar in der Version 2.1.0 noch funktionieren, aber anschließend aus Checkmk entfernt werden. Wir empfehlen daher den kompletten Umstieg auf das neue, stark verbesserte Kubernetes-Monitoring der Version 2.1.0.

Was müssen Sie tun? Setzen Sie das Kubernetes-Monitoring komplett neu auf, wie es im Artikel zur Überwachung von Kubernetes beschrieben ist.

Betrifft Sie das? Wenn Sie verteiltes Monitoring mit zentraler Benachrichtigung verwenden, profitieren Sie von erhöhter Sicherheit bei Aktivierung der Transportverschlüsselung des Notification Spooler mknotifyd.

Was müssen Sie tun? Bei der Aktualisierung vorhandener Checkmk-Installationen bleiben bereits konfigurierte Verbindungen zunächst ohne Verschlüsselung weiter nutzbar. Allerdings wird in diesem Fall Analyze configuration die Einstellung mit CRIT bemängeln. Ändern Sie nach Migration aller beteiligten Instanzen auf 2.1.0 die Option Global settings > Notification spooler configuration > Encryption auf die Einstellung Encrypt communication with TLS. Neue Verbindungen verwenden bei der Erstellung automatisch die TLS-Verschlüsselung.

Die Web-API (auch HTTP-API genannt) ist abgekündigt und wird in der nächsten Checkmk-Version entfernt werden. Ersatz steht bereit mit der in Version 2.0.0 eingeführten REST-API.

Betrifft Sie das? Das betrifft Sie, falls Sie eigene Skripte geschrieben haben, die die Web-API nutzen.

Die Web-API wird in der Checkmk-Version weiterhin funktionieren und in bestehenden Instanzen, die von der Version 2.0.0 auf 2.1.0 aktualisiert werden, bleibt die Web-API eingeschaltet. In Instanzen, die mit der Version 2.1.0 neu erstellt werden, ist die Web-API bereits in den Global settings abgeschaltet. Den Schalter zum Ein- und Ausschalten der Web-API finden Sie unter Setup > General > Global settings > Site management > Disable Web API.

Was müssen Sie tun? Wir empfehlen, alle bestehenden Skripte, die die Web-API verwenden, so bald wie möglich auf die REST-API zu migrieren, um Probleme frühzeitig zu erkennen, bevor Sie auf die Checkmk-Version 2.2.0 umsteigen.

Die REST-API bietet bereits jetzt Zugriff zu mehr Bereichen in Checkmk als die Web-API, z.B. zu Host-Status, Service-Status, Wartungszeiten, Zeitperioden, Quittierung von Problemen und der Business Intelligence (BI).

Die in der REST-API noch fehlenden Funktionen zum Zugriff auf Instanzen im verteilten Monitoring und auf Metriken und Graphen werden in 2.1.0 Patch-Versionen nachgeliefert, sodass im Laufe der Zeit alle Funktionen zur Verfügung stehen, die auch in der Web-API genutzt werden konnten.

Betrifft Sie das? Dies betrifft Sie, wenn Sie von der Funktion Gebrauch gemacht haben, MKPs in verschiedenen Versionen vorzuhalten.

Was müssen Sie tun? Während des Updates werden inkompatible Pakete automatisch auf den Zustand Disabled gesetzt, aber nicht vollständig gelöscht. Zur neuen Checkmk-Version kompatible Pakete werden automatisch aktiviert, Sie erhalten den Zustand Enabled (active on this site).

Wenn die Funktionalität der neuen Pakete sichergestellt ist und die alten nicht mehr als Referenz benötigt werden, können Sie nach veralteten Paketen suchen:

Deinstallieren Sie diese dann mit mkp remove.

Die Web-API (auch HTTP-API genannt) wird in der nächsten Checkmk-Version 2.2.0 entfernt. Die Web-API wird ersetzt durch die in der 2.0.0 eingeführte REST-API.

Der Checkmk 2.0.0 Spezialagent für das Kubernetes-Monitoring und die zugehörigen Check-Plugins werden in der nächsten Checkmk-Version 2.2.0 entfernt. Details finden Sie im Werk #13561. Ersatz gibt es in Version 2.1.0 mit dem komplett neuen Kubernetes-Monitoring.

Die Unterstützung für den Nagios Service Check Acceptor (NSCA) wird in der nächsten Checkmk-Version 2.2.0 entfernt.

NSCA ist ein Nagios Add-on, um Ergebnisse passiver Checks von fernen Hosts in einer verteilten Nagios-Konfiguration zu erhalten. Dieses veraltete Verfahren zum Aufbau eines verteilten Monitoring bietet gegenüber den Checkmk-eigenen Verfahren keine Vorteile.

Details und Hinweise zum Ersatz finden Sie im Werk #13644.

Die Unterstützung der alten Plugin-API für die HW/SW-Inventur wird in der nächsten Checkmk-Version 2.2.0 entfernt.

Die dieser API folgenden Plugins befinden sich im Instanzverzeichnis unter ~/share/check_mk/inventory und (als lokale Dateien) unter ~/local/share/check_mk/inventory. Diese Plugins funktionieren in der Version 2.1.0, werden aber ab der Version 2.2.0 ignoriert werden.

Falls Sie benutzerdefinierte Plugins nutzen, migrieren Sie diese auf die neue Check-API bevor Sie auf die Version 2.2.0 wechseln. Im Werk #14084 finden Sie weitere Details und Informationen zur Migration.