So migrieren Sie zum neuen aktiven HTTP Check

Verwenden Sie als Instanzbenutzer den Befehl cmk-migrate-http --help, um eine Übersicht der verfügbaren Subkommandos zu erhalten. Diese sind:

• migrate: Migriert die Regeln der v1 in solche von v2. Dies führt entweder einen Probelauf durch oder erstellt (zunächst inaktive) Regeln zur parallelen Verwendung mit den alten. In welchem Modus das Skript läuft, bestimmen Sie durch zusätzliche Parameter: --dry-run oder --write.
• activate: Aktiviert die zuvor erstellten, bislang inaktiven Regeln für v2.
• deactivate: Deaktiviert aktive, aber noch nicht finalisierte v2 Regeln.
• delete: Löscht alle v2 Regeln, die noch nicht finalisiert wurden.
• finalize:  Löscht migrierte v1 Regeln und entfernt die bei den v2 Gegenstücken hinterlegten Referenzen auf die ursprünglichen v1 Regeln, von denen sie abgeleitet wurden. Dieser Schritt ist irreversibel.

Jedes Subkommando hat seine eigene Hilfe. Die von migrate ist hier die umfangreichste und wichtigste, da dieses Subkommando die Migration vorbereitet. Alle Aktionen lassen sich auf Ordner (optional rekursiv) oder Hosts einschränken.  Letztere Option arbeitet nicht mit Host-Namen, sondern den Host Conditions.

Beachten Sie auch, dass die Option für die Auswahl von Ordnern nicht auf den Ordnernamen in der GUI arbeitet, sondern den „gestutzten“ Ordnernamen (auf Kleinschreibung umgestellt und Leerzeichen durch Unterstriche ersetzt) die intern verwendet werden: Versuchen Sie es zunächst mit den bekannten Ordnernamen, falls diese nicht existieren, zeigt das Skript die verfügbaren internen Ordnernamen:

cmk-migrate-http migrate --dry-run --folder 'a nested folder with spaces'
Starting dry run.
Importing...
Loading plugins...
Loading rule sets...
No folder found for the given argument. Use the 'script_folder_key' for the desired folder. Available folders:
Main > ''
badssl > 'badssl'
somefolder > 'somefolder'
somefolder/a nested folder with spaces > 'somefolder/a_nested_folder_with_spaces'

Wie oben erwähnt erlaubt das Skript einen Probelauf. So können Sie das Verhalten der v1 und v2 Regeln im Monitoring parallel testen und später jederzeit finalisieren oder eben zurückrollen. Zudem können Sie jede neue Regel vor der Finalisierung anpassen. Und wenn Sie etwas kaputt konfigurieren, rollen Sie es zurück und fangen einfach von vorne an. In diesem Kapitel zeigen wir Ihnen, wie Sie eine Migration durchführen.

Führen Sie zuerst einen Probelauf durch:

cmk-migrate-http migrate --dry-run

Die Überprüfung wird Ihnen zunächst zeigen, wie viele Regeln präsent sind, welche sich davon automatisch konvertieren lassen und wie viele eine Interaktion erfordern. Im Falle inkompatibler Regeln, schlagen wir vor, diese zunächst zu überspringen. Dies geschieht durch Hinzufügen entsprechender Optionen, zum Beispiel:

cmk-migrate-http migrate --dry-run --ssl-incompatible skip

um Regeln auszulassen, die versuchen eine veraltete TLS-Version zu erzwingen. Diese werden ignoriert, sodass Sie sich später um sie kümmern können. Kombinieren Sie so viele Optionen wie möglich, um im ersten Durchlauf nur unzweideutige Regeln zu migrieren. Zum Thema Konfliktlösung erfahren Sie später mehr. Sind Sie mit dem Ergebnis zufrieden, führen Sie den Befehl mit dem Subkommando --write aus, um die migrierten Regeln zu schreiben:

cmk-migrate-http migrate --write --ssl-incompatible skip --v2-checks-certificate skip

Jetzt wurden die migrierten Regeln geschrieben, doch noch sind sie inaktiv. Sehen Sie sich die Regeln an, um zu sehen, ob sie plausibel erscheinen.

