Workshop: Monitoring mit Checkmk – Teil 2 Monitoring von Servern und Workstations

Nach Theorie und Konzepten aus Teil 1 dieser Mini-Serie gibt es jetzt ein wenig Hands-on-Praxis: Wie gelingt der Start mit Checkmk, wie lassen sich Server überwachen?

Im ersten Teil der Serie haben wir gesehen, wie Checkmk grundsätzlich tickt: Der Server läuft auf einem Linux-System und entweder holen sich Agenten vom Server aus Daten von den Netzwerkgeräten via SNMP oder deren APIs. Oder der Checkmk-Agent wird auf Servern und Workstations installiert, wo er Daten sammelt und diese auf Anfrage an den Server übermittelt. Dort werden die Roh-Daten dann von Checks ausgewertet, um Hosts auf die Status UP oder DOWN und Services auf OK, WARN oder CRIT zu setzen.

Nun möchten wir zeigen, wie das Monitoring eines Servers in der Praxis aussehen kann. Und da es mit einer simplen Installationsroutine nicht getan ist, beginnen wir mit der Einrichtung – in aller Kürze.

Bildergalerie

Bildergalerie mit 5 Bildern

Die ersten Schritte

Checkmk selbst ist schnell und wie gewohnt installiert, dann allerdings muss zunächst eine „Site“, auch Instanz genannt, eingerichtet werden. Eine Instanz ist quasi ein Monitoring-Projekt – zum Beispiel für die gesamte interne IT. Weitere Instanzen könnten für Kunden aufgesetzt werden, als Backup oder Testsystem dienen oder schlicht voneinander unabhängige Bereiche völlig voneinander getrennt bedienen. Das Einrichten, Starten, Aktualisieren und Verwalten von Instanzen ist der einzige Part im Umgang mit Checkmk, der auf der Kommandozeile stattfindet.

In einem realen Projekt sollte nach der Installation zunächst eine Strukturierung stattfinden, sprich vor allem der Aufbau einer Ordnerstruktur – das ist konzeptionell nicht ganz trivial und hat später enorme Auswirkungen. Vor allem aus einem einfachen Grund: Wie in Teil 1 beschrieben, werden Hosts und Services über Regeln konfiguriert. Und diese Regeln lassen sich direkt auf Ordner anwenden! Außerdem können Ordnern Eigenschaften zugeordnet werden, die sich an deren Inhalte und Unterordner vererben lassen. So würden sich beispielsweise Ordnerstrukturen für Orte oder Nutzungsarten (Workstation, Server) anbieten.

Und eigentlich sollte noch eine Angelegenheit ganz zu Beginn geregelt werden: Benachrichtigungen. Checkmk kann auf diversen Wegen benachrichtigen, beispielsweise via Jira, Microsoft Teams, Slack oder Mail. Und möchte man nicht versehentlich Dutzende Nutzer mit Hunderten von Benachrichtigungen belästigen, sollte man hier ebenfalls vorausschauend ans Werk gehen. Das Grundkonzept: Nutzer werden Kontaktgruppen zugeordnet und Kontaktgruppen werden Monitoring-Objekten zugeordnet: „Armin Admin“ ist Mitglied der Gruppe „Linux-Admins“, die wiederum allen Servern im Ordner „Linux-Server“ zugeordnet ist.

Server ins Monitoring aufnehmen

Testen kann man natürlich jederzeit auch ohne die obigen Schritte – weder Ordner noch Kontaktgruppen noch Benachrichtigungen müssen überhaupt konfiguriert werden! Die erste Aufgabe besteht stets darin, Hosts und ihre Services ins Monitoring zu bekommen. Und ohne nun jeden einzelnen Schritt auszuführen, so sieht der Workflow standardmäßig aus:

• Host über IP-Adresse in der Checkmk-Weboberfläche anlegen

• Agenten auf dem Host über die Weboberfläche herunterladen und installieren

• Host am Checkmk-Server anmelden

• Über die Weboberfläche eine Service-Erkennung durchführen lassen

• Alle oder die gewünschten Services ins Monitoring übernehmen

• Änderungen akzeptieren

Der letzte Punkt wird einem in Checkmk immer wieder begegnen: Alle Änderungen an der Konfiguration treten erst in Kraft, wenn sie gemeinsam über „Activate Changes“ akzeptiert werden.

Dieser Prozess ist recht aufwändig, für einen Host sind rund ein Dutzend Einzelschritte notwendig – dafür gibt es dann aber auch verschlüsselte Kommunikation zwischen Checkmk-Server und -Agent.

Sobald dies geschehen ist, landet endlich einen Host samt Services im Monitoring – und erfreulicherweise haben all diese Services bereits einen Status, da die Standard-Checks mit sinnvollen Vorgaben ausgestattet sind (beispielsweise geht ein Dateisystem ab 80 Prozent Auslastung von OK auf WARN).

Freilich kann man sich auch entscheiden, gefundene Services einmalig zu ignorieren oder sie dauerhaft vom Monitoring auszuschließen. Das Ausschließen von Diensten erfolgt übrigens wie nahezu jede Konfiguration in Checkmk über eine Regel. So könnte die Regel „Disabled Services“ dafür sorgen, dass alle Services zur CPU-Auslastung für alle Hosts im Ordner „Windows-Hosts“ von vornherein ignoriert werden.

Was soll wie gemonitort werden?

Wir haben nun also Hosts und deren Services dem Monitoring hinzugefügt und nach Checkmk-Vorgaben ausgewertet. Der nächste Schritt wäre nun die Anpassung dieser Checks und Vorgaben.

Einen Wert, den man auf einem Server sicherlich im Auge behalten will, ist die Auslastung von Dateisystemen. Das Vorgehen hier ist beispielhaft zu verstehen: Zunächst wird die zugehörige Regel benötigt, einfach zu finden über die Suchfunktion im Hauptmenü: „Filesystems (used space and growth)“.

In den meisten Regeln gibt es drei Bereiche: „Rule properties“ für ein paar optionale Metadaten, „Conditions“ zum Setzen von Filtern (etwa auf bestimmte Hosts) sowie einen Bereich mit der eigentlichen Konfiguration.

Für Dateisysteme gibt es hier 18 verschiedene Aspekte, die konfiguriert werden können. Hier zwei Möglichkeiten, die ganz gut demonstrieren, wie feinteilig Checkmk arbeitet:

• „Levels for used/free space“ ermöglicht eine Statusänderung auf WARN oder CRIT, sobald die gesetzten absoluten oder prozentualen Schwellwerte für belegten Platz überschritten werden.

• „Levels on the time left until full“ setzt Statusänderungen durch, wenn es voraussichtlich nur noch die gesetzten Stunden dauert, bis das Dateisystem komplett vollläuft. Hier wird der Trend herangezogen.

Andere Optionen wie „Show space reserved for the root user“ ergänzen schlicht die Anzeige des Services um weitere Informationen.

Bei allen anderen Services, die Checkmk auf dem Host gefunden hat, wird genauso vorgegangen, also beispielsweise bei CPU-Auslastung, Arbeitsspeicher, Netzwerkschnittstellen und so weiter.

Agenten erweitern

Es gibt allerdings auch Dinge, die man gerne monitoren möchte, die allerdings nicht standardmäßig vom Agenten geliefert werden – beispielsweise Windows-Lizenzen.

Wenn man im Hauptmenü nach „windows license“ sucht, bekommt man zwei Regeln namens „Windows License“, einmal unter „Service rules“ und einmal unter „Agent rules“. Service-Regeln sind, was wir eben kennengelernt haben: Sie regeln, wie gelieferte Daten interpretiert werden sollen.

Agenten-Regeln hingegen bestimmen, dass der Agent um ein Plugin erweitert werden soll, das diese zu interpretierenden Daten überhaupt erst mal erhebt. Das Plugin muss deshalb auf den Hosts ausgerollt werden: Hierzu einfach das zugehörige Batch-Skript aus der Weboberfläche herunterladen und in den Agenten-Ordner auf dem Host kopieren – zumindest in der Open-Source-Version. In den kommerziellen Versionen wird der Agent komplett neu kompiliert, samt derlei Plugins (über die in Teil 1 erwähnte Agentenbäckerei).

Sobald die Agenten-Regel zur Windows-Lizenz angelegt und das Plugin ausgerollt ist, muss die zugehörige Service-Regel angelegt werden, um die neu gewonnenen Daten des Plugins zu interpretieren.

Dieses ganze Prozedere ist anfangs nicht wirklich intuitiv durchführbar. Für das Verständnis von Checkmks Arbeitsweise aber wichtig: Agenten-Regeln, um weitere Daten zu erheben (via Plugin) und zugehörige Service-Regeln, um die Daten (via Check) zu interpretieren.

Und falls gestandene Checkmk-Profis mitlesen: Natürlich, das ist leicht vereinfacht.

Im letzten Teil der Checkmk-Serien wird es dann wieder etwas lockerer und wir zeigen, wie konkret Webseiten gemonitort werden und was darüber hinaus möglich ist.

Workshop: Monitoring mit Checkmk – Teil 1

Wie funktioniert das Monitoring mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 3

Monitoring von Webseiten, Mailkonten und Applikationen

Workshop: Monitoring mit Checkmk – Teil 4

Wie sieht eine gute Strukturierung in Checkmk aus?

Workshop: Monitoring mit Checkmk – Teil 5

Die wichtigsten Schritte zur Backup-Überwachung mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 6

Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 7

Dashboards aus Daten: So wird das Checkmk-Inventar sichtbar

Workshop: Monitoring mit Checkmk – Teil 8

Checkmk aktualisieren – vorsichtig!

Workshop: Monitoring mit Checkmk – Teil 9

Checkmk: Android-Geräte überwachen – oder nicht?

Workshop: Monitoring mit Checkmk – Teil 10

So monitoren Sie Proxmox VE mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 11

Webseiten mit check_httpv2 überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 12

Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 13

Checkmk anpassen: Ansichten nach Belieben gestalten

(ID:50196967)