Grundlagen des Monitorings mit Check_MK


Bisher haben wir uns damit befasst, wie man Check_MK installieren und in Betrieb nehmen kann. Nun ist es an der Zeit, zunächst einmal die grundlegenden Konzepte und Begriffe des Monitorings (mit Check_MK) zu erläutern, bevor wir in die technischen Details abtauchen. Unter anderem wird es in diesem Artikel um Zustände, Ereignisse, Alarme, Benachrichtigungen, Wartungszeiten, Quittierungen, Hosts, Services, Checks und vieles mehr gehen.

Check_MK hat den grundsätzlichen Aufbau von Nagios übernommen und ist zu Nagios in vielen Dingen kompatibel. Die  Check_MK Raw Edition baut nach wie vor auf den bewährten Nagios-Kern auf. Die  Check_MK Enterprise Edition verwendet stattdessen einen eigenen, komplett neu entwickelten Kern: den Check_MK Micro Core. Sie kann aber auch auf Nagios umgestellt werden. Dieses Handbuch verlangt jedoch keine Vorkenntnisse über Nagios oder verwandte Systeme.

1. Zustände und Ereignisse

Es ist 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 SCSI Timeout 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 sponantan (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.

Das Check_MK Monitoring System 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.
  • Das regelmäßige Abfragen in einem festen Zeitraster ermöglicht das Erfassen von Leistungsdaten.
  • Das Monitoring kann selbst steuern, mit welcher Rate Zustände abgerufen werden. Es gibt keine Gefahr eines Sturms an Event-Meldungen in systemweiten Problemsituationen.
  • 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 Check_MK das normale ist. Für das Verarbeiten von Ereignissen gibt es daneben die Check_MK 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. Den 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

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

Zustand Farbe ID Bedeutung
UP grün 0 Der Host ist über das Netzwerk erreichbar (in der Regel heißt das, dass er auf PING antwortet).
DOWN rot 1 Der Host antwortet nicht auf Anfragen aus dem Netzwerk, ist nicht erreichbar.
UNREACH orange 2 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 dem Monitoring-Server in der Mitte (hier dargestellt als ):

Wenn in diesem Beispiel also der Host switch-intern den Zustand DOWN annimmt, dann geht das Monitoring automatisch davon aus, dass ein eventueller Ausfalls von tauschzone.de 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. Aber: die Überwachung von tauschzone.de findet dann trotzdem noch statt! Sollte dieser Host antworten, wird er auf jeden Fall als UP dargestellt.

Die wichtigste Aufgabe der Parents ist die Erkennung von Netzwerkausfällen und die Vermeidung von massenhaften Fehlalarmen in solchen Situationen.

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 ID Bedeutung
OK grün 0 Der Service ist vollständig in Ordnung. Alle Messwerte liegen im erlaubten Bereich.
WARN gelb 1 Der Service funktioniert normal, aber seine Parameter liegen außerhalb des optimalen Bereichs.
CRIT rot 2 Der Service ist ausgefallen, defekt.
UNKNOWN orange 3 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 Check_MK 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 omdadmin (bzw. cmkadmin ab 1.4.0), 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. Check_MK 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, Alarme und Benachrichtigungen

6.1. Behandelte und unbehandelte Probleme

Check_MK 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 dich 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 Check_MK von einem Alarm (Alert). So ein Alarm kann – muss aber nicht – zu einer Benachrichtigung führen. Check_MK 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 omdadmin/cmkadmin erstmal kein Kontakt von irgendeinem Objekt ist). Dies kann aber sehr flexibel angepasst werden. Auch hängt eine Alarmierung von einigen Rahmenbedingungen ab. Am einfachsten ist es, wenn wir uns ansehen, in welchen Fällen nicht benachrichtigt wird. Benachrichtigungen werden unterdrückt, wenn:

  • Benachrichtigungen global in der Master Control ausgeschaltet wurden;
  • Benachrichtigungen bei dem Host/Service ausgeschaltet wurden;
  • der jeweilige Zustand bei dem Host/Service für Benachrichtigungen 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 Benachrichtigungs-Periode (notification period) gesetzt 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 aber im zweiten Schritte eine Kette von 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 Benachrichtigungen zu vermeiden, schaltet Check_MK 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 Benachrichtigungen ü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 Benachrichtigungen 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 benachrichtigt wird (Benachrichtigungsperiode, 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. Check_MK 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 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 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 Check_MK dafür sorgen, dass der Check auch wirklich in dieses kurze Zeitfenster verschoben wird.

Mithilfe 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 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, aber die maximalen Versuche noch nicht erreicht – hat einen weichen Zustand (soft state).

9. Passive Checks

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

Damit das Zielsystem (Server, Netzwerkgerät, etc.) nicht für jeden einzelnen Service aufs Neue kontaktiert werden muss, holt Check_MK 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 Check_MK.

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:

Ein Klick auf dieses Icon führt sofort einen Check dieses Services aus.
Ein Klick führt einen Check aus, indirekt durch Anstoßen des Check_MK-Services.
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.
Hier gelangen Sie zür Übersicht über das selbstanpassende Monitoring (predictive Monitoring).
Dieser Host besitzt HW/SW-Inventurdaten. Ein Klickt bringt Sie zu deren Ansicht.
Dieser Host/Service gehört zu Ihren Favoriten.