Sie haben zwei Möglichkeiten, die Regeln zu aktivieren: Mit dem activate ​​​​​​​Subkommando des Skriptes aktivieren Sie alle frisch migrierten Regeln oder Sie aktivieren Regeln nach und nach von Hand in der GUI. Beachten Sie, dass Sie in beiden Fällen noch Activate changes ausführen müssen, um sie im Monitoring zu verwenden.

Bedenken Sie, dass die Aktivierung aller Regeln auf einmal in einer hohen Zahl von Services im Zustand CRIT resultieren kann, was vor allem davon abhängt, wie aufmerksam die alten Regeln konfiguriert worden sind. Da der alte Check nicht den in Zertifikaten angegebenen Hostnamen geprüft hat, war es kein Problem, die Zertifikatsprüfung auf der IP-Adresse durchzuführen. Aus diesem Grund haben wir das Standardverhalten bei einem leeren oder nicht angegebenen Feld Address von der IP-Adresse auf den Hostnamen geändert.

Anmerkung: Falls Sie manuell eine IP-Adresse im Adressfeld angegeben haben, werden Sie die migrierte Regel später anpassen müssen. Passen Sie ruhig alles an. Zur Erinnerung: Wenn Sie etwas kaputt machen, können Sie jederzeit alle migrierten Regeln deaktivieren oder sogar komplett verwerfen und vor vorne anfangen.

Sie werden mit an Sicherheit grenzender Wahrscheinlichkeit mit Situationen konfrontiert sein, in denen wenigstens einige der konvertierten Regeln nicht zufriedenstellend funktionieren. In diesem Fall können Sie ganz oder teilweise zurückrollen. Einen partiellen Rollback führen Sie durch, indem Sie nicht zufriedenstellende v2 Regeln einfach in der GUI löschen. Einen kompletten Rollback erreichen Sie, indem Sie nacheinander zuerst das Subkommando deactivate und dann delete verwenden.

Wir haben bereits auf mögliche Probleme hingewiesen und empfohlen, Regeln, die sich nicht ohne Benutzerinteraktion migrieren lassen, zu überspringen. Jetzt ist es an der Zeit, diese Regeln zu migrieren. Für insgesamt elf häufige Konflikte haben wir die Möglichkeit geschaffen, den Konflikt automatisch aufzulösen. In vielen Fällen wird dies zu v2-Regeln führen, die wie vorgesehen funktionieren, in einigen Fällen kann eine zusätzliche Konfiguration erforderlich sein.

Probleme, deren (teilweise) Lösung über die Kommandozeile sowie mögliche erforderliche Anpassungen sind nur die wichtigsten Punkte.  Verwenden Sie immer die Ausgabe des Befehls cmk-migrate-http migrate --help als endgültige Referenz, da wir die Auswahlmöglichkeiten für bestehende Migrationsoptionen erweitern oder bei Bedarf Optionen hinzufügen werden.

Bei der Verwendung von check_http für URL-Überprüfungen mit aktiviertem HTTPS wurde die Gültigkeit des Zertifikats standardmäßig nicht geprüft. Bei der neuen v2-Überprüfung werden standardmäßig Zertifikate geprüft. Ob Sie auf das neue Verhalten umsteigen oder näher am alten Verhalten bleiben wollen, können Sie mit --v2-checks-certificates zusammen mit den Schlüsselwörtern skip, keep (v2 strengere Voreinstellung beibehalten) oder disable (Zertifikatsprüfungen komplett ignorieren) bestimmen. Um die Zertifikats- und URL-Überprüfung später zusammenführen zu können, empfehlen wir die Verwendung von keep.

Ähnliches gilt für alleinige Zertifikatsprüfungen: v2 prüft immer alle Aspekte eines Zertifikats, während v1 nur die Restgültigkeit prüft. Verwenden Sie --cant-ignore-certificate-validation, um anzugeben, ob die Migration der betroffenen Regeln übersprungen oder das neue Standardverhalten akzeptiert werden soll. Falls Sie URL-Prüfungen mit den strengeren Vorgaben migriert haben, können Sie die Überprüfung der Restlaufzeit einfach zur URL-Prüfung hinzufügen und so eine aktive Prüfung pro Host einsparen.

