Instanzen (Sites) mit omd verwalten

In manchen Fällen möchte man die Benutzer-/Gruppen-ID des neu anzulegenden Benutzers festlegen. Dies geschieht mit den Optionen -u und -g, z.B.:

Eine Übersicht über weitere Optionen erhalten Sie mit omd create --help. Die wichtigsten Optionen sind:

Standardmäßig wird das Home-Verzeichnis einer neuen Instanz unter /omd/sites/ angelegt und mit Standarddateien gefüllt. Sie können jedoch auch ein leeres Home-Verzeichnis erstellen lassen, um etwa ein externes Medium an dieser Stelle zu mounten. Das erledigt die Option --no-init:

Mit dieser Option wird auch die Integration in den System-Apache ausgesetzt, sprich /omd/apache/mysite.conf bleibt leer. Anschließend könnten Sie ein beliebiges Verzeichnis mounten und die Einrichtung fortsetzen:

omd init holt dann die beiden ausgelassenen Schritte nach, fügt also die Standarddateien ein und erstellt die Apache-Konfiguration.

Den interaktiven Modus rufen Sie als Instanzbenutzer einfach so auf:

Sobald Sie bei laufender Instanz eine Einstellung ändern, wird Sie OMD darauf hinweisen, dass zuvor Ihre Instanz angehalten werden muss und diese bei Bedarf auch stoppen:

Vergessen Sie nicht, nach getaner Arbeit die Instanz wieder zu starten. omd config wird das nicht automatisch für Sie tun.

Wer den interaktiven Modus nicht liebt oder mit Skripten arbeiten will, kann die einzelnen Einstellungen als Variablen auch per Kommandozeile setzen. Dafür gibt es den Befehl omd config set. Folgendes Beispiel setzt die Variable AUTOSTART auf off:

Sie können omd config set auch als root aufrufen, wenn Sie den Namen der Instanz als Argument mit angeben:

Die aktuelle Belegung aller Variablen zeigt als root das Kommando omd config mysite show und als Instanzbenutzer omd config show:

Die obige Kommandoausgabe zeigt nur die ersten Einträge.

In omd config gibt es zahlreiche Einstellungen. Die Wichtigsten sind:

Hinweis: Diese Variablen sehen Sie unter gleichem Namen auch im interaktiven Modus.

Manchmal ist es nützlich, eine Kopie einer Instanz zu erzeugen — sei es zu Testzwecken oder für die Vorbereitung eines Updates. Natürlich könnte man jetzt einfach das Verzeichnis /omd/sites/mysite_old nach /omd/sites/mysite_new kopieren. Das würde aber nicht so funktionieren wie gewünscht, denn:

Um das Kopieren einer Instanz zu vereinfachen, gibt es stattdessen den Befehl omd cp, welcher all das berücksichtigt. Führen Sie den Befehl als root aus und geben Sie als Argumente einfach den Namen der bestehenden Instanz und dann den Namen der neuen an, z.B.:

Das Kopieren geht nur, wenn

Beides stellt sicher, dass die Instanz zum Zeitpunkt des Kopierens in einem konsistenten Zustand ist und sich auch während des Vorgangs nicht ändert.

OMD konnte ursprünglich lediglich mit den Dateien umgehen, die beim Erstellen der Instanz mit omd create auch tatsächlich angelegt wurden, und die zudem die Instanz-ID ($OMD_SITE) enthalten. Diese Dateien sind im Instanzverzeichnis ~/etc zu finden mit diesem Befehl:

Mit Konfigurationsdateien, die erst später über die Arbeit mit der Checkmk-Instanz entstanden, konnte OMD nichts anfangen (also zum Beispiel den Konfigurationen hinzugefügter Hosts). Rein technisch betrachtet entspricht dieses Verhalten genau dem Geltungsbereich von OMD. Die Erwartungshaltung der meisten Benutzer ist aber die, dass ein omd cp eine komplett neue Instanz erschafft, die produktiv weitergenutzt werden kann — inklusive der eigenen Monitoring-Konfiguration.

Seit der Checkmk-Version 2.1.0 kann OMD nunmehr auch die wichtigsten Teile der Checkmk-Konfiguration anpassen. Sie selbst müssen dafür übrigens im Grunde nichts tun, die gesamte folgend beschriebene Migration findet ganz automatisch statt.

Ein typisches Beispiel dazu: In den Eigenschaften eines Hosts können Sie über das Attribut Monitored on site manuell festlegen, über welche Instanz dieser Host überwacht werden soll, etwa mysite_old. Nach einem omd cp mysite_old mysite_new ändert sich der Wert entsprechend auf mysite_new. (Früher hätte dieses Prozedere zu dem Eintrag Unknown site (mysite_old) geführt.)

Die technische Umsetzung dieser Migration sieht wie folgt aus: OMD erkennt Änderungen an der Instanz-ID und führt dann den Befehl post-rename-site -v -o mysite_new aus. Die einzelnen Migrationsschritte werden in der Folge ganz automatisch über die so genannten rename actions plugins abgearbeitet, die Sie unter unter cmk/post_rename_site/plugins/actions im Git-Repository finden.

Zur Migration gehört auch, dass Sie über Dinge informiert werden, die nicht automatisch migriert werden (können).

Hier ein konkretes Beispiel: Sie nutzen ein verteiltes Monitoring und benennen sowohl die Zentralinstanz als auch eine Remote-Instanz um.

Zentralinstanz: Das Plugin sites.py erkennt, dass es sich um eine Zentralinstanz handelt und aktualisiert unter anderem den Wert URL prefix, der sich in den Verbindungseinstellungen der lokalen Instanz unter Setup > General > Distributed Monitoring findet.

Remote-Instanz: Das Plugin warn_remote_site.py erkennt, dass es sich um eine Remote-Instanz handelt und weist entsprechend darauf hin, dass die Zentralinstanz manuell geprüft und gegebenenfalls angepasst werden muss. Das heißt hier konkret: In den Distributed-Monitoring-Einstellungen auf der Zentralinstanz muss in der Verbindungseinstellung zur umbenannten Remote-Instanz deren neuer Name eingetragen werden — das kann OMD von einem entfernten Rechner aus freilich nicht leisten.

OMD selbst informiert Sie im Terminal ausführlich über das gesamte Prozedere. Hier sehen Sie beispielhaft die Migrationsmeldungen der omd cp-Ausgabe beim Umbenennen einer Zentralinstanz - getrennt nach Erfolgs- und Warnmeldungen. Die abgearbeiteten rename actions plugins werden dabei einzeln durchnummeriert. Zunächst die Ausgabe der automatisch erfolgten Migrationsaufgaben (gekürzt):

Der zweite Teil der Ausgabe enthält nun Hinweise bezüglich Einstellungen, die Sie möglicherweise manuell anpassen müssen (stark gekürzt):

Zum Punkt Warn about configurations to review…​ gehören allgemeine Hinweise zu einzelnen Aspekten, die bei einer Migration generell manuell geprüft werden müssen, beispielsweise hartkodierte Filter für Ansichten:

Hier eine Übersicht der derzeit sechs aktiven Plugins - die Reihenfolge entspricht der Nummerierung in den obigen Ausgaben:

Wenn Sie mit der Instanz eine größere Zahl von Hosts überwachen, können die Datenmengen, die kopiert werden müssen, schon ganz erheblich sein. Der Großteil wird dabei durch die Messwerte verursacht, die in den Round-Robin-Datenbanken (RRDs) gespeichert sind. Aber auch die Log-Dateien mit historischen Ereignissen können größere Datenmengen erzeugen.

Wenn Sie die Historie nicht benötigen (z.B. weil Sie einfach schnell etwas testen möchten), können Sie diese beim Kopieren weglassen. Dazu dienen folgende Optionen, die Sie bei omd cp angeben können:

Die Reihenfolge der Option(en) ist dabei wichtig:

Das Umbenennen einer Instanz erfolgt mit dem Befehl omd mv. Dies geschieht analog zum Kopieren einer Instanz, hat die gleichen Voraussetzungen und wird ebenfalls inklusive der Migration der Konfiguration durchgeführt. Die Optionen zum Beschränken der Datenmengen existieren hier nicht, weil die Dateien ja einfach nur in ein anderes Verzeichnis verschoben und nicht dupliziert werden.

Beispiel:

Wie beim Erstellen einer Instanz wird auch beim Kopieren und beim Umbenennen jeweils ein neuer Linux-Benutzer angelegt. Daher verfügen omd cp und omd mv auch über einige der Optionen von omd create, z.B. zur Festlegung von Benutzer- und Gruppen-IDs. Genaue Information erhalten Sie mit den Befehlen omd cp --help und omd mv --help.

Die Instanzverwaltung von Checkmk hat einen eingebauten Mechanismus zum Sichern und Wiederherstellen von Checkmk-Instanzen. Die Grundlage davon sind die Befehle omd backup und omd restore, welche alle Daten einer Instanz in ein tar-Archiv einpacken bzw. von dort wieder auspacken.

Hinweis: Checkmk bietet auch die Möglichkeit Backup und Restore ohne Kommandozeile über die GUI durchzuführen unter Setup > Maintenance > Backups. Dort können Sie auch verschlüsselte Backups und zeitgesteuerte Backup-Aufträge erstellen. Im Artikel zu Backups erfahren Sie, wie das geht.

Das Sichern einer Instanz mit omd backup erfordert keine root-Rechte. Sie können es als Instanzbenutzer ausführen. Geben Sie einfach als Argument den Namen einer zu erzeugenden Backup-Datei an:

Beachten Sie dabei:

Wenn das Zielverzeichnis der Sicherung nicht als Instanzbenutzer schreibbar ist, können Sie die Sicherung auch als root durchführen. Dazu benötigen Sie wie immer als zusätzliches Argument den Namen der zu sichernden Instanz:

Die Sicherung enthält alle Daten der Instanz — außer den flüchtigen Daten unterhalb von ~/tmp/. Sie können mit dem Befehl tar tzf einfach einen Blick in die Datei werfen:

Der Löwenanteil der zu bewegenden Daten bei einer Instanzsicherung sind die Messwerte und die Log-Dateien mit historischen Ereignissen. Das gilt beim Sichern genauso wie beim Kopieren einer Instanz. Wenn Sie diese Daten nicht zwingend benötigen, können Sie diese weglassen und so die Sicherung deutlich schneller und die Ergebnisdatei deutlich kleiner machen.

omd backup bietet zum Verzicht auf diese Daten die gleichen Optionen wie omd cp beim Kopieren. Im folgenden Beispiel wird das Backup ohne Messdaten und ohne die in den Log-Dateien gespeicherte Historie erstellt:

Ein Backup kann auch von einer laufenden Instanz erstellt werden. Um einen konsistenten Stand der für das Aufzeichnen der Messdaten verwendeten Round-Robin-Datenbanken (RRDs) zu gewährleisten, versetzt der Befehl omd backup den Round-Robin-Cache automatisch in einen Modus, bei dem laufende Updates nur noch in das Journal und nicht mehr in die RRDs geschrieben werden. Die Journaldateien werden zu allerletzt gesichert. Damit wird erreicht, dass möglichst viele der Messdaten, die während der Sicherung angefallen sind, noch mitgesichert werden.

Das Zurückspielen einer Sicherung ist ebenso einfach wie das Sichern selbst. Der Befehl omd restore stellt eine Instanz aus einer Sicherung wieder her — in der Checkmk-Version, mit der die Instanz gesichert wurde. Damit das Wiederherstellen klappt, muss daher diese Version auf dem Server installiert sein.

Die Instanz wird komplett geleert und neu befüllt. Vor dem omd restore muss die Instanz gestoppt sein und danach muss sie dann wieder gestartet werden:

Auch als root-Benutzer ist ein Wiederherstellen möglich. Anders als beim Aufruf durch den Instanzbenutzer wird dabei die Instanz mit der Sicherung neu erstellt.

Falls also noch eine Instanz mit dem gleichen Namen existiert, müssen Sie diese vorher löschen. Das können Sie entweder mit einem omd rm erledigen, oder Sie geben beim omd restore die Option --reuse mit an. Ein --kill sorgt zusätzlich dafür, dass die noch bestehende Instanz vorher gestoppt wird. Den Namen der Instanz brauchen Sie beim Befehl nicht anzugeben, da dieser in der Sicherung enthalten ist:

Als root-Benutzer können Sie eine Instanz auch mit einem anderen Namen als dem in der Sicherung gespeicherten wiederherstellen. Geben Sie dazu den gewünschten Namen als Argument hinter dem Wort restore an:

Die lange Liste der Konvertierungen, die hier stattfinden, hat den gleichen Grund wie bei dem weiter oben beschriebenen Kopieren und Umbenennen von Instanzen. Der Name der Instanz kommt in etlichen Konfigurationsdateien vor und wird hier automatisch durch den neuen Namen ersetzt.

Die Befehle omd backup und omd restore können — in guter alter Unix-Tradition — anstelle von Dateien auch über die Standard-Ein-/Ausgabe arbeiten. Geben Sie hierzu anstelle eines Pfads für die tar-Datei einfach einen Bindestrich (-) an.

Auf diese Art können Sie eine Pipe aufbauen und die Daten ohne Zwischendatei direkt auf einen anderen Rechner „streamen“. Je größer die Sicherung ist, desto nützlicher ist das, denn so wird kein temporärer Platz im Dateisystem des gesicherten Servers benötigt.

Folgender Befehl sichert eine Instanz per SSH auf einen anderen Rechner:

Wenn Sie den SSH-Zugriff umdrehen, sich also lieber vom Backup Server auf die Checkmk-Instanz verbinden möchten, so geht auch das, wie folgendes Beispiel zeigt. Dazu muss zuvor ein SSH-Login als Instanz-Benutzer erlaubt werden.

Wenn Sie das geschickt mit einem omd restore kombinieren, das die Daten von der Standardeingabe liest, können Sie eine komplette Instanz im laufenden Betrieb von einem Server auf einen anderen kopieren — und das ohne irgendeinen zusätzlichen Platz für eine Sicherungsdatei:

Und jetzt nochmal das Ganze mit umgedrehtem SSH-Zugriff — diesmal wieder vom Quellsystem auf das Zielsystem: