In der Statistik treten immer zwei Fehler auf, die man typischerweise als „Typ I“ oder „Typ II“ unterscheidet. In der Sprache der Statistiker ist ein Fehler vom Typ I „die irrtümliche Ablehnung der Nullhypothese“. Oder einfach ausgedrückt: ein falsches Positiv. Beispiele für falsch-positive Ergebnisse sind ein Covid-Test, der bei einer gesunden Person ein negatives Ergebnis liefert, eine seriöse E-Mail, die fälschlicherweise als Spam gekennzeichnet wird, oder eine unschuldige Person, die eines Verbrechens für schuldig befunden wird.

Der Typ-II-Fehler ist – kaum überraschend – das genaue Gegenteil des Typs I, nämlich die „irrtümliche Annahme der Nullhypothese“ – auch bekannt als falsches Negativ. In diesem Fall kommt der Schuldige frei, die Spam-Mail des nigerianischen Prinzen landet tatsächlich im Posteingang und der Covid-Test eines Infizierten ist positiv.

Auch im Monitoring haben wir es mit falsch-positiven und falsch-negativen Ereignissen zu tun. Meldet das Monitoring-Tool ein Problem, obwohl das überwachte System in Wirklichkeit völlig in Ordnung ist, handelt es sich hierbei um eine falsch-positive Benachrichtigung. Beispiele dafür gibt es viele: ein Server, der als DOWN angezeigt wird, weil es eine kurze Störung in der Netzwerkverbindung gab oder ein kritischer Alarm, der durch eine Spitze in der genutzten Bandbreite eines Netzwerkgeräts ausgelöst wird, obwohl diese nach fünf Sekunden wieder normal ist.

Von falsch-negativen Benachrichtigungen im Monitoring sprechen wir, wenn die Monitoring-Software keinen Alarm verschickt, obwohl tatsächlich etwas nicht in Ordnung ist. Wenn beispielsweise die Firewall ausgefallen ist, sollte das IT-Ops-Team dies sofort wissen. Ansonsten könnte das Unternehmen sehr schnell in echte Schwierigkeiten geraten.

Wie viele Benachrichtigungen sind okay?

Das Tückische an der Statistik ist, dass man weder Fehler vom Typ I noch vom Typ II vollständig ausschließen kann. Das ist mathematisch unmöglich. Die einzige Möglichkeit ist, ein akzeptables Niveau von beiden Fehlertypen zu optimieren. Dabei sollte man jedoch bedenken, dass eine Optimierung, die zu sehr auf die Eliminierung von Fehlern des Typs I abzielt, die Fehler des Typs II erhöht und umgekehrt. Wo dieses akzeptable Niveau für die Fehler liegt, hängt von der jeweiligen Situation ab.

Das gilt auch für die Überwachung. Das Problem ist, dass beim Betrieb einer Unternehmens-IT-Infrastruktur die Kosten für eine falsch-positive und eine falsch-negative Benachrichtigung sehr unterschiedlich ausfallen. Ein falsches Negativ kann etwa bedeuten, dass ein geschäftskritisches System ausfällt und das Monitoring keine Warnung ausgibt. Ein falsches Positiv kann ein unnötiger Alarm sein, den der Administrator schnell aus seinem Posteingang löscht.

Wenn IT-Ops-Teams das akzeptable Maß an falsch-positiven Alarmen gegen ein akzeptables Maß an falsch-negativen Alarmen abwägen, tendieren sie dazu, mehr falsch-positive Alarme zu akzeptieren, als das Risiko von mehr falschen Negativen einzugehen. Dies ist der Grund, warum viele IT-Ops-Teams sich für die sichere Variante entscheiden und die Titelfrage – benachrichtigen oder nicht benachrichtigen – mit „benachrichtigen“ beantworten. Und das ist völlig verständlich. Ein Nachteil ist jedoch, dass diese Teams dadurch in unnötigen Alarmen ertrinken können.

Mehr als 300 Alarme jeden Tag

Ein Unternehmen, das zu Checkmk gewechselt ist, setzte zuvor ein Monitoring-System ein, das im Monat etwa 10.000 Alarme an das IT-Ops-Team sendete. Das sind über 300 Alarme jeden Tag – oder bei einem 24/7-Betrieb ungefähr ein Alarm alle vier Minuten. Geht ein Administrator in die Mittagspause, ist bei seiner Rückkehr die gesamte erste Seite seines Posteingangs mit neuen Benachrichtigungen gefüllt – und bei den meisten davon handelt es sich um Fehlalarme, also falsche Positive.

Das Benachrichtigungssystem der besagten Monitoring-Lösung war nicht nur relativ unflexibel, sondern wahrscheinlich auch nicht optimal ausgerichtet. Dadurch wurde das Team mit Warnmeldungen überhäuft, von denen es bereits wusste, dass die meisten wahrscheinlich bedeutungslos sind.

Da jedoch immer die Gefahr besteht, etwas Wichtiges zu übersehen, muss jemand all diese Warnmeldungen durchgehen und prüfen, ob es sich um ein tatsächliches Problem oder um einen Fehlalarm handelt. Dies nimmt jedoch viel Zeit in Anspruch und ist auch nicht die angenehmste Tätigkeit der Welt. Außerdem können die Kosten dafür schwindelerregend sein.

Fehlalarme verursachen hohe Kosten

Geht man davon aus, dass es nur zwei Minuten dauert, zu überprüfen, ob ein Alarm echt ist oder nicht, verbrachte der erwähnte Kunde jeden Monat etwa 20.000 Minuten nur mit der Überprüfung von Alarmen. Dafür benötigt man zwei Vollzeitkräfte – nur für diese Aufgabe. Die zusätzlich noch benötigte Zeit, um echte Probleme zu beheben oder nach der Ursache für die falsche Benachrichtigung zu suchen und zu beheben, ist in dieser Rechnung noch gar nicht berücksichtigt.

Die Kosten fallen jedoch oft nicht nur intern an. Ein anderer Kunde von tribe29, ein europäischer Bahnbetreiber, nutzt Checkmk für das Monitoring seines internen Kommunikationsnetzes. Das ist das System, über das die Bahnbetreiber, die Bahnhöfe und die Verkehrslotsen kommunizieren. Dieses System ist absolut geschäftskritisch. Jeder Alarm muss daher schnell untersucht werden.

Beim eingangs erwähnten tribe29 Kunden, dessen vorherige Monitoring-Lösung so viele Fehlalarme produzierte, war eine schnelle Untersuchung jedes Alarms nicht möglich. Daher beauftragte das Unternehmen einen externen Dienstleister mit der Behebung von Problemen vor Ort. Natürlich stellte dieser Dienstleister dem Unternehmen auch die Kosten für die Untersuchung der Fehlalarme in Rechnung. Nachdem das Unternehmen das Monitoring und die Alarmierung durch Checkmk ersetzt hatte, konnte es die Gesamtkosten um mehr als 65.000 Euro pro Jahr reduzieren, weil es keine Fehlalarme mehr gab! Spoiler-Alarm: Checkmk kostete dem Kunden deutlich weniger als diese 65.000 Euro pro Jahr.

In Zeiten knapper Budgets und eines akuten Mangels an qualifiziertem, technischem Personal kann es sich kein Unternehmen leisten, so viel Zeit oder Geld für Aktivitäten aufzuwenden, die nur einen geringen Mehrwert bringen. Das ist einer der Gründe, warum tribe29 bei der Implementierung von Checkmk bei seinen Kunden so viel Wert darauf legt, dass die Kunden die richtigen Benachrichtigungen erhalten. Auf einen weiteren Grund wird der nächste Artikel eingehen: Die versteckten Kosten von Fehlalarmen. Im dritten  und letzten Teil der Serie werfen wir abschließend einen Blick auf die verschiedenen Tools, die dabei helfen, bessere Warnmeldungen und Benachrichtigungen zu erhalten.


Related Articles

Luftqualitäts-Monitoring mit Checkmk
Luftqualitäts-Monitoring mit Checkmk
Luftqualitätsüberwachung mit Checkmk: Auf der Checkmk Conference #9 haben wir mit CO2-Ampeln die Luftqualität gemonitort und entsprechende Dashboards…
Dashboard für vSphere-Monitoring in Checkmk erstellen
Dashboard für vSphere-Monitoring in Checkmk erstellen
Checkmk bietet eine große Auswahl an vordefinierten Dashboards, unterstützt aber auch das Erstellen individueller Dashboards. In diesem Tutorial…
So werden Sie Ihre eigene Certificate Authority
So werden Sie Ihre eigene Certificate Authority
Unabhängig davon, ob Sie eine möglichst realitätsnahe Testumgebung entwerfen, Checkmk im Intranet (besser) absichern oder eine interne…