Ein entscheidender Aspekt der Zertifikatsbehandlung hat sich geändert: Die alte Prüfung verwendete die Hostadresse als Standard für Verbindungsversuche auch im HTTP-Request-Header, während die neue Prüfung den Hostnamen verwendet. Dieses Verhalten wird auch bei der Migration abgebildet. Zusammen mit dem strikteren Verhalten sollte dies die Probleme, die sich aus der Migration ergeben, minimieren. Allerdings: Falls Sie das $HOSTADDRESS$-Makro manuell angegeben haben, wird es nicht ersetzt, und Sie könnten mit fehlgeschlagenen Prüfungen konfrontiert werden.

Version 2 der Prüfung unterstützt nur TLS 1.2 und 1.3. Möglicherweise haben Sie Regeln konfiguriert, die ältere Versionen erzwingen, die von der neuen Prüfung nicht mehr unterstützt werden. In diesem Fall können Sie --ssl-incompatible verwenden, um die migrierte Regel auf Aushandlung der Version umzustellen.

Falls Sie wirklich Hosts mit solchen veralteten TLS/SSL-Versionen überwachen müssen, sollten Sie die Anleitung befolgen, die wir für die Version 2.3.0 von Checkmk veröffentlicht haben. Damals hat das OpenSSL-Update auf 3.x Inkompatibilitäten mit TLS 1.0 und früher verursacht.

Während das alte check_http eine freie Definition von Request- und Response-Headern erlaubte, erwartet der neue Check einen bestimmten Satz von Feld-Wert-Paaren. Regeln, die sich nicht an das „Header: value“-Schema halten, bedürfen einer Benutzerentscheidung. Verwenden Sie --add-headers-incompatible und --expect-response-header entweder mit dem Schlüsselwort skip oder ignore, um die Migration der Regel zu überspringen oder die Migration zu erzwingen, indem die Option entfernt wird. Korrigieren Sie später, wenn nötig.

Beim alten Check konnten Sie beliebige Statuscodes angeben. Nicht nur dreistellige Zahlen wie 320 (oder 737 ...), sondern auch Zeichenketten (für Details siehe Werk 17738). In einigen Fällen – wenn die angegebene Zeichenkette irgendwo in den Antwort-Headern gefunden wurde – führte dies zu keinem Fehler. Normalerweise sollten Sie solche falschen Statuscodes ignorieren. Verwenden Sie --only-status-codes-allowed mit dem ignore Schlüsselwort, um solche Regeln zu migrieren, indem der falsche Statuscode entfernt wird, und prüfen Sie danach sorgfältig.

Der alte Check folgte nicht Redirects, um andere Aspekte der Antwort wie Zeichenketten im Body des Dokumentes zu prüfen. Der neue Check folgt zuerst Redirects und prüft dann. Verwenden Sie ​​​​​​​--v1-skips-redirect-response acknowledge, um den neuen Standard zu bestätigen. Sie können die Einstellungen für die Weiterleitung später beim Testen und Bearbeiten der Regeln verfeinern.

Der neue Check unterstützt OPTIONS, TRACE, CONNECT, CONNECT_POST, PROPFIND nicht mehr. Falls Sie diese für den alten Check konfiguriert haben, können Sie --method-unavailable ​​​​​​​verwenden, um diese Methoden zu ignorieren und zu GET (wenn keine Postdaten vorhanden sind) oder POST (falls Postdaten vorhanden sind) zu wechseln.

Außerdem können Sie beim alten Check Post-Daten für Nicht-Post-Methoden konfigurieren. Wird eine solche Konfiguration gefunden, können Sie ​​​​​​​--cant-post-data post  verwenden, um die Methode in POST zu ändern, oder​​​​​​​ --cant-post-data prefermethod, um die Methode zu migrieren, aber die Post-Daten zu ignorieren.