Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Die Checkmk-Konferenz #6 steht an! Regulärer Verkauf endet in . Tickets hier!

Grundlagen des Monitorings mit Checkmk

1. Zustände und Ereignisse

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, wie die Wahl besteht, dem zustandsbasierten Monitoring den Vorzug. Der Grund liegt in den zahlreichen Vorteilen dieser Methode. Einige davon sind:

  • Ein Fehler in der Überwachung selbst wird sofort erkannt, weil es natürlich auffällt, wenn das Abfragen des Zustands nicht mehr funktioniert. Das Nichtauftreten einer Meldung dagegen gibt keine Sicherheit, ob das Monitoring noch funktioniert.
  • Das Monitoring kann selbst steuern, mit welcher Rate Zustände abgerufen werden. Es gibt keine Gefahr eines Sturms an Event-Meldungen in systemweiten Problemsituationen.
  • Das regelmäßige Abfragen in einem festen Zeitraster ermöglicht das Erfassen von Metriken, um deren Zeitverlauf aufzuzeichnen.
  • Auch nach chaotischen Situationen – z. B. Stomausfall im RZ – hat man immer einen zuverlässigen Gesamtzustand.

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 von Events spezialisiert und nahtlos in das Monitoring integriert.

2. Hosts und Services

2.1. Hosts

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

  • Ein Server
  • Ein Netzwerkgerät (Switch, Router, Loadbalancer)
  • Ein Messgerät mit IP-Anschluss (Thermomether, Luftfeuchtesensor)
  • Irgendetwas anderes mit einer IP-Adresse
  • Ein Cluster aus mehreren Hosts
  • Eine virtuelle Maschine
  • Ein Docker-Container

Im Monitoring hat ein Host immer einen von folgenden Zuständen:

Zustand Farbe Bedeutung
UP grün Der Host ist über das Netzwerk erreichbar (in der Regel heißt das, dass er auf PING antwortet).
DOWN rot Der Host antwortet nicht auf Anfragen aus dem Netzwerk, ist nicht erreichbar.
UNREACH orange Der Weg zu dem Host ist aktuell für das Monitoring versperrt, weil ein Router oder Switch auf dem Weg dorthin ausgefallen ist.
PEND grau Der Host wurde frisch in die Überwachung aufgenommen und noch nie abgefragt. Genau genommen ist das aber kein Zustand.

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

  • Einen eindeutigen Namen
  • Eine IP-Adresse
  • Optional einen Alias-Namen, welcher nicht eindeutig sein muss
  • Optional einen oder mehrere Parents

2.2. Parents

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

Wenn in diesem Beispiel also der Host sw-ks-01.lan.tribe29.com den Zustand DOWN annimmt, dann geht das Monitoring automatisch davon aus, dass ein eventueller Ausfall von sw-ks-02.lan.tribe29.com einfach damit erklärbar ist, dass dieser vom Monitoring nicht mehr erreicht werden kann. Ob er wirklich ebenfalls ausgefallen ist, ist damit nicht feststellbar. Er wird im Monitoring dann als UNREACH klassifiziert. Und es gilt die wichtige Regel, dass (per Default) zu Hosts mit dem Status UNREACH keine Alarmierung erfolgt. Denn das ist die wichtigste Aufgabe des Konzepts mit den Parents: Die Vermeidung von massenhaften Fehlalarmen, falls ein ganzes Netzwerksegment für das Monitoring nicht mehr erreichbar ist.

Übrigens: Die Überwachung von sw-ks-02.lan.tribe29.com findet trotzdem noch statt! Sollte dieser Host antworten, wird er auf jeden Fall als UP dargestellt.

2.3. Services

Ein Host hat eine Menge von Services. Ein Service kann alles Mögliche sein, bitte verwechseln Sie das nicht mit den 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:

Zustand Farbe Bedeutung
OK grün Der Service ist vollständig in Ordnung. Alle Messwerte liegen im erlaubten Bereich.
WARN gelb Der Service funktioniert normal, aber seine Parameter liegen außerhalb des optimalen Bereichs.
CRIT rot Der Service ist ausgefallen, defekt.
UNKNOWN orange Der Zustand des Services konnte nicht korrekt ermittelt werden. Der Monitoring-Agent hat fehlerhafte Daten geliefert oder die zu überwachende Sache ist ganz verschwunden.
PEND grau Der Service ist gerade in die Überwachung aufgenommen worden und es gibt noch keine Monitoring-Daten.

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

OKWARNUNKNOWNCRIT

3. Host- und Servicegruppen

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.

4. Kontakte und Kontaktgruppen

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:

  1. Wer darf was sehen?
  2. Wer darf welche Hosts und Services konfigurieren und steuern?
  3. Wer wird bei welchen Problemen benachrichtigt?

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.

5. Benutzer und Rollen

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:

Rolle Bedeutung
admin Darf alles sehen, hat alle Privilegien.
user Darf nur sehen, wofür er Kontakt ist. Darf Hosts verwalten in Ordnern, die ihm zugewiesen sind. Darf keine globalen Einstellungen machen.
guest Darf alles sehen, aber nichts konfigurieren und auch nicht in das Monitoring eingreifen.

6. Probleme, Ereignisse und Alarmierungen

6.1. Behandelte und unbehandelte Probleme

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 behandelt (handled). Der Ablauf ist so, dass ein neues Problem zunächst als unbehandelt gilt. Sobald jemand das Problem im Monitoring bestätigt (quittiert, acknowledged), gilt es als behandelt. Man könnte auch sagen, dass die unbehandelten Probleme solche sind, um die sich noch niemand gekümmert hat. Die taktische Übersicht 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.

6.2. Alarme und Benachrichtigungen

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

  • Alarme global in der Master Control ausgeschaltet wurden,
  • Alarme bei dem Host/Service ausgeschaltet wurden,
  • der jeweilige Zustand bei dem Host/Service für Alarmierung abgeschaltet ist (z. B. keine Benachrichtigung bei WARN),
  • das Problem einen Service betrifft, dessen Host DOWN oder UNREACH ist,
  • das Problem einen Host betrifft, dessen Parents alle DOWN oder UNREACH sind,
  • für den Host/Service eine Alarmierungsperiode (notification period) definiert wurde, die gerade nicht aktiv ist (siehe unten),
  • der Host/Service gerade unstetig (flapping) ist (siehe unten),
  • sich der Host/Service gerade in einer Wartungszeit (scheduled downtime) befindet (siehe unten).

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

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

6.3. Unstetige Hosts und Services (Flapping)

Manchmal kommt es vor, dass sich der Zustand von einem Service in kurzen Abständen immer wieder ändert. Um ständige Alarmierungen zu vermeiden, schaltet Checkmk so einen Service in den Zustand unstetig (flapping). Dies wird durch das Symbol illustriert. Jetzt wird ein letztes Mal eine Benachrichtigung erzeugt. 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 normale Alarmierung setzt wieder ein.

6.4. Wartungszeiten (Scheduled Downtimes)

Wenn Sie an einem Server, Gerät oder an einer Software Wartungsarbeiten vornehmen möchten, möchten Sie in der Regeln Alarmierungen über eventuelle Probleme in dieser Zeit vermeiden. Außerdem möchten Sie Ihren Kollegen evtl. 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:

Der Host/Service befindet sich in einer Wartungszeit.
Der Host, auf dem sich der Service befindet, ist in einer Wartungszeit.

Während ein Host oder Service in Wartungszeit ist,

  • werden keine Alarme versendet,
  • werden Probleme nicht in der Tactical Overview angezeigt.

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.

7. Zeitperioden (Timeperiods)

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 Außnahmen für bestimmte Kalendertage enthalten – z. B. für die bayerischen Feiertage.

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

  • Begrenzung der Zeiten, innerhalb derer alarmiert wird (Alarmierungsperiode, notification period)
  • Begrenzung der Zeiten, innerhalb derer Checks ausgeführt werden (Checkperiode, check period)
  • Servicezeiten für die Berechnung von Verfügbarkeiten (Serviceperiode, service period)
  • Zeiten, innerhalb derer bestimmte Regeln in der Event Console greifen.

8. Checkintervall, Checkversuche und Checkperiode

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:

  • Auf einen längeren Wert, um CPU-Ressourcen auf Server und Zielsystem zu sparen
  • Auf einen kürzeren Wert, um schneller Alarme zu bekommen und Messdaten in einer höheren Auflösung einzusammeln

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 Alarmierungen 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 Alarmierung 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 Alarmierung 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).

9. Aktive und Passive Checks

Wenn Sie auf die Checkmk-Oberfläche schauen, werden Sie sehen, dass bei einigen Services im Menü ein oranger Doppelpfeil steht (), bei den meisten anderen aber ein grauer Vierfachpfeil (). Die Services mit dem orange 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.

10. Übersicht über die wichtigsten Host- und Service-Icons

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

Dieser Host/Service ist gerade in einer Wartungszeit.
Der Host dieses Services ist in einer Wartungszeit.
Dieser Host/Service ist gerade außerhalb seiner Benachrichtigungsperiode.
Benachrichtigungen für diesen Host/Service sind gerade abgeschaltet.
Checks dieses Services sind gerade abgeschaltet.
Der Zustand dieses Hosts/Services ist veraltet.
Der Zustand dieses Hosts/Services ist unstetig.
Dieser Host/Service hat ein Problem, das bestätigt wurde.
Zu diesem Host/Service gibt es einen Kommentar.
Dieser Host/Service ist Teil einer BI-Aggregation.
Hier gelangen Sie direkt zur Einstellung der Checkparameter.
Nur bei Logwatch-Services: Hier gelangen Sie zu den gespeicherten Logfiles.
Hier gelangen Sie zum Zeitverlauf der aufgezeichneten Messwerte.
Dieser Host besitzt HW/SW-Inventurdaten. Ein Klickt bringt Sie zu deren Ansicht.
Bei diesem Check ist ein Fehler aufgetreten. Über einen Klick können Sie einen Fehlerreport einsehen und absenden.