Checkmk
to checkmk.com

1. OMD — Die Open Monitoring Distribution

Das Checkmk Monitoring-System baut auf der Open Monitoring Distribution (OMD) auf. OMD ist ein von Mathias Kettner gegründetes Open Source Projekt, das sich rund um die komfortable und flexible Installation einer Monitoring-Lösung aus diversen Komponenten dreht. Die Abkürzung OMD haben Sie bereits als Teil der Namen der installierten RPM/DEB-Pakete kennengelernt.

Eine OMD-basierte Installation zeichnet sich durch diese Eigenschaften aus:

  • die Möglichkeit mehrere Monitoring-Instanzen parallel zu betreiben,

  • die Möglichkeit, dies in unterschiedlichen Versionen der Monitoring-Software zu tun,

  • einen intelligenten und komfortablen Mechanismus zur Aktualisierung (update) der Software,

  • einheitliche Dateipfade — egal welche Linux-Plattform Sie einsetzen,

  • eine saubere Trennung von Daten und Software,

  • eine sehr einfache Installation — ohne Abhängigkeit von Drittanbieter-Software,

  • eine perfekte Vorkonfiguration aller Komponenten.

OMD wird auf der Kommandozeile verwaltet, mit dem Befehl omd — genauer mit einer Reihe von omd-Befehlen für die unterschiedlichen Aktionen rund um die Verwaltung der Monitoring-Instanzen, z.B. omd create für das Anlegen einer Instanz. Die wichtigsten omd-Befehle werden in diesem Artikel vorgestellt.

Der erste Befehl ist omd help, der eine Übersicht der verfügbaren omd-Befehle anzeigt. Hilfe zu einem dieser Befehle erhalten Sie, indem Sie hinter den Befehl die Option --help anfügen, z.B. omd create --help. Die beiden Bindestriche vor dem help sind dabei wichtig, denn ohne sie hätten Sie mit omd create help bereits Ihre erste Instanz mit dem Namen help erstellt.

2. Erstellen von Instanzen

Das vielleicht Beste an OMD ist, dass OMD auf einem Server beliebig viele Monitoring-Instanzen verwalten kann. Diese heißen auf Englisch monitoring sites. Jede Instanz ist ein in sich geschlossenes Monitoring-System, welches von den anderen getrennt läuft.

Eine Instanz hat immer einen eindeutigen Namen, der bei ihrer Erstellung festgelegt wird. Dieser ist gleichzeitig der Name eines Linux-Benutzers, der dabei angelegt wird. Der Instanzname orientiert sich an den Konventionen zu Benutzernamen unter Linux. Das erste Zeichen eines Instanznamen muss ein Buchstabe sein, alle weiteren Zeichen dürfen Buchstaben, Ziffern und Unterstriche sein. Die Länge darf maximal 16 Zeichen betragen.

Das Erstellen geschieht mit dem Befehl omd create. Dieser muss als root-Benutzer ausgeführt werden:

root@linux# omd create mysite
Adding /opt/omd/sites/mysite/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Updating core configuration...
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Executing post-create script "01_create-sample-config.py"...OK
Restarting Apache...OK
Created new site mysite with version 2.1.0p17.cre.

  The site can be started with omd start mysite.
  The default web UI is available at http://linux/mysite/

  The admin user for the web applications is cmkadmin with password: YzxfoFZh
  For command line administration of the site, log in with 'omd su mysite'.
  After logging in, you can change the password for cmkadmin with 'cmk-passwd cmkadmin'.

Bei der Erstellung des Benutzers cmkadmin wird ein zufällig generiertes Passwort angelegt und ausgegeben.

Was geschieht beim Anlegen einer Instanz mit dem Namen mysite?

  • Ein Betriebssystembenutzer mysite und eine Gruppe mysite werden angelegt.

  • Dessen neues Home-Verzeichnis /omd/sites/mysite wird angelegt und diesem übereignet. Dieses Verzeichnis wird auch Instanzverzeichnis (englisch: site directory) genannt.

  • Dieses Verzeichnis wird mit Konfigurationsdateien und Verzeichnissen gefüllt.

  • Für die neue Instanz wird eine Grundkonfiguration erstellt.

Hinweis: Es ist nicht möglich eine neue Instanz mit einem Namen zu erstellen, der auf dem Server bereits als Namen eines "normalen" Benutzers vergeben ist.

2.1. Benutzer- und Gruppen-IDs

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

root@linux# omd create -u 6100 -g 180 mysite

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

-u UID

Der neue Benutzer wird mit der Benutzer-ID UID angelegt.

-g GID

Die Gruppe des neuen Benutzers wird mit der Gruppen-ID GID angelegt.

--admin-password mypassword

Der neue Benutzer wird — statt mit dem zufällig generierten — mit dem Passwort mypassword angelegt.

--reuse

OMD geht davon aus, dass der neue Benutzer bereits existiert und legt ihn nicht an. Das Home-Verzeichnis dieses Benutzers muss sich unterhalb von /omd/sites/ befinden und leer sein.

-t SIZE

Das temporäre Dateisystem der neuen Instanz wird mit der Größe SIZE angelegt. SIZE endet mit M (Megabyte), G (Gigabyte) oder % (Prozent vom RAM). Beispiel: -t 4G

2.2. Externes Instanzverzeichnis

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:

root@linux# omd create --no-init mysite

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:

root@linux# omd init mysite

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

3. Instanzbenutzer

Die omd-Befehle können Sie als root-Benutzer oder als Instanzbenutzer (englisch: site user) ausführen. Unter root haben Sie mehr Möglichkeiten. So kann nur root eine Instanz erstellen, was nachvollziehbar ist, denn erst beim Erstellen der Instanz wird der Instanzbenutzer angelegt. Da Sie unter root Befehle für alle existierenden Instanzen ausführen können, müssen Sie den Namen der Instanz, um die es geht, beim omd-Befehl mit angeben.

Sobald die Instanz existiert, sollten Sie die weiteren omd-Befehle nur noch als Instanzbenutzer ausführen. Als Instanzbenutzer können Sie alle wichtigen Operationen durchführen, die diese Instanz betreffen.

Der Benutzerwechsel geschieht mit su:

root@linux# su - mysite

Beachten Sie unbedingt das Minuszeichen nach dem su. Es sorgt dafür, dass der Benutzerwechsel alle Operationen durchläuft, die auch bei einer normalen Anmeldung ablaufen. Insbesondere werden alle Umgebungsvariablen korrekt gesetzt, und Ihre Sitzung wird als mysite im Instanzverzeichnis /omd/sites/mysite gestartet:

OMD[mysite]:~$

Sobald sie als Instanzbenutzer angemeldet sind, brauchen Sie in der Regel bei omd-Befehlen keinen Instanznamen mitanzugeben, da so ein Befehl auf die Instanz angewendet wird, unter der Sie angemeldet sind.

Falls Sie mehrere Checkmk-Versionen auf Ihrem Checkmk-Server installiert haben, wird mit jeder dieser Versionen auch die zugehörige OMD-Version mitinstalliert. Da kann sich mit der Zeit schon eine lange Liste von Software-Versionen ansammeln. Da sich auch omd-Befehle zwischen den Versionen unterscheiden können, ist es manchmal interessant zu wissen, mit welcher OMD-Version Sie gerade arbeiten:

  • Als Instanzbenutzer nutzen Sie stets die omd-Befehle der auf der Instanz aktuell installierten Checkmk-Version, die Sie sich mit omd version anzeigen lassen können.

  • Als root-Benutzer werden die Befehle der Standardversion ausgeführt, die auch bei der Erstellung einer Instanz verwendet wird. In der Regel ist das die zuletzt auf dem Server installierte Version. Die Standardversion können Sie sich mit omd version anzeigen lassen und mit omd setversion ändern.

4. Starten und Stoppen von Instanzen

Ihre Instanz ist jetzt bereit, gestartet zu werden. Sie können das als root mit omd start mysite machen. Besser ist es aber, wenn Sie das Arbeiten mit der Instanz grundsätzlich als Instanzbenutzer erledigen:

OMD[mysite]:~$ omd start
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Starting agent-receiver...OK
Starting mkeventd...OK
Starting rrdcached...OK
Starting npcd...OK
Starting nagios...OK
Starting apache...OK
Starting redis...OK
Initializing Crontab...OK

Wenig überraschend geht das Anhalten mit omd stop:

OMD[mysite]:~$ omd stop
Removing Crontab...OK
Stopping redis...killing 484382...OK
Stopping apache...killing 484371...OK
Stopping nagios...OK
Stopping npcd...OK
Stopping rrdcached...waiting for termination...OK
Stopping mkeventd...killing 484279...OK
Stopping agent-receiver...killing 484267...OK
Stopping 1 remaining site processes...OK

Das Starten und Stoppen einer Instanz ist nichts anderes als das Starten bzw. Stoppen einer Reihe von Diensten. Diese können auch einzeln verwaltet werden, indem Sie den Namen des Diensts mit angeben, z.B.:

OMD[mysite]:~$ omd start apache
Temporary filesystem already mounted
Starting apache...OK

Wie die einzelnen Dienste heißen, erfahren Sie im Verzeichnis ~/etc/init.d. Beachten Sie die Tilde (~) am Anfang des Pfadnamens. Diese steht für das Home-Verzeichnis des Instanzbenutzers (das Instanzverzeichnis). ~/etc/init.d und /etc/init.d sind unterschiedliche Verzeichnisse.

Neben start und stop gibt es noch die omd-Befehle restart, reload und status. Das Neuladen von Apache ist z.B. immer nach einer manuellen Änderung der Apache-Konfiguration notwendig:

OMD[mysite]:~$ omd reload apache
Reloading apache

Beachten Sie, dass hier nicht der globale Apache-Prozess des Linux-Servers gemeint ist, sondern ein eigener dedizierter Apache-Prozess in der Instanz selbst:

Um nach den ganzen Starts und Stops einen Überblick vom Zustand der Instanz zu erhalten, verwenden Sie einfach omd status:

OMD[mysite]:~$ omd status
agent-receiver: stopped
mkeventd:       stopped
rrdcached:      stopped
npcd:           stopped
nagios:         stopped
apache:         running
redis:          stopped
crontab:        stopped
-----------------------
Overall state:  partially running

5. Konfigurieren der Komponenten

Wie bereits erwähnt, integriert OMD mehrere Software-Komponenten zu einem Monitoring-System. Dabei sind manche Komponenten optional und für manche gibt es Alternativen oder verschiedene Betriebseinstellungen. Dies alles kann komfortabel mit dem Befehl omd config konfiguriert werden. Dabei gibt es einen interaktiven Modus und einen Skriptmodus.

5.1. Interaktive Konfiguration

Den interaktiven Modus rufen Sie als Instanzbenutzer einfach so auf:

OMD[mysite]:~$ omd config
Hauptmenü von 'omd config'.
Im omd config-Menü navigieren Sie mit den Cursor- und Enter-Tasten

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:

Hinweis zum Ändern einer Einstellung bei gestarteter Instanz.
Die Konfiguration kann nur geändert werden, wenn die Instanz nicht läuft

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

5.2. Konfiguration per Skriptmodus

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:

OMD[mysite]:~$ omd config set AUTOSTART off

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

root@linux# omd config mysite set AUTOSTART off

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

OMD[mysite]:~$ omd config show
ADMIN_MAIL:
AGENT_RECEIVER: on
AGENT_RECEIVER_PORT: 8005
APACHE_MODE: own
APACHE_TCP_ADDR: 127.0.0.1
APACHE_TCP_PORT: 5008
AUTOSTART: off
[...]

Die obige Kommandoausgabe zeigt nur die ersten Einträge.

5.3. Häufig benötigte Einstellungen

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

Variable Standard Bedeutung

AUTOSTART

on

Stellen Sie dies auf off, wenn Sie verhindern möchten, dass diese Instanz beim Hochfahren des Rechners automatisch gestartet wird. Das ist vor allem bei Testinstallationen interessant, die normalerweise nicht laufen sollen.

CORE

nagios (Raw Edition),
cmc (kommerzielle Editionen)

Auswahl des Monitoring-Kerns. In den kommerziellen Editionen kann statt des Checkmk Micro Core (CMC) auch der Nagios-Kern ausgewählt werden. In der CRE Checkmk Raw Edition gibt es nur nagios als Monitoring-Kern.

MKEVENTD

on

Aktiviert die Event Console, mit der Sie Syslog-Meldungen, SNMP-Traps und andere Events verarbeiten können.

LIVESTATUS_TCP

off

Hiermit erlauben Sie Zugriff auf die Statusdaten dieser Instanz von außen. Damit kann ein verteiltes Monitoring aufgebaut werden. Auf der Zentralinstanz kann dann der Status dieser (Remote-) Instanz eingebunden werden. Aktivieren Sie diese Einstellung nur in einem abgesicherten Netzwerk.

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

6. Kopieren und Umbenennen von Instanzen

6.1. Kopieren von Instanzen

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:

  • in vielen Konfigurationsdateien ist der Name der Instanz enthalten,

  • auch tauchen an etlichen Stellen absolute Pfade auf, die mit /omd/sites/mysite_old beginnen,

  • und nicht zuletzt muss es auf Betriebssystemebene einen Benutzer samt zugehöriger Gruppe geben, dem die Instanz gehört und der standardmäßig so heißt, wie die Instanz.

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

root@linux# omd cp mysite_old mysite_new

Das Kopieren geht nur, wenn

  • die Instanz gestoppt ist und

  • keine Prozesse mehr laufen, die dem Instanzbenutzer gehören.

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

6.2. Migration der Konfiguration

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:

OMD[mysite]:~$ grep -r $OMD_SITE etc

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):

...
Executing post-cp script "01_cmk-post-rename-site"...
-|  1/6 Distributed monitoring configuration...
-|  2/6 Hosts and folders...
-|  3/6 Update core config...
...

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

...
-|  4/6 Warn about renamed remote site...
-|  5/6 Warn about new network ports...
-|  6/6 Warn about configurations to review...
...

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:

...
-| Parts of the site configuration cannot be migrated automatically. The following
-| parts of the configuration may have to be reviewed and adjusted manually:
-|
-| - Custom bookmarks (in users bookmark lists)
-| - Hard coded site filters in custom dashboards, views, reports
-| - Path in rrdcached journal files
-| - NagVis maps or custom NagVis backend settings
-| - Notification rule "site" conditions
-| - Event Console rule "site" conditions
-| - "site" field in "Agent updater (Linux, Windows, Solaris)" rules (CEE/CME only)
-| - Alert handler rule "site" conditions (CEE/CME only)
-|
-| Done

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

Plugin Funktion

sites.py

Ändert die Instanz-ID in diversen Konfigurationsdateien.

hosts_and_folders.py

Ändert das Instanz-Attribut von Host- und Ordner-Eigenschaften.

update_core_config.py

Aktualisiert die Konfiguration des Kerns (cmk -U).

warn_remote_site.py

Hinweise beim Umbenennen einer Remote-Instanz.

warn_changed_ports.py

Hinweise bezüglich Problemen mit mehrfach genutzten Ports.

warn_about_not_migrated_configs.py

Allgemeine Hinweise zu Aspekten, die manuell geprüft werden sollten.

6.3. Datenmengen einschränken

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:

--no-rrds

Kopiert die Instanz ohne die RRDs.

--no-logs

Kopiert die Instanz ohne Log-Dateien und übrige historische Daten.

-N

Macht beides: -N ist eine Abkürzung für --no-rrds --nologs.

Die Reihenfolge der Option(en) ist dabei wichtig:

root@linux# omd cp --no-rrds mysite_old mysite_new

6.4. Instanzen umbenennen

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:

root@linux# omd mv mysite_old mysite_new

6.5. Weitere Optionen

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.

7. Änderungen in Konfigurationsdateien anzeigen

Beim Erstellen einer Instanz füllt der Befehl omd create das Verzeichnis ~/etc mit vielen vordefinierten Konfigurationsdateien. Auch unter ~/var und ~/local werden etliche Verzeichnisse angelegt.

Nun ist es wahrscheinlich so, dass Sie im Laufe der Zeit einige der Dateien anpassen werden. Wenn Sie nach einiger Zeit feststellen möchten, welche Dateien nicht mehr dem Auslieferungszustand entsprechen, können Sie das mit dem Befehl omd diff herausfinden. Nützlich ist dies unter anderem vor einem Update von Checkmk, da hier Ihre Änderungen möglicherweise im Konflikt stehen mit Änderungen der Standarddateien.

Bei einem Aufruf ohne weitere Argumente sehen Sie alle geänderten Dateien unterhalb des aktuellen Verzeichnisses:

OMD[mysite]:~$ omd diff
 * Changed content var/check_mk/wato/auth/auth.php
 ! Changed permissions var/check_mk/wato/auth/auth.php
 * Changed content etc/htpasswd
 * Changed content etc/diskspace.conf
 ! Changed permissions etc/diskspace.conf
 * Changed content etc/auth.secret
 * Changed content etc/mk-livestatus/xinetd.conf
 * Changed content etc/omd/allocated_ports
 * Changed content etc/apache/apache.conf
 * Deleted etc/apache/apache-own.conf

Sie können beim Aufruf auch ein Verzeichnis angeben:

OMD[mysite]:~$ omd diff etc/apache
 * Changed content etc/apache/apache.conf
 * Deleted etc/apache/apache-own.conf

Wenn Sie die Änderungen in der Datei im Detail sehen möchten, geben Sie einfach den Pfad zur Datei an:

OMD[mysite]:~$ omd diff etc/apache/apache.conf
74,75c74,75
< ServerLimit          64
< MaxClients           64
---
> ServerLimit          128
> MaxClients           128

8. Instanzen aktualisieren

Um die auf der Instanz installierte Monitoring-Software auf eine höhere Version zu aktualisieren, dient der Befehl omd update. Dieser wird ausführlich im Artikel zum Update von Checkmk vorgestellt. Dort werden auch weitere nützliche omd-Befehle rund um das Software-Update beispielhaft gezeigt:

  • omd versions zur Auflistung aller installierten Software-Versionen,

  • omd sites zur Auflistung aller existierender Instanzen mit den auf ihnen installierten Versionen,

  • omd version zur Anzeige der Standardversion, die bei der Erstellung einer Instanz verwendet wird,

  • omd setversion zur Festlegung einer anderen Standardversion.

Mit omd update wird übrigens auch ein Upgrade auf eine andere Edition durchgeführt, z.B. von der Raw Edition auf die Standard Edition.

9. Instanzen sichern und wiederherstellen

9.1. Backup erstellen

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:

OMD[mysite]:~$ omd backup /tmp/mysite.tar.gz

Beachten Sie dabei:

  • Der erzeugte Dateityp ist ein gzip-komprimiertes tar-Archiv. Verwenden Sie daher .tar.gz oder .tgz als Dateiendung.

  • Legen Sie die Sicherung nicht in das Instanzverzeichnis. Denn dieses wird ja komplett gesichert. So würde jedes weitere Backup alle bisherigen als Kopie enthalten.

  • Wenn Sie das Backup als Instanzbenutzer erstellen, erhält nur der Instanzbenutzer und seine Gruppe Lese- und Schreibzugriff auf das tar-Archiv.

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:

root@linux# omd backup mysite /var/backups/mysite.tar.gz

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:

OMD[mysite]:~$ tar tvzf /tmp/mysite.tar.gz  | less
lrwxrwxrwx mysite/mysite     0 2022-07-25 11:59 mysite/version -> ../../versions/2.1.0p8.cre
drwxr-xr-x mysite/mysite     0 2022-07-25 17:25 mysite/
-rw------- mysite/mysite   370 2022-07-26 17:09 mysite/.bash_history
-rw-r--r-- mysite/mysite  1091 2022-07-25 11:59 mysite/.bashrc
-rw-r--r-- mysite/mysite    63 2022-07-25 11:59 mysite/.modulebuildrc
-rw-r--r-- mysite/mysite  2066 2022-07-25 11:59 mysite/.profile
drwxr-xr-x mysite/mysite     0 2022-07-25 11:59 mysite/.version_meta/
drwxr-xr-x mysite/mysite     0 2022-07-20 11:40 mysite/.version_meta/skel/
-rw-r--r-- mysite/mysite  1091 2022-06-26 02:03 mysite/.version_meta/skel/.bashrc
-rw-r--r-- mysite/mysite    52 2022-07-20 09:02 mysite/.version_meta/skel/.modulebuildrc
-rw-r--r-- mysite/mysite  2055 2022-06-26 02:03 mysite/.version_meta/skel/.profile
drwxr-xr-x mysite/mysite     0 2022-07-20 11:40 mysite/.version_meta/skel/etc/
drwxr-xr-x mysite/mysite     0 2022-07-20 11:40 mysite/.version_meta/skel/etc/apache/
-rw-r--r-- mysite/mysite  1524 2022-06-26 02:03 mysite/.version_meta/skel/etc/apache/apache-own.conf

9.2. Backup ohne Historie

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:

OMD[mysite]:~$ omd backup -N /tmp/mysite.tar.gz

9.3. Backup bei laufender Instanz

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.

9.4. Restore

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:

OMD[mysite]:~$ omd stop
OMD[mysite]:~$ omd restore /tmp/mysite.tar.gz
OMD[mysite]:~$ omd start

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:

root@linux# omd restore --reuse --kill /var/backup/mysite.tar.gz
root@linux# omd start mysite

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:

root@linux# omd restore mysite2 /var/backup/mysite.tar.gz
Restoring site mysite2 from /tmp/mysite.tar.gz...
 * Converted      ./.modulebuildrc
 * Converted      ./.profile
 * Converted      etc/xinetd.conf
 * Converted      etc/logrotate.conf

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.

9.5. Live Backup & Restore auf einen anderen Server

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:

root@linux# omd backup mysite - | ssh user@otherserver "cat > /var/backup/mysite.tar.gz"

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.

root@otherserver# ssh mysite@checkmkserver "omd backup -" > /var/backup/mysite.tar.gz

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:

root@otherserver# ssh mysite@checkmkserver "omd backup -" | omd restore -

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

root@linux# omd backup mysite - | ssh user@otherserver "omd restore -"

10. Instanzen deaktivieren

OMD kann Instanzen deaktivieren. Mit dem Befehl omd disable --kill mysite, ausgeführt als root, passiert Folgendes:

  1. Die Instanz mysite wird gestoppt.

  2. Prozesse, die auf das tmpfs zugreifen, werden gestoppt.

  3. Das tmpfs wird ausgehängt.

  4. Die Datei /omd/apache/mysite.conf wird geleert.

  5. Apache wird neu gestartet.

In diesem Status wird das Home-Verzeichnis der Instanz, hier /omd/sites/mysite, von keinem Prozess mehr referenziert. Praktisch ist dies vor allem in einem Cluster, da sich das Home-Verzeichnis nun auf einen anderen Knoten verschieben lässt.

11. Instanzen löschen

Das Löschen einer Instanz geht ebenso einfach wie das Erstellen — mit dem Befehl omd rm als root. Dabei wird die Instanz vorher automatisch gestoppt.

root@linux# omd rm mysite
PLEASE NOTE: This action removes all configuration files
             and variable data of the site.

In detail the following steps will be done:
- Stop all processes of the site
- Unmount tmpfs of the site
- Remove tmpfs of the site from fstab
- Remove the system user <SITENAME>
- Remove the system group <SITENAME>
- Remove the site home directory
- Restart the system wide apache daemon
 (yes/NO): yes

Man muss wohl nicht extra dazuschreiben, dass hierbei alle Daten der Instanz gelöscht werden!

Wenn Sie kein Freund von Sicherheitsabfragen sind oder das Löschen in einem Skript durchführen wollen, können Sie mit der Option -f das Löschen erzwingen.

Achtung: -f muss hier vor dem rm stehen:

root@linux# omd -f rm mysite

12. Ungenutzte Versionen deinstallieren

Da Checkmk in mehreren Versionen gleichzeitig installiert sein darf, kann es vorkommen, dass nicht alle Versionen auch wirklich von einer Instanz genutzt werden. OMD kann ungenutzte Versionen mit dem Kommando cleanup deinstallieren:

root@linux# omd cleanup
1.6.0p28.cee         In use (by mysite_old). Keeping this version.
2.1.0p15.cee         Uninstalling
2.1.0p15.cme         Uninstalling
2.1.0p15.cre         In use (by mysite_raw). Keeping this version.
2.1.0p19.cme         Keeping this version, since it is the default.
2022.12.14.cee       In use (by mysite). Keeping this version.

OMD behält dabei neben den genutzten Versionen auch die Standardversion. Die Standardversion ist, sofern nicht manuell mit omd setversion anders konfiguriert, die zuletzt installierte Version von Checkmk, im obigen Beispiel also 2.1.0p19.cme.

13. Dateien und Verzeichnisse

Pfad Bedeutung

/omd/sites/mysite

Instanzverzeichnis der Instanz mysite.

~/etc/

In diesem Verzeichnis werden die Konfigurationsdateien der Instanz abgelegt.

Auf dieser Seite