Grundlagen des Monitorings mit Checkmk

Bisher haben wir uns damit befasst, wie man Checkmk installiert und in Betrieb nimmt. Nun ist es an der Zeit, die grundlegenden Konzepte und Begriffe des Monitorings (mit Checkmk) zu erläutern.

Zunächst ist es wichtig, die grundlegenden Unterschiede zwischen Zuständen und Ereignissen zu verstehen — und zwar aus ganz praktischem Nutzen. Die meisten klassischen IT-Monitoring-Systeme drehen sich um Ereignisse (Events). Ein Ereignis ist etwas zu einem ganz bestimmten Zeitpunkt einmalig Geschehenes. Ein gutes Beispiel wäre Fehler beim Zugriff auf Platte X. Übliche Quellen von Ereignissen sind Syslog-Meldungen, SNMP-Traps, das Windows-Event-Log und Einträge in Logdateien. Ereignisse passieren quasi spontan (von selbst, asynchron).

Dagegen beschreibt ein Zustand eine anhaltende Situation, z.B. Platte X ist online. Um den aktuellen Zustand von etwas zu überwachen, muss das Monitoring-System diesen regelmäßig abfragen. Wie das Beispiel zeigt, gibt es beim Monitoring oft die Wahl, ob man mit Ereignissen oder mit Zuständen arbeitet.

Checkmk beherrscht beide Disziplinen, gibt jedoch immer dort, wo die Wahl besteht, dem zustandsbasierten Monitoring den Vorzug. Der Grund liegt in den zahlreichen Vorteilen dieser Methode. Einige davon sind:

Man kann also sagen, dass das zustandsbasierte Monitoring bei Checkmk das normale ist. Für das Verarbeiten von Ereignissen gibt es daneben die Checkmk Event Console. Diese ist auf das Korrelieren und Bewerten von großen Mengen an Events spezialisiert und nahtlos in das Monitoring integriert.

Hosts und Services können zur Übersicht gruppiert werden. Dabei kann ein Host/Service auch in mehreren Gruppen sein. Diese Gruppen sind rein optional und für die Konfiguration nicht notwendig. Hostgruppen können nützlich sein, wenn Sie eine zusätzliche Gruppierung quer zu der Ordnerstruktur wünschen, in der Sie die Hosts verwalten. Haben Sie die Ordnerstruktur z.B. nach geographischen Gesichtspunkten aufgebaut, dann kann eine Hostgruppe Linux-Server sinnvoll sein, die alle Linux-Server zusammenfasst, egal an welchen Standorten diese stehen.

Kontakte und Kontaktgruppen bieten die Möglichkeit, Hosts und Services Personen zuzuordnen. Ein Kontakt entspricht einer Benutzerkennung der Weboberfläche. Die Zuordnung zu Hosts und Services geschieht jedoch nicht direkt, sondern über Kontaktgruppen. Zunächst wird ein Kontakt (z.B. harri) einer Kontaktgruppe (z.B. linux-admins) zugeordnet. Der Kontaktgruppe werden dann wieder Hosts oder nach Bedarf auch einzelne Services zugeordnet. Dabei können sowohl Benutzer als auch Hosts und Services jeweils mehreren Kontaktgruppen zugeordnet sein.

Diese Zuordnung ist für mehrere Aspekte nützlich:

Der Benutzer cmkadmin, der beim Erzeugen einer Instanz automatisch angelegt wird, darf übrigens immer alle Hosts und Services sehen, auch wenn er kein Kontakt ist. Dies ist durch seine Rolle als Administrator bedingt.

Während über Kontakte und Kontaktgruppen gesteuert wird, welche Personen für einen bestimmten Host oder Service zuständig oder berechtigt sind, werden die Privilegien über Rollen gesteuert. Checkmk wird dabei mit drei Rollen ausgeliefert, von denen Sie später weitere Rollen ableiten können. Jede Rolle definiert eine Reihe von Rechten, welche Sie anpassen können. Die Bedeutung der Standardrollen sind:

Zeitperioden definieren regelmäßig wöchentlich wiederkehrende Zeitbereiche, die an verschiedenen Stellen in der Konfiguration des Monitorings zum Einsatz kommen. Eine typische Zeitperiode könnte workhours heißen und die Zeiten von jeweils 8:00 bis 17:00 Uhr beinhalten, an allen Wochentagen außer Samstag und Sonntag. Vordefiniert ist die Periode 24X7, welche einfach alle Zeiten einschließt. Zeitperioden können auch Ausnahmen für bestimmte Kalendertage enthalten — z.B. für die bayerischen Feiertage.

Einige wichtige Stellen, an denen Zeitperioden zum Einsatz kommen, sind:

Das Ausführen von Checks geschieht beim zustandsbasierten Monitoring in festen Intervallen. Checkmk verwendet als Standard eine Minute. Jeder Check wird also einmal pro Minute ausgeführt. Per Konfiguration kann dies geändert werden:

Durch Definition einer anderen Checkperiode als 24X7 kann das Ausführen von aktiven Checks in bestimmten Zeitfenstern unterbrochen werden. Der Zustand der Services wird dann nicht mehr aktualisiert und diese werden als veraltet angezeigt (stale), symbolisiert durch .

In Kombination mit einem großen Checkintervall kann man dafür sorgen, dass ein aktiver Check einmal am Tag zu einer ganz bestimmten Zeit ausgeführt wird. Setzen Sie z.B. das Intervall auf 24 Stunden und die Checkperiode auf den Zeitraum 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.

Mit Hilfe der Checkversuche (max check attempts) können Sie Benachrichtigungen bei sporadischen Fehlern vermeiden. Sie machen einen Check damit quasi weniger sensibel. Sind die Checkversuche 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 Versuche noch nicht erreicht hat — hat einen weichen Zustand (soft state).

Wenn Sie auf die Checkmk-Oberfläche schauen, werden Sie sehen, dass bei einigen Services im Menü ein gelber Pfeil steht (), bei den meisten anderen aber ein grauer Pfeil (). Die Services mit dem gelben Pfeil sind aktive Checks. Diese werden von Checkmk direkt ausgeführt. Services mit dem grauen Pfeil sind solche, bei denen die Checkergebnisse von dem aktiven Check Checkmk ermittelt werden. Dies geschieht aus Gründen der Performance und stellt eine Besonderheit von Checkmk dar:

Damit das Zielsystem (Server, Netzwerkgerät, etc.) nicht für jeden einzelnen Service aufs Neue kontaktiert werden muss, holt Checkmk einmal pro Intervall alle wichtigen Daten in einem Rutsch und berechnet daraus die neuen Resultate für alle passiven Checks auf einmal. Das schont CPU-Ressourcen auf beiden Systemen und ist ein wichtiger Grund für die hohe Performance und gute Skalierbarkeit von Checkmk.

Folgende Tabelle gibt eine kurze Übersicht der wichtigsten Icons, die Sie als Status neben Hosts und Services finden: