Grundlagen des Monitorings mit Checkmk

Alles in der Überwachung dreht sich um Hosts und Services. Wir haben uns lange Gedanken gemacht, wie man Host ins Deutsche übersetzen könnte und am Ende entschieden, dass wir den Begriff so belassen, um keine unnötige Verwirrung zu stiften. Denn ein Host kann vieles sein, z.B.:

Im Monitoring hat ein Host immer einen der folgenden Zustände:

Neben dem Zustand hat ein Host noch einige Attribute, die vom Benutzer konfiguriert werden, z.B.:

Damit das Monitoring den Zustand UNREACH berechnen kann, muss es wissen, über welchen Weg es jeden einzelnen Host erreichen kann. Dazu kann man bei jedem Host einen oder mehrere sogenannte Parent-Hosts angeben. Wenn z.B. ein Server A vom Monitoring aus gesehen nur über einen Router B erreichbar ist, dann ist B ein Parent-Host von A. In Checkmk konfiguriert werden dabei nur direkte Parents. Daraus ergibt sich dann eine baumartige Struktur mit der Checkmk-Instanz in der Mitte (hier dargestellt als ):

Nehmen wir an, dass in der oben gezeigten beispielhaften Netzwerktopologie die Hosts myhost und myhost4 nicht mehr erreichbar sind. Der Ausfall von myhost4 ist dadurch erklärbar, dass myhost ausgefallen ist. Daher wird myhost4 im Monitoring als UNREACH klassifiziert. Es ist schlicht nicht eindeutig feststellbar, weswegen Checkmk myhost4 nicht mehr erreichen kann und der Status DOWN wäre daher unter Umständen irreführend. Stattdessen bewirkt das UNREACH standardmäßig die Unterdrückung einer Benachrichtigung. Denn das ist die wichtigste Aufgabe des Konzepts der Parents: Die Vermeidung massenhafter Benachrichtigungen, falls ein ganzes Netzwerksegment aufgrund einer Unterbrechung für das Monitoring nicht mehr erreichbar ist.

Der Vermeidung von Fehlalarmen dient auch ein Feature des in den kommerziellen Editionen verwendeten Checkmk Micro Core (CMC). Hier wird der Statuswechsel über einen ausgefallenen Host wenige Augenblicke zurückgehalten und findet erst dann statt, wenn gesichert ist, dass der Parent noch erreichbar ist. Falls der Parent dagegen sicher DOWN ist, wechselt der Host nach UNREACH — ohne dass benachrichtigt wird.

In manchen Fällen hat ein Host mehrere Parents, zum Beispiel, wenn ein Router hochverfügbar in einem Cluster betrieben wird. Für Checkmk reicht es, wenn einer dieser Parents erreichbar ist, um den Status des Hosts eindeutig zu bestimmen. Falls ein Host also mehrere Parents hat und zumindest einer dieser Parents UP ist, wird der Host im Monitoring als erreichbar betrachtet. Mit anderen Worten: In diesem Fall wird der Host nicht automatisch in den Zustand UNREACH wechseln.

Ein Host hat eine Menge von Services. Ein Service kann alles Mögliche sein, bitte verwechseln Sie das nicht mit den Diensten (services) von Windows. Ein Service ist irgendein Teil oder Aspekt des Hosts, der OK sein kann oder eben nicht. Der Zustand von Services kann natürlich immer nur dann abgefragt werden, wenn der Host im Zustand UP ist.

Folgende Zustände kann ein Service im Monitoring haben:

Wenn es darum geht, welcher Zustand „schlimmer“ ist, verwendet Checkmk folgende Reihenfolge:

OK → WARN → UNKNOWN → CRIT

Ein Check sorgt dafür, dass ein Host oder ein Service einen Zustand erhält. Welche Zustände das sein können, ist im vorherigen Abschnitt beschrieben. Services und Checks hängen eng miteinander zusammen. Daher werden sie manchmal, vielleicht sogar in diesem Handbuch, synonym verwendet, obwohl es doch verschiedene Dinge sind.

Im Setup können Sie sich anzeigen lassen, welches Check-Plugin für welchen Service zuständig ist. Öffnen Sie mit Setup > Hosts die Eigenschaften eines Hosts und dann im Menü Hosts > Service Configuration die Liste der Services dieses Hosts. Dann blenden Sie mit Display > Show plugin names eine neue Spalte ein, die Ihnen für jeden Service das zuständige Check-Plugin anzeigt:

Wie Sie am Beispiel des Check-Plugins df sehen, kann ein Check-Plugin für mehrere Services verantwortlich sein. Übrigens sind in der eingeblendeten Spalte die Namen der Check-Plugins Links, die Sie zur Beschreibung des Check-Plugins führen.

Der Zusammenhang und die Abhängigkeit von Services und Checks sind auch im Monitoring zu sehen. In der Service-Liste eines Hosts im Monitoring können Sie feststellen, dass im Aktionsmenü beim Eintrag Reschedule bei einigen Services ein gelber Pfeil steht (), bei den meisten anderen aber ein grauer Pfeil (). Ein Service mit dem gelben Pfeil basiert auf einem aktiven Check:

Solch ein aktiver Check wird von Checkmk direkt ausgeführt. Services mit dem grauen Pfeil basieren auf passiven Checks, deren Daten von einem anderen Service, dem Service Check_MK, geholt werden. Dies geschieht aus Gründen der Performance und stellt eine Besonderheit von Checkmk dar.

Checkmk bezeichnet jeden Host der nicht UP und jeden Service, der nicht OK ist, als ein Problem. Dabei kann ein Problem zwei Zustände haben: unbehandelt (unhandled) und bearbeitet (handled). Der Ablauf ist so, dass ein neues Problem zunächst als unbehandelt gilt. Sobald jemand das Problem im Monitoring bestätigt (quittiert, acknowledge), gilt es als bearbeitet. Man könnte auch sagen, dass die unbehandelten Probleme solche sind, um die sich noch niemand gekümmert hat. Der Overview in der Seitenleiste unterscheidet deswegen diese beiden Arten von Problemen:

Übrigens: Service-Probleme von Hosts, die gerade nicht UP sind, werden hier nicht als Problem angezeigt.

Weitere Details zu den Quittierungen finden Sie in einem eigenen Artikel.

Wann immer sich der Zustand eines Hosts oder Services ändert (z.B. von OK auf CRIT), spricht Checkmk von einem Monitoring-Ereignis. So ein Ereignis kann — muss aber nicht — zu einer Benachrichtigung führen. Checkmk ist so voreingestellt, dass im Falle eines Problems von einem Host oder Service jeder Kontakt dieses Objekts per E-Mail benachrichtigt wird (bitte beachten Sie hierbei, dass der Benutzer cmkadmin erst einmal kein Kontakt von irgendeinem Objekt ist). Dies kann aber sehr flexibel angepasst werden. Auch hängen die Benachrichtigungen von einigen Rahmenbedingungen ab. Am einfachsten ist es, wenn wir uns ansehen, in welchen Fällen nicht benachrichtigt wird. Benachrichtigungen werden unterdrückt, wenn:

Wenn keine dieser Bedingungen für eine Unterdrückung erfüllt ist, erzeugt der Monitoring-Kern eine Benachrichtigung, welche dann im zweiten Schritt eine Kette von Regeln durchläuft. Dort können Sie dann noch weitere Ausschlusskriterien festlegen und entscheiden, wer auf welchem Wege benachrichtigt werden soll (E-Mail, SMS etc.).

Alle Einzelheiten rund um die Benachrichtigungen finden Sie in einem eigenen Artikel.

Manchmal kommt es vor, dass sich der Zustand von einem Service in kurzen Abständen immer wieder ändert. Um ständige Benachrichtigungen zu vermeiden, schaltet Checkmk so einen Service in den Zustand „unstetig“ (flapping). Dies wird durch das Symbol illustriert. Wenn ein Service in diesen Flapping-Zustand eintritt, wird eine Benachrichtigung generiert. Diese informiert, dass eben dieser Zustand eingetreten ist, und danach ist Ruhe. Wenn für eine angemessene Zeit kein weiterer Zustandswechsel geschieht — sich also alles beruhigt und endgültig zum Guten oder zum Schlechten gewendet hat — verschwindet dieser Zustand wieder und die normalen Benachrichtigungen setzen wieder ein.

Wenn Sie an einem Server, Gerät oder an einer Software Wartungsarbeiten vornehmen möchten, möchten Sie in der Regel Benachrichtigungen über eventuelle Probleme in dieser Zeit vermeiden. Außerdem möchten Sie Ihren Kollegen eventuell signalisieren, dass Probleme, die das Monitoring anzeigt, vorübergehend ignoriert werden sollen.

Zu diesem Zweck können Sie zu einem Host oder Service Wartungszeiten (scheduled downtimes) eintragen. Diese können Sie entweder direkt beim Beginn der Arbeiten oder auch schon im Vorfeld eintragen. Wartungszeiten werden durch Symbole illustriert:

Während ein Host oder Service in Wartungszeit ist,

Auch wenn Sie später Auswertungen über die Verfügbarkeit von Hosts oder Services machen möchten, ist es eine gute Idee Wartungszeiten einzutragen. Diese können dann später bei der Berechnung berücksichtigt werden.

Wenn Sie eine Weile mit Checkmk gearbeitet haben, kann es passieren, dass in Ihren Host- und Service-Ansichten Spinnennetze angezeigt werden. Für Services sieht das dann zum Beispiel so aus:

Diese Spinnennetze symbolisieren den Zustand veraltet (stale). Sobald es einen veralteten Host oder Service gibt, wird das auch im Snapin Overview angezeigt, das um die Spalte Stale erweitert wird.

Doch was bedeutet der Zustand stale genau? Generell wird ein Host oder Service als stale gekennzeichnet, wenn Checkmk über eine längere Zeitdauer keine aktuellen Informationen über dessen Zustand mehr bekommt:

Sie können den Zeitraum anpassen, ab wann Hosts und Services stale werden. Lesen Sie hierzu den Abschnitt über Check-Intervalle.

Sie können die Zeiträume einschränken, in denen Checks ausgeführt werden. Dazu dienen die Regelsätze Check period for hosts, Check period for active services und Check period for passive Checkmk services. Mit diesen Regeln wählen Sie einen der verfügbaren Zeiträume (time periods) als Check-Zeitraum (check period) aus.

Das Ausführen von Checks geschieht beim zustandsbasierten Monitoring in festen Intervallen. Checkmk verwendet als Standard für Service-Checks eine Minute, für Host-Checks mit Smart Ping 6 Sekunden.

Mit Hilfe der Regelsätze Normal check interval for service checks und Normal check interval for host checks kann dies geändert werden:

Kombinieren Sie nun einen Check-Zeitraum mit einem Check-Intervall, so können Sie dafür sorgen, dass ein aktiver Check genau einmal am Tag zu einer ganz bestimmten Zeit ausgeführt wird. Setzen Sie z.B. das Check-Intervall auf 24 Stunden und den Check-Zeitraum auf 2:00 bis 2:01 Uhr an jedem Tag (also nur eine Minute pro Tag), dann wird Checkmk dafür sorgen, dass der Check auch wirklich in dieses kurze Zeitfenster verschoben wird.

Der Zustand der Services wird außerhalb des festgelegten Check-Zeitraums nicht mehr aktualisiert und die Services werden dann mit dem Symbol als veraltet (stale) gekennzeichnet. Mit der globalen Einstellung Staleness value to mark hosts / services stale können Sie definieren, wie viel Zeit vergehen soll, bis ein Host/Service auf stale geht. Diese Einstellung finden Sie unter Setup > General > Global settings > User interface:

Dieser Faktor stellt das n-fache des Check-Intervalls dar. Ist also Ihr Check-Intervall auf eine Minute (60 Sekunden) eingestellt, so geht ein Service, für den es keine neuen Check-Ergebnisse gibt, nach der 1,5-fachen Zeit, somit nach 90 Sekunden, auf stale.

Mit Hilfe der Check-Versuche (check attempts) können Sie Benachrichtigungen bei sporadischen Fehlern vermeiden. Sie machen einen Check damit quasi weniger sensibel. Dazu können Sie die Regelsätze Maximum number of check attempts for host und Maximum number of check attempts for service nutzen.

Sind die Check-Versuche z.B. auf 3 eingestellt, und der entsprechende Service wird CRIT, dann wird zunächst noch keine Benachrichtigung ausgelöst. Erst wenn auch die nächsten beiden Checks ein Resultat liefern, das nicht OK ist, steigt die Nummer des aktuellen Versuchs auf 3 und die Benachrichtigung wird versendet.

Ein Service, der sich in diesem Zwischenzustand befindet — also nicht OK ist, aber die maximalen Anzahl der Check-Versuche noch nicht erreicht hat — hat einen „weichen Zustand“ (soft state). Nur ein „harter Zustand“ (hard state) löst eine Benachrichtigung aus.