Verfügbarkeit (Availability)

Da Checkmk alle Hosts und Services in regelmäßigen Intervallen kontinuierlich überwacht, schafft es damit eine hervorragende Grundlage für spätere Auswertungen über deren Verfügbarkeit. Und nicht nur das — Sie können berechnen lassen, welchen Anteil der Zeit ein Objekt in einem bestimmten Zustand war, wie oft dieser Zustand aufgetreten ist, wie lange er am längsten angehalten hat und vieles mehr.

Jeder Berechnung liegen dabei eine Auswahl von Objekten und ein bestimmter Zeitraum der Vergangenheit zugrunde. Checkmk rekonstruiert dann für diesen Zeitraum den Verlauf des Zustands für jedes der ausgewählten Objekte. Pro Zustand werden die Zeiten aufsummiert und in einer Tabelle dargestellt. Das Ergebnis kann dann z.B. sein, dass der Zustand eines bestimmten Services zu 99,95 % OK war und zu 0,005 % WARN.

Dabei rechnet Checkmk auch Dinge wie Wartungszeiten, Service-Zeiten, nicht überwachte Zeiträume und andere Besonderheiten korrekt ab, erlaubt das Zusammenfassen von Zuständen, das Ignorieren von „kurzen Aussetzern“ und noch etliche weitere Anpassungsmöglichkeiten. Auch eine Verfügbarkeit von BI-Aggregaten ist möglich.

Durch die Einbeziehung von Wartungszeiten und ähnlichen Sonderzuständen gibt es theoretisch eine sehr große Zahl von möglichen Zustandskombinationen, wie z.B. CRIT + In Wartungszeit + In der Service-Zeit + Flapping. Da die meisten dieser Kombinationen nicht sehr nützlich sind, reduziert Checkmk sie auf eine kleine Zahl und geht dabei nach einem Prinzip von Prioritäten vor. Da in obigem Beispiel der Service in einer Wartungszeit war, gilt als Zustand einfach in scheduled downtime und der eigentliche Zustand wird ignoriert. Das reduziert die Anzahl der möglichen Zustände auf die Folgenden:

Diese Grafik zeigt auch die Reihenfolge, nach der Zustände priorisiert werden. Später werden wir zeigen, wie Sie manche der Zustände ignorieren oder zusammenfassen können. Hier die Zustände noch einmal im Detail:

Das Erstellen einer Verfügbarkeitsauswertung ist sehr einfach. Rufen Sie zunächst eine beliebige Ansicht von Hosts, Services oder BI-Aggregaten auf. Dort finden Sie im Menü Services bzw. Hosts den Eintrag Availability, welcher Sie direkt zur Berechnung der Verfügbarkeit der ausgewählten Objekte bringt. Diese wird tabellarisch angezeigt:

Die Tabelle zeigt die gleichen Objekte, die auch in der vorherigen Ansicht sichtbar waren. In jeder Spalte wird dargestellt, welchen Anteil des Abfragezeitraums das Objekt im besagten Zustand war. Die Darstellung ist per Default in Prozent mit zwei Kommastellen, aber das können Sie leicht umstellen.

Den Anfragezeitraum können Sie mit dem Menüeintrag Availability > Change display options > Time Range ändern. Dazu weiter unten mehr  …​

Sie haben die Möglichkeit, die Ansicht als PDF zu exportieren (nur kommerzielle Editionen). Auch ein Download der Daten in CSV-Format ist möglich (Export as CSV). Das sieht dann für obiges Beispiel so aus:

Mithilfe eines Automationsbenutzers, der sich über die URL authentifizieren kann, können Sie so die Daten auch skriptgesteuert abrufen (z.B. mit wget oder curl) und automatisiert verarbeiten.

In jeder Zeile finden Sie das Symbol . Dies bringt Sie zu einer Zeitleistendarstellung des entsprechenden Objekts, in der genau aufgeschlüsselt ist, welche Zustandswechsel es im Anfragezeitraum gab (hier gekürzt):

Dazu einige Hinweise:

Wie gerade erwähnt, bietet die Zeitleiste über das Symbol die Möglichkeit, für einen Zeitabschnitt eine Anmerkung zu hinterlegen. Dahinter finden Sie ein bereits ausgefülltes Formular, in dem Sie einen Kommentar eingeben können:

Dabei können Sie den Zeitraum auch anders festlegen und erweitern. Das ist z.B. praktisch, wenn Sie einen größeren Abschnitt annotieren möchten, der mehrere Zustandswechsel erlebt hat. Wenn Sie die Angabe eines Services weglassen, erzeugen Sie eine Anmerkung für einen Host. Diese bezieht sich automatisch auch auf alle Services des Hosts.

In jeder Verfügbarkeitsansicht werden automatisch alle Anmerkungen sichtbar, die zum Zeitraum und den Objekten passen, die dargestellt werden.

Aber Annotationen haben noch eine weitere Funktion: Sie können damit nachträglich Wartungszeiten eintragen oder umgekehrt auch entfernen. Die Verfügbarkeitsberechnung berücksichtigt diese Korrekturen wie ganz normale Wartungszeiten. Es gibt für so etwas mindestens zwei legitime Gründe:

Zum Umklassifizieren von Wartungszeiten wählen Sie einfach die Checkbox Reclassify downtime of this period:

In der Verfügbarkeitstabelle finden Sie neben dem Symbol für die Zeitleiste noch ein weiteres Symbol: . Dieses bringt Sie zur Ansicht der Monitoring-Historie mit einem bereits ausgefüllten Filter für das entsprechende Objekt und den Anfragezeitraum. Dort sehen Sie nicht nur die Ereignisse, auf denen die Verfügbarkeitsberechnung basiert (die Zustandswechsel), sondern auch die zugehörigen Benachrichtigungen und ähnliche Ereignisse:

Was Sie hier nicht sehen, ist der Zustand des Objekts am Anfang des Abfragezeitraums. Die Berechnung der Verfügbarkeit geht dazu noch weiter in die Vergangenheit zurück, um den Anfangszustand zuverlässig zu ermitteln.

Viele Optionen betreffen die Art, wie die Daten präsentiert werden, andere wiederum beeinflussen die Berechnungsmethode. Zunächst ein Blick auf die Darstellung:

Die in der Einleitung beschriebenen Zustände können auf verschiedenste Arten angepasst und verdichtet werden. Auf diese Weise werden flexibel sehr unterschiedliche Arten von Auswertungen erstellt. Dafür gibt es verschiedene Optionen.

Manchmal werden Sie Überwachungen haben, die oft kurzzeitig ein Problem melden, das aber im Normalfall beim nächsten Check (nach einer Minute) schon wieder OK ist. Und Sie finden keinen Weg durch Anpassen von Schwellwerten oder Ähnlichem, das sauber in den Griff bekommen. Eine häufige Lösung ist dann das Setzen der Maximum number of check attempts von 1 auf 3, um mehrere Fehlversuche zu erlauben, bevor eine Benachrichtigung stattfindet. Dadurch ergibt sich das Konzept von Soft states — die Zustände WARN, CRIT und UNKNOWN vor Ablauf aller Versuche.

Von Anwendern, die dieses Feature einsetzen, werden wir gelegentlich gefragt, warum das Availability-Modul von Checkmk keine Funktion hat, um für die Berechnung nur Hard states zu verwenden. Der Grund ist: Es gibt eine bessere Lösung! Denn würde man die Hard states als Grundlage nehmen,

Die Option Short time Intervals ist viel flexibler und gleichzeitig sehr einfach. Sie legen schlicht eine Zeitdauer fest, unterhalb derer Zustände nicht gewertet werden.

Nehmen Sie an, Sie setzen den Wert auf 2,5 Minuten (150 Sekunden). Ist nun ein Service die ganze Zeit auf OK, geht dann 2 Minuten lang auf CRIT und dann wieder auf OK, so wird das kurze CRIT-Intervall einfach als OK gewertet! Das gilt allerdings auch umgekehrt! Ein kurzes OK innerhalb einer langen WARN-Phase wird dann ebenfalls als WARN gewertet.

Allgemein gesagt, werden kurze Abschnitte, bei denen vorher und nachher der gleiche Zustand herrscht, mit diesem gleichgesetzt. Bei einer Abfolge OK, dann 2 Minuten WARN, dann CRIT, bleibt das WARN bestehen, auch wenn dessen Dauer unterhalb der eingestellten Zeit liegt!

Bedenken Sie beim Festlegen der Zeit das bei Checkmk übliche Check-Intervall von einer Minute. Dadurch dauert jeder Zustand etwa das Vielfache einer Minute. Da die Antwortzeiten der Agenten leicht schwanken, können das auch leicht mal 61 oder 59 Sekunden sein. Daher ist es sicherer, wenn Sie als Wert keine ganze Minutenzahl eintragen, sondern einen Puffer einbauen (daher das Beispiel mit den 2,5 Minuten).

Eine wichtige Funktion der Verfügbarkeitsberechnung von Checkmk ist, dass Sie diese von Zeitperioden abhängig machen können. Damit können Sie für jeden Host oder Service individuelle Zeiten definieren. In diesen Zeiten wird der Host/Service als verfügbar erwartet und der Zustand dann zur Auswertung genutzt. Dafür hat jedes Objekt das Attribut Service period. Das Vorgehen ist wie folgt:

Hier gibt es drei einfache Möglichkeiten. Der Default Base report only on service times blendet die Zeiten außerhalb der definierten Service-Zeit komplett aus. Diese zählen damit auch nicht zu den 100 Prozent. Es werden nur die Zeiträume innerhalb der Service-Zeiten betrachtet. In der Zeitleistendarstellung sind die übrigen Zeiten grau dargestellt.

Base report only on none-service times macht das Gegenteil und berechnet quasi die inverse Darstellung: Wie gut war die Verfügbarkeit außerhalb der Service-Zeiten?

Und die dritte Option Include both service and non-service times deaktiviert das ganze Konzept der Service-Zeiten und zeigt die Auswertungen wieder für alle Zeiten von Montag bis Sonntag und 00:00 Uhr bis 24:00 Uhr.

Übrigens: Wenn ein Host nicht in der Service-Zeit ist, heißt das für Checkmk nicht automatisch, dass das auch für die Services auf dem Host gilt. Sie benötigen für Services immer eine eigene Regel in Service period for services.

Bei der Berechnung der Verfügbarkeit muss die komplette Vergangenheit der gewählten Objekte aufgerollt werden. Wie das im einzelnen geht, erfahren Sie weiter unten. Vor allem in Checkmk Raw kann die Auswertung etwas Zeit beanspruchen, da dessen Kern keinen Cache für die benötigten Daten hat und die textbasierten Logdateien durchsucht werden müssen.

Damit eine allzu komplexe Anfrage — die eventuell aus Versehen aufgerufen wurden — nicht über sehr lange Zeit einen Apache-Prozess lahmlegt, die CPU übermäßig strapaziert und dabei „hängt“, gibt es zwei Optionen, welche die Dauer der Berechnung begrenzen. Beide sind per Default aktiviert:

Das Query time limit begrenzt die Dauer der zugrundeliegenden Abfrage an den Monitoring-Kern auf eine bestimmte Zeit. Diese ist auf eine halbe Minute voreingestellt. Wird diese überschritten, wird die Auswertung abgebrochen und ein Fehler angezeigt. Wenn Sie sicher sind, dass die Auswertung länger dauern darf, können Sie dieses Timeout einfach hochsetzen.

Die Option Limit processed data schützt Sie vor Auswertungen mit zu vielen Objekten. Hier wird ein Limit eingezogen, das analog zu dem in den Ansichten funktioniert. Wenn die Anfrage an den Monitoring-Kern mehr als 5000 Zeitabschnitte liefern würde, wird die Berechnung mit einer Warnung abgebrochen. Die Limitierung wird bereits im Kern durchgeführt — do wo die Daten beschafft werden.

Ein starkes Feature der Verfügbarkeitsberechnung von Checkmk ist die Möglichkeit, die Verfügbarkeit von BI-Aggregaten zu berechnen. Ein Alleinstellungsmerkmal dabei ist, dass Checkmk dazu nachträglich anhand des Verlaufs der einzelnen Zustände von Hosts und Services Schritt für Schritt rekonstruiert, wie der Zustand des jeweiligen Aggregats zu einem bestimmte Zeitpunkt genau war.

Warum der ganze Aufwand? Warum nicht einfach das BI-Aggregat mit einem aktiven Check abfragen und dann dessen Verfügbarkeit anzeigen? Nun, der Aufwand hat für Sie eine ganze Menge Vorteile:

Das Aufrufen der Verfügbarkeitsansicht geht erst einmal analog zu den Hosts und Services. Sie wählen eine Ansicht mit einem oder mehreren BI-Aggregaten und wählen den Menüeintrag BI Aggregations > Availability aus. Es gibt aber hier noch einen zweiten Weg: Jedes BI-Aggregat hat über das Symbol einen direkten Weg zu dessen Verfügbarkeit:

Die Auswertung an sich ist erst einmal analog zu der bei Services — allerdings ohne die Spalten Host down und flapping, da es diese Zustände bei BI nicht gibt:

Der große Unterschied kommt in der Zeitleistenansicht. Folgendes Beispiel zeigt ein Aggregat von unserem Demoserver, welches für einen sehr kurzen Abschnitt von gerade mal einer Sekunde CRIT war (das wäre eines gutes Beispiel für die Option Short time intervals).

Wollen Sie wissen, was hier der Grund für den Ausfall war? Ein einfacher Klick auf den Zauberstab genügt. Er ermöglicht eine Zeitreise zu genau dem Zeitpunkt, an dem der Ausfall auftrat und öffnet eine Darstellung des BI-Aggregats zu jenem Zeitpunkt — in der folgenden Abbildung bereits an der richtigen Stelle aufgeklappt:

Zur Berechnung der Verfügbarkeit greift Checkmk auf die Monitoring-Historie zurück. Es orientiert sich dabei an den Zustandswechseln. Wenn ein Service z.B. am 20.10.2021 um 17:14 Uhr auf CRIT geht und um 17:24 Uhr wieder auf OK, dann wissen Sie, dass er während dieser Zeitspanne 10 Minuten den Zustand CRIT hatte.

Diese Zustandswechsel sind in Form von Einträgen im Monitoring-Log enthalten, haben den Typ HOST ALERT oder SERVICE ALERT und sehen z.B. so aus:

Dabei gibt es immer eine aktuelle Logdatei, die die Einträge der letzten Stunden oder Tage beinhaltet und ein Verzeichnis mit einem Archiv der früheren Zeiträume. Der Ort ist je nach verwendetem Monitoring-Kern unterschiedlich:

Dabei greift die Benutzeroberfläche nicht direkt auf diese Dateien zu, sondern fragt sie mittels einer Livestatus-Abfrage vom Monitoring-Kern ab. Das ist unter anderem wichtig, weil in einem verteilten Monitoring die Dateien mit der Historie gar nicht auf dem gleichen System liegen wie die GUI.

Die Livestatus-Abfrage benutzt dabei die Tabelle statehist. Im Gegensatz zur Tabelle log, welche einen „nackten“ Zugriff auf die Historie bietet, wird hier die Tabelle statehist verwendet, weil sie bereits erste aufwendige Berechnungsschritte durchführt. Sie übernimmt unter anderem das Zurücklaufen in die Vergangenheit zur Ermittlung des Anfangszustands und das Berechnen von Zeitabschnitten gleichen Zustands mit Anfang, Ende und Dauer.

Das Verdichten der Zustände nach dem am Anfang beschriebenen Schema macht dann das Verfügbarkeitsmodul in der Benutzeroberfläche.