Falsch-positive Alarme mit Checkmk minimieren

Ein gutes IT-Monitoring steht und fällt mit seiner Präzision. Es muss das IT-Team genau dann benachrichtigen, wenn etwas fehlerhaft ist. Aber wie in der Statistik lassen sich auch bei der IT-Überwachung falsch-positive und falsch-negative Meldungen nicht vermeiden.

Ein Beispiel für einen falsch-positiven Alarm wäre, wenn das Monitoring-Tool ein Problem meldet, obwohl das überwachte System völlig in Ordnung ist. Es zeigt dann beispielsweise einen Server als “DOWN” an, weil es möglicherweise eine kurze Störung in der Netzwerkverbindung gab oder eine kurze Spitze in der genutzten Bandbreite eines Netzwerkgeräts auftrat, die wiederum einen kritischen Alarm auslöst – obwohl 5 Sekunden später wieder alles normal ist.

Falsch-negative Alarme liegen vor, wenn die Monitoring-Lösung keine Warnung versendet, obwohl tatsächlich etwas nicht in Ordnung ist. Wenn die Firewall ausgefallen ist, möchte das IT-Team dies sofort wissen. Schickt das Monitoring-Tool ihm aus irgendeinem Grund keine Benachrichtigung darüber, führt dies schnell zu Schwierigkeiten.

Wie in der Statistik lassen sich jedoch auch im IT-Monitoring Fehler nicht völlig ausschließen. Das Problem ist jedoch, dass beim Betrieb einer IT-Infrastruktur in einem Unternehmen die Kosten eines falsch-positiven oder falsch-negativen Alarms sehr unterschiedlich ausfallen können. Ein falsch-negativer Alarm kann bedeuten, dass ein geschäftskritisches System nicht funktioniert und keinen Alarm auslöst, während eine falsch-positive Benachrichtigung nur eine unnötige Meldung ist, die schnell aus dem Posteingang gelöscht wird.

Wenn IT-Teams also versuchen, das akzeptable Maß an falsch Positiven gegenüber dem akzeptablen Maß an falsch Negativen abzuwägen, stufen sie falsch Positive oft als akzeptabler ein. Damit gehen sie verständlicher Weise auf Nummer sicher und lassen sich lieber öfter benachrichtigen. Die Folge ist jedoch, dass diese Teams sehr schnell in einer Flut an bedeutungslosen Warnmeldungen ertrinken können, was wiederum das Risiko erhöht, eine kritische Meldung zu übersehen.

Dieser Artikel stellt einige einfache Möglichkeiten für die Feinjustierung eines Monitoring-Systems vor, sodass es keine Benachrichtigungsflut auslöst, sondern im Idealfall nur relevante Benachrichtigungen versendet. Denn ein Monitoring ist nur hilfreich, wenn es keine oder nur gelegentliche Fehlalarme auslöst.

Die hier vorgestellten Tipps basieren auf der IT-Monitoring-Lösung Checkmk und seinen Funktionen. Diese lassen sich möglicherweise nicht immer mit einem anderen Monitoring-Tool umsetzen, da dieses nicht über entsprechende Funktionen verfügt.

1. Nicht Alarmieren. Ganz im Ernst.

Benachrichtigungen in Checkmk sind eigentlich optional. Das IT-Monitoring funktioniert auch ohne sie effizient und zuverlässig. Einige große Organisationen haben eine Art Kontrollzentrum, in dem ein IT-Betriebsteam die Oberfläche von Checkmk ständig überwacht, sodass zusätzliche Benachrichtigungen unnötig sind.

Dabei handelt es sich in der Regel um Anwender, die keinerlei Ausfallzeiten ihrer IT riskieren können, etwa eine Börse. Sie nutzen die Problem Dashboards in Checkmk, um ein Fehlverhalten und dessen Details sofort zu sehen. Da die Listen meist leer sind, fällt es sofort auf, wenn etwas Rotes auf einem solchen Dashboard auftaucht.

Das ist aber eher die Ausnahme. Die meisten Anwender nutzen irgendeine Variante für die Benachrichtigung ihrer Betriebs- und Systemadministratoren-Teams, etwa E-Mail, SMS oder Plugins für ITSM-Tools wie Service-Now, PagerDuty oder Splunk OnCall.

Für Unternehmen, die zum ersten Mal ein IT-Monitoring einrichten, kann es eine sinnvolle Übergangslösung sein, am Anfang gänzlich auf Benachrichtigungen zu verzichten. Stattdessen sollten sie nach der Einrichtung des Monitorings zunächst damit anfangen, die durch das Monitoring erkannten Probleme zu beheben und anschließend Schritt für Schritt Benachrichtigungen einzuschalten. Auf diese Weise bringen Unternehmen zuerst ihre IT-Infrastruktur in Ordnung. Ansonsten kann das frisch aufgesetzte Monitoring eine Vielzahl von Warnungen generieren und das IT-Team direkt überfordern.

2. Zeit geben

Organisationen, die nicht den vorgestellten Weg der “Nicht-Benachrichtigung” gehen wollen, müssen sicherstellen, dass ihre Benachrichtigungen so abgestimmt sind, dass das Monitoring nur im Fall eines echten Problems alarmiert. Das lässt sich dadurch erreichen, wenn man dem Monitoring-Tool Zeit gibt.

Manche Systeme produzieren sporadische und kurzlebige Fehler. Natürlich sollte man deren Ursache untersuchen und beseitigen, es kann jedoch schnell aussichtslos sein, allen auftretenden Problemen hinterherzujagen.

Es gibt zwei Möglichkeiten, Alarme durch solche Probleme zu reduzieren: Die Benachrichtigungen einfach verzögern – das Monitoring versendet diese also erst nach einer bestimmten Zeit und auch nur, wenn sich der Status in der Zwischenzeit nicht wieder auf OK geändert hat. Die Alternative ist die Verwendung der Regel Maximum number of check attempts for service. Damit lässt sich Checkmk anweisen, nur eine Benachrichtigung zu versenden, wenn das Problem über mehrere Prüfintervalle hinweg besteht. Das Standardintervall von Checkmk beträgt 60 Sekunden, es lässt sich jedoch beliebig konfigurieren.

Beide Optionen unterscheiden sich geringfügig in der Art und Weise, wie Checkmk das überwachte System behandelt – der Artikel verzichtet an dieser Stelle darauf, detaillierter auf die Unterschiede einzugehen. Der wesentliche Effekt beider Varianten ist jedoch, dass Checkmk den überwachten Systemen Zeit gibt, sich zu erholen und so eine Reihe von unnötigen Benachrichtigungen vermeidet.

Diese Methode eignet sich auch für “selbstheilende” Systeme, die sich selbstständig erholen sollten und für die das IT-Team keine Benachrichtigung erhalten möchte. Anders verhält es sich hingegen für unternehmenskritische Systeme, für die man sich KEINE Ausfallzeit leisten kann und bei denen man direkt reagieren muss. Ein Hedgefonds überwacht deshalb die Netzwerkverbindung zu einem Derivate-Markplatz. Fällt diese aus, kann er nicht handeln. Jede Sekunde Ausfallzeit kann ihm daher teuer zu stehen kommen.

3. Im Durchschnitt gibt es kein Problem

Benachrichtigungen werden oft dadurch ausgelöst, wenn der Wert einer Auslastungsmetrik, etwa CPU-Auslastung, einen Schwellwert nur kurz überschreitet. Solche kurzen Spitzen sind in der Regel kein Problem und sollten nicht dazu führen, dass das Monitoring-System sofort eine Benachrichtigung auslöst.

Aus diesem Grund haben viele Check-Plugins die Konfigurationsoption, dass Checkmk die jeweiligen Metriken über einen längeren Zeitraum mittelt, zum Beispiel 15 Minuten. Dadurch ignoriert Checkmk vorübergehende Spitzenwerte und wendet die Schwellwerte für die Alarmierung auf die Durchschnittswerte an.

4. Wie die Eltern, so die Kinder

Im folgenden Szenario überwacht ein IT-Team ein entferntes Rechenzentrum. Das heißt, dass ein Monitoring-System Hunderte gut funktionierende Server überwacht. Die Verbindung zu diesen Servern läuft jedoch über den Core-Switch des Rechenzentrums (das Thema Redundanz wird in diesem Beispiel zur Veranschaulichung kurz ausgespart). Fällt dieser Core-Switch aus, bricht die Hölle los, denn das Monitoring-System kann Hunderte von Hosts nicht mehr erreichen und zeigt diese als DOWN an. Hunderte von DOWN-Hosts lösen somit gleichzeitig eine Welle von Hunderten von Benachrichtigungen aus…

Aber: Diese Server funktionieren alle noch einwandfrei. Es ist nur dieser eine Core-Switch, der nicht mehr funktioniert. Das Problem lässt sich vermeiden, wenn man dem Monitoring-System mitteilt, dass all diese Server von diesem Core-Switch abhängig sind. In Checkmk lässt sich das einfach mit “Parent-Child-Relationships” abbilden. Das IT-Team kann so Host A zum “Kind” von Host B erklären, der als “Parent” fungiert. Dadurch weiß Checkmk, dass Host A von B abhängig ist und keine Benachrichtigung verschickt, sollte B ausfallen. Durch die Eltern-Kind-Abhängigkeiten pausiert Checkmk Benachrichtigungen für die Kinder-Hosts, wenn der Eltern-Host ausfällt.

5. Warnmeldungen durch planbaren Ausfallzeiten vermeiden

Es gibt Hunderte von Gründen, warum ein System vorübergehend nicht verfügbar sein kann, etwa weil man es regelmäßig neu starten sollte, Wartungsarbeiten durchführt oder es nur zu bestimmten Zeiten benötigt. Wenn das Monitoring-System dann in den Panikmodus schaltet, wenn ein System planmäßig nicht verfügbar ist, ist das nicht unbedingt hilfreich für das IT-Team.

Checkmk stellt hierfür die Option Scheduled Downtimes bereit. Während einer solchen geplanten Auszeit gibt Checkmk keinen Alarm für das System aus. Die Checkmk Enterprise Edition bietet zusätzlich die Möglichkeit, wiederkehrende Ausfallzeiten zu planen. Wenn zum Beispiel ein System täglich zwischen Mitternacht und 2 Uhr morgens neu gebootet wird, kann das IT-Team das als wiederkehrende Ausfallzeit in Checkmk konfigurieren, sodass es keine Benachrichtigung verschickt, wenn das System in dieser Zeit nicht verfügbar ist.

Die Funktion ist jedoch nicht nur auf Hosts begrenzt, sondern lässt sich auch für einzelne Services nutzen. Aber warum sollte man für einzelne Services eine geplante Ausfallzeit einrichten? Die Antwort ist einfach und unterscheidet sich nicht sonderlich von einem Host: Wenn man weiß, dass ein Prozess ansteht, der eine unnötige Benachrichtigung auslösen würde.

Auf diese Weise behält das Monitoring weiterhin den gesamten Host im Auge, versendet aber keinen Alarm, wenn bestimmte Dienste erwartungsgemäß für eine gewisse Zeit aus dem Ruder laufen und Schwellwerte überschreiten. Dies kann zum Beispiel ein nächtlicher CronJob sein, der Daten synchronisiert und dadurch einen Service wie Disk I/O in die Höhe treibt. Solange sich nach der Synchronisierung alles wieder normalisiert, ist dies kein Grund zur Panik.

Checkmk ermöglicht es außerdem, die geplanten Ausfallzeiten auf die Kinder-Hosts eines Eltern-Hosts auszuweiten.

Der Artikel enthält hoffentlich einige Anregungen, wie IT-Teams die Anzahl an Benachrichtigungen in ihrem IT-Monitoring auf einfache Weise reduzieren können. Viele der beschriebenen Funktionen sind nicht allein auf Checkmk begrenzt, sondern auch in anderen Monitoring-Lösungen verfügbar. Selbstverständlich gibt es noch zahlreiche weitere Möglichkeiten, die Zahl der Benachrichtigungen sinnvoll zu begrenzen.

Die Feinabstimmung der Benachrichtigungen ist eine der wichtigsten, aber auch lohnendsten Aktivitäten, wenn es um die Konfiguration eines IT-Monitoring-Systems geht. Die Auswirkungen machen sich sofort spürbar bemerkbar. Weitere Informationen zu den Benachrichtigungen in Checkmk finden sich in der Dokumentation. Für die Beantwortung von weiteren Fragen ist auch das Checkmk Forum eine gute Anlaufstelle.