1. Einleitung
In diesem Artikel finden Sie die wichtigsten Themen, die für das Update Ihrer Checkmk-Version 2.0.0 auf 2.1.0 relevant sind.
Wir empfehlen Ihnen, vor dem Update den kompletten Artikel durchzulesen, damit Sie genau wissen, was auf Sie zukommt: vor, während und nach dem Update.
2. Vorbereitungen
In diesem Kapitel erhalten Sie die Übersicht der Themen, um die Sie sich kümmern sollten, bevor Sie das Update durchführen. Wahrscheinlich wird nicht jedes der Themen für Sie relevant sein: Bei einem solchen können Sie intern einen Haken setzen und sich gleich das nächste Thema vornehmen.
2.1. Backup
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.
2.2. Linux-Distributionsversionen
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:
Ubuntu 20.10 Groovy Gorilla
Ubuntu 21.04 Hirsute Hippo
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:
Stoppen Sie zunächst Ihre Checkmk-Instanz:
root@linux# omd stop mysite
Hängen Sie das
tmp-Verzeichnis der Instanz aus:root@linux# umount /opt/omd/sites/mysite/tmp
Verschieben Sie das gesamte
omd-Verzeichnis, damit hieran im nächsten Schritt keine ungewollten Änderungen auftreten können. Bei einem Release-Upgrade werden im Regelfall alle Pakete entfernt, deren Abhängigkeiten nicht mehr erfüllt werden können. Zu diesen Paketen würde auch Checkmk gehören. Um hier einen Datenverlust zu verhindern, ist dieser Schritt notwendig und kann permvdurchgeführt werden.root@linux# mv /opt/omd /opt/omd.bak
Führen Sie das Versions-Upgrade von Linux entsprechend der Anleitung des jeweiligen Distributors durch.
Nach der erfolgreichen Aktualisierung Ihrer Linux-Distribution müssen Sie nun das in Sicherheit gebrachte
omd-Verzeichnis wieder an Ort und Stelle verschieben:root@linux# mv /opt/omd.bak /opt/omd
Installieren Sie nun das zur neuen Version der verwendeten Distribution passende Paket von Checkmk. Wichtig: Die Versionsnummer von Checkmk muss exakt der vorher verwendeten entsprechen. Wenn Sie also vor dem Upgrade der Distribution Checkmk 2.0.0p23 verwendet haben, so installieren Sie nun die 2.0.0p23, die zu Ihrer neuen Linux-Distributionsversion passt.
Im Falle von Ubuntu würde an dieser Stelle der folgende Befehl genügen:
root@linux# apt install /tmp/check-mk-enterprise-2.0.0p23_0.jammy_amd64.debHinweis: Geben Sie bei der Installation per
apt installden vollständigen Pfad zur DEB-Datei an.
Halten Sie sich bei der Neu-Installation von Checkmk an die jeweilige detaillierte Installationsanleitung für Ihre Distribution.
2.3. Die Agenten für Linux und Windows
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.
2.4. Lokale Dateien
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):
OMD[mysite]:~$ find -L ~/local -type fIn 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.
2.5. Die Check-API
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.
2.6. Inkompatible und obsolete MKPs
Ü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:
OMD[mysite]:~$ mkp list
my_mkp_from_exchange
my_personal_mkpZu jedem gelistetem MKP können Sie dann in der Folge auch die Dateien anzeigen lassen, die zu dem Paket gehören:
OMD[mysite]:~$ mkp list my_personal_mkp
/omd/sites/mysite/local/lib/check_mk/base/plugins/agent_based/check_mk.py
/omd/sites/mysite/local/share/check_mk/web/plugins/metrics/custom_metrics.pySollten 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.
MKP-Verwaltung ab 2.0.0p33 und 2.1.0p21
 | Verlust von Einstellungen droht! Beim Update der Major-Version löscht Checkmk Regeln, die nicht mehr benötigt werden. Falls Sie Pakete vor dem Update deinstallieren, um nach dem Update eine neue Version zu installieren, gehen möglicherweise noch benötigte Einstellungen verloren. Installieren Sie stattdessen immer neue und alte Pakete wie in diesem Abschnitt beschrieben parallel und entfernen Sie alte erst nach dem Update. |
Für die Erleichterung von Updates wurde mit Checkmk 2.0.0p33 und 2.1.0p21 die Möglichkeit eingeführt, MKPs in verschiedenen Versionen vorzuhalten. Beim Update wird dann das Paket für Checkmk 2.0.0 automatisch deaktiviert und das für Checkmk 2.1.0 automatisch aktiviert. Bei Nutzung eines verteilten Monitorings mit zentraler Konfiguration können Sie mit diesem Feature von der Zentralinstanz aus Pakete in verschiedenen Versionen an die Remote-Instanzen verteilen. Das klappt sogar, wenn die Remote-Instanzen eine höhere Version haben, wie es beim Update im verteilten Monitoring für eine Übergangszeit der Fall ist.
Beachten Sie, dass Sie dieses Feature nur nutzen können, wenn Sie als Ausgangsversion mindestens 2.0.0p33 verwenden und auf 2.1.0p21 oder höher aktualisieren! Sind diese Voraussetzungen erfüllt, können Sie auf der Zentralinstanz zusätzlich Pakete für 2.1.0 hinzufügen.
Bei der Installation eines für Checkmk 2.1.0 geschriebenen MKPs erhalten Sie unter Checkmk 2.0.0p33 und höher eine Warnmeldung:
OMD[mysite]:~$ mkp install /tmp/hello_world-0.2.1.mkp
The package requires Check_MK version 2.1.0, but you have 2.0.0p33 installed.Dieses Paket wird in der Liste der Pakete als Enabled (inactive on this site) aufgeführt:
OMD[mysite]:~$ mkp list
Name Version Title Req. Version Until Version Files State
----------- ------- ------------ ------------ ------------- ----- -------------------------------
hello_world 0.2.1 Hello world! 2.1.0 2.1.999 6 Enabled (inactive on this site)
hello_world 0.2.0 Hello world! 2.0.0 2.0.999 6 Enabled (active on this site)Details der überarbeiteten Paketverwaltung zeigt der Artikel zur Verwaltung von Erweiterungspaketen (MKPs).
2.7. Inkompatible Änderungen
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.
3. Update
3.1. Best Practices beim Update
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.
Betriebssystem aktualisieren
Das Betriebssystem auf einem Checkmk-Server sollte ohnehin immer auf dem aktuellen Stand sein.
Vor einem Update von Checkmk schadet es aber bestimmt nicht, sich dessen noch einmal zu versichern:
mithilfe von apt (für Debian und Ubuntu), yum (für Red Hat Enterprise Linux (RHEL) basierte Systeme) oder zypper (für SUSE Linux Enterprise Server).
Checkmk-Version aktualisieren
Vor dem Update auf die Version 2.1.0 muss auf der Checkmk-Instanz die Version 2.0.0 installiert sein.
Wir haben bereits früher von einem Update mit Auslassung einer Hauptversion abgeraten, da es dazwischen einfach zu viele Änderungen gibt, die ein reibungsloses Update behindern und mit großer Wahrscheinlichkeit zu Problemen führen. Mit Werk #13320 wird aus dieser Empfehlung nun eine Voraussetzung — und eine Sperre eingeführt, die zum Beispiel ein direktes Update von Version 1.6.0 auf 2.1.0 verhindert.
Ein Update auf die Version 2.1.0 setzt zurzeit keine bestimmte 2.0.0 Patch-Version voraus. Es gibt jedoch auch hier gute Gründe, den Sprung auf die 2.1.0 nur von der neuesten 2.0.0 Patch-Version aus zu starten, da z.B. ein 2.0.0 Patch Korrekturen enthalten kann, die das Update auf die Version 2.1.0 erleichtern.
Daher empfehlen wir, zuerst Checkmk auf die neueste 2.0.0 Patch-Version zu aktualisieren und erst dann das Update auf die 2.1.0 durchzuführen.
Probelauf des Updates durchführen
In großen Umgebungen, in denen auch das Zurückspielen eines selbstverständlich vorhandenen Backups Ihrer Checkmk-Umgebung mit einem gewissen zeitlichen Aufwand verbunden wäre, empfiehlt es sich, vor dem Update der produktiven Umgebung, einen Test mit einer geklonten Instanz durchzuführen. Zu diesem Zweck können Sie beispielsweise das letzte reguläre Backup Ihrer Instanz unter einem anderen Namen wiederherstellen.
root@linux# omd restore newsite /path/to/backupAlternativ können Sie Ihre Instanz auch per omd cp kopieren.
Dafür muss die Instanz allerdings kurzzeitig gestoppt werden:
root@linux# omd stop mysite
root@linux# omd cp mysite newsiteFühren Sie das Update im Anschluss erst einmal auf dieser neuen geklonten Instanz durch, um hier beispielsweise die oben angesprochenen lokalen Änderungen in der neuen Umgebung zu prüfen.
Agenten-Update vorübergehend abschalten
Wenn Sie die automatischen Agenten-Updates verwenden, sollten Sie überlegen, diese vor dem Update von Checkmk vorübergehend zu deaktivieren, um den Wechsel auf die neuen Agenten bei den Hosts später kontrolliert vollziehen zu können.
Dazu wählen Sie zuerst Setup > Agents > Windows, Linux, Solaris, AIX und auf der folgenden Seite den Menüeintrag Agents > Automatic updates.
Durch Klick auf den Knopf 
vor dem Master switch können Sie das Agenten-Update komplett abschalten:
Nach dem erfolgreichen Update von Checkmk können Sie das Agenten-Update auf gleichem Weg wieder anschalten.
Wir empfehlen an dieser Stelle das automatische Agenten-Update erstmal nur für einzelne Hosts oder Host-Gruppen wieder zu aktivieren. Auf diese Weise wird der neue Agent nicht gleich auf all Ihre Server ausgerollt und Sie können sich auf einigen wenigen Systemen mit den neu angelieferten Daten vertraut machen. Auch aufgrund der deutlich gestiegenen Zahl an mitgelieferten Check-Plugins könnten Sie eine ganze Reihe neuer Services finden, welche Sie dann auf den von Ihnen gewählten Testsystemen richtig einstellen können. Eventuell sind für neue Services auch neue Schwellwerte vonnöten. Wenn Sie dies erst einmal im Kleinen angehen, ersparen Sie schnell einige Fehlalarme.
Auf der oben angegebenen Seite können Sie dafür einfach ein paar Hosts oder Host-Gruppen in die entsprechenden Felder eintragen und dann den Master switch wieder aktivieren.
Wichtig: Denken Sie daran, diese Einschränkungen auf explizite Hosts und Host-Gruppen wieder zu entfernen, sobald Sie mit den Ergebnissen zufrieden sind.
Benachrichtigungen vorübergehend abschalten
Sie sollten auch überlegen, Benachrichtigungen in der Instanz vor dem Update abzuschalten — aus ähnlichen Gründen, die wir im vorherigen Abschnitt zu den automatischen Agenten-Updates erklärt haben. So vermeiden Sie, dass Ihre Kollegen aus dem Monitoring-Team unnötige Benachrichtigungen erhalten.
Die Benachrichtigungen können Sie zentral im Snapin Master control mit dem Hauptschalter Notifications abschalten.
Es kann durchaus vorkommen, dass nach dem Update der eine oder andere Service CRIT ist, der dies vorher nicht gewesen ist. Kümmern Sie sich nach dem Update zuerst um neu auftretende Probleme. Die unbehandelten Probleme (unhandled problems) können Sie sich z.B. im Snapin Overview anzeigen lassen.
Wichtig: Vergessen Sie nicht, die Benachrichtigungen wieder einzuschalten, z.B. dann, wenn sich die Zahl der unbehandelten Probleme nach dem Update auf das Niveau vor dem Update eingepegelt hat.
3.2. Update im verteilten Monitoring
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:
Alle Instanzen stoppen.
Das Update für alle Instanzen durchführen.
Die aktualisierten Instanzen wieder starten.
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.
Kompatibilitätstabelle
Mit Werk #13313 wurden Versionsprüfungen hinzugefügt, die sicherstellen, dass die beteiligten Instanzen kompatible Versionen verwenden. Die Kurzfassung ist: Instanzen müssen die gleiche Hauptversion haben — mit einer Ausnahme: die Checkmk-Version einer Remote-Instanz darf um genau eine Hauptversion höher sein als die der Zentralinstanz. Die folgende Tabelle zeigt die möglichen Kombinationen beim Update von 2.0.0 zur 2.1.0:
| Zentralinstanz | Remote-Instanz | Erlaubt? |
|---|---|---|
2.0.0 | 2.0.0 | Ja |
2.0.0 | 2.1.0 | Ja |
2.1.0 | 2.0.0 | Nein |
2.1.0 | 2.1.0 | Ja |
Für Patch-Versionen gilt prinzipiell das gesagte: Die Zentral-Instanz darf nie einen höheren Versionsstand als die Remote-Instanzen nutzen. Allerdings sind häufig größere Abweichungen als eine Patch-Version erlaubt. Details zur konkreten Kompatibilität entnehmen Sie den Werks.
Aus diesen Regeln folgt, dass bei einem Update im laufenden Betrieb die Zentralinstanz zuletzt aktualisiert wird. Beachten Sie, dass auch beim Update im verteilten Monitoring gilt: Hauptversionen dürfen nicht ausgelassen werden, sodass z.B. eine Verbindung zwischen einer 1.6.0 und einer 2.1.0 Instanz nicht unterstützt wird.
Hinweis: Da sich der Funktionsumfang verschiedener Checkmk-Versionen unterscheidet, kann es sein, dass einige Features von Checkmk in diesem Mischbetrieb nicht oder nur eingeschränkt funktionieren. In einem Mischbetrieb können auch bei kompatiblen Versionen Probleme auftreten und ein reibungsloses Zusammenspiel ist nur dann gesichert, wenn alle Instanzen die gleiche Hauptversion haben. Sie sollten daher den Zeitraum eines Mischbetriebs mit verschiedenen Versionen möglichst kurz halten und nach dem Start des Updates alle Instanzen zügig aktualisieren.
MKPs im verteilten Setup
Falls Sie verteiltes Monitoring mit einer zentralen Konfiguration betreiben, aus der auch Checkmk-Erweiterungspakete (MKPs) an die Remote-Instanzen verteilt werden, haben Sie die Möglichkeit, in der Checkmk 2.0.0 Zentralinstanz Pakete für die Remote-Instanzen in Versionen für 2.0.0 und 2.1.0 vorzuhalten. Es werden dann automatisch die zur Remote-Instanz passenden MKPs verteilt.
Um dieses Feature nutzen zu können, muss zunächst die Zentralinstanz auf Patch-Version 2.0.0p33 gebracht werden. Ist dies geschehen, können Sie beginnen, auf der Zentralinstanz zusätzlich Pakete für 2.1.0 hinzuzufügen. Wenn Sie nun Remote-Instanzen auf 2.1.0p21 aktualisieren, erhalten und aktivieren diese dann automatisch das zur neuen Version passende Paket.
3.3. Das Update durchführen
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.
4. Nachbereitungen
4.1. Änderungen der Benutzeroberfläche
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.
Entfernte Snapins für die Seitenleiste
Mit Werk #13736 wurden einige veraltete und wenig genutzte Snapins für die Seitenleiste entfernt. Für fast alle dieser Snapins gibt es Ersatz, meist über Menüeinträge der Navigationsleiste.
4.2. Automigration auf die Check-API überprüfen
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:
OMD[mysite]:~$ cmk -R
Failed to auto-migrate legacy plugin to check plugin: mssql_counters
Please refer to Werk 10601 for more information.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.
4.3. Services aktualisieren
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.
Check_MK und Check_MK Agent
Die Services Check_MK und Check_MK Agent heißen zwar noch genauso wie in der Version 2.0.0, haben aber in der 2.1.0 teilweise eine andere Bedeutung:
Der Service Check_MK Agent ist nun immer präsent und liefert alle Informationen, die mit der Agentenverteilung (agent deployment) zu tun haben, wie die Version des Agenten, der Zeitpunkt des letzten Updates, die Zahl von Agentenplugins und lokalen Checks, oder die Beschränkung der IP-Adressen. Bisher kümmerte sich dieser Service nur um die Agenten-Updates — und war auch nur dann verfügbar, wenn Agenten-Updates eingerichtet waren.
Auch der Service Check_MK ist nun immer da — vorher war er es nur dann, wenn auf dem Host passive Services liefen. Der Service Check_MK kümmert sich nun ausschließlich um den Zustand der verwendeten Agenten im laufenden Betrieb (operational state). Er meldet z.B. Verbindungsfehler oder fehlende Daten und zeigt die Ausführungszeit.
Cluster-Services
Mit Checkmk Version 2.1.0 verändert sich das Verhalten einiger Cluster-Services. Betroffene Services nehmen den Zustand UNKNOWN an und erfordern eine Anpassung der Konfiguration.
Checkmk kennt vier Cluster-Modi:
Best (der Wert der besten Node bestimmt den Gesamtzustand)
Worst (analog: Wert der schlechtesten Node)
Failover (nur eine Node darf OK liefern)
Natives Clustering per API-Funktion (frei programmierbar, z.B.: 80 % der Nodes müssen OK sein, damit der Cluster OK ist)
Legacy-Plugins, welche die alte Check-API nutzen, verfügten bislang über eine zusätzliche implizite Cluster-Möglichkeit, bei der die Ausgabe der zugeordneten Hosts lediglich der Reihe nach ausgewertet wurde und der letzte erhaltene Einzelzustand den Gesamtzustand des Clusters bestimmte. Da dieses Verhalten nicht verlässlich war, wurde es in 2.1.0 entfernt.
Im Zuge der Portierung auf 2.1.0 haben wir bei einigen mitgelieferten Check-Plugins das zur 2.0.0 nachgerüstete native Clustering wieder entfernt, wenn es nicht sinnvoll war. Stattdessen haben wir als Standard eines der Verhalten best, worst oder failover ausgewählt. Diese Liste zeigt betroffene Plugins und das neue Standardverhalten. Ebenfalls betroffen sind selbst programmierte oder aus der Checkmk Exchange bezogene Plugins, die keine API-Integration für den nativen Cluster-Modus verwenden.
All diese Dienste nehmen nach dem Update auf 2.1.0 den Zustand UNKNOWN an, wenn der einst ausgewählte Cluster-Modus nicht mehr unterstützt wird. Verwenden Sie in diesen Fällen die Regel Aggregation options for clustered services, um einen der drei Cluster-Modi best, worst oder failover zu definieren.
Service-Beschreibungen
Jedes Update von Checkmk bedeutet, dass Service-Beschreibungen geändert werden, um die Konsistenz der Benennung innerhalb des Monitorings und der Dokumentation von Checkmk zu verbessern. Da die Änderung von Service-Beschreibungen bedeutet, dass mitunter Regeln angepasst werden müssen und historische Monitoring-Daten verloren gehen, belässt Checkmk bei Updates zunächst die alten Beschreibungen. Sie sollten bei Services, bei denen Verlust alter Monitoring-Daten zu verschmerzen und der Aufwand für die Anpassung von Regeln überschaubar ist, zeitnah auf neue Service-Beschreibungen umstellen.
Gehen Sie hierfür in Setup > General > Global Settings > Execution of checks die Liste Use new service descriptions durch und identifizieren Sie die Services, bei denen die Checkboxen noch nicht aktiv sind und aktivieren Sie diese. Nach Anwenden der Änderungen sind die neuen Service-Beschreibungen aktiv und es werden wenige Minuten vergehen, bis Sie wieder definierte Zustände der betroffenen Services im Monitoring sehen.
4.4. Neue Ports
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.
4.5. Agenten für TLS registrieren
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.
4.6. Das neue Kubernetes-Monitoring
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.
4.7. Benachrichtigungs-Spooler verschlüsseln
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.
4.8. REST-API ersetzt Web-API
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.
4.9. Obsolete MKPs entfernen
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).
OMD[mysite]:~$ mkp list
Name Version Title Req. Version Until Version Files State
----------- ------- ------------ ------------ ------------- ----- -----------------------------
hello_world 0.2.1 Hello world! 2.1.0 2.1.999 6 Enabled (active on this site)
hello_world 0.2.0 Hello world! 2.0.0 2.0.999 6 DisabledWenn 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:
OMD[mysite]:~$ mkp list | grep DisabledDeinstallieren Sie diese dann mit mkp remove.
OMD[mysite]:~$ mkp remove hello_world 0.2.05. Ausblick
In diesem Kapitel geht es um Themen, die nicht die aktuelle Checkmk Version 2.1.0, sondern eine der darauf folgenden Versionen betreffen.
5.1. Die Web-API wird entfernt
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.
5.2. Der alte Kubernetes Spezialagent wird entfernt
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.
5.3. NSCA wird nicht mehr unterstützt
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.
5.4. Die alte HW/SW-Inventur Plugin-API wird nicht mehr unterstützt
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.