Warum ein fester Schwellenwert für Warnmeldungen beim Fehlermonitoring nicht funktioniert
Die einfachste Methode, eine Warnmeldung einzurichten, klingt zunächst harmlos: „Benachrichtige mich, wenn die Anzahl der Fehler 100 pro Stunde überschreitet.“ Das Problem entsteht, sobald sich die Anwendung weiterentwickelt. Der Traffic wächst, neue Funktionen kommen hinzu, die Anzahl der Benutzer verändert sich und plötzlich hat der einige Monate zuvor festgelegte Wert kaum noch eine Bedeutung.
Fehlermonitoring sollte vor allem eine Frage beantworten: Passiert gerade etwas, das für diese konkrete Anwendung ungewöhnlich ist? Die reine Anzahl der Ereignisse liefert darauf nicht immer eine gute Antwort.
Derselbe Schwellenwert passt nicht zu jeder Anwendung
Stellen Sie sich einen Onlineshop vor, der täglich Tausende von Bestellungen verarbeitet. Selbst bei einwandfreiem Betrieb treten einzelne Fehler auf, etwa durch abgebrochene Sitzungen, fehlgeschlagene Zahlungsversuche, Timeouts externer Dienste oder automatisierten Bot-Traffic.
Wenn ein solcher Shop innerhalb einer Stunde mehrere Dutzend oder sogar mehrere Hundert Fehler erzeugt, muss das noch keinen Ausfall bedeuten. Eine Warnmeldung bei 100 Fehlern kann daher ständig Benachrichtigungen über Situationen auslösen, die in Wirklichkeit zum normalen Betrieb gehören.
In die andere Richtung funktioniert das noch schlechter. Ein Administrationsbereich, der nur von wenigen Personen genutzt wird, erzeugt möglicherweise den ganzen Tag über keinen einzigen Fehler. Ein fester Schwellenwert von 100 Ereignissen wird dann selbst dann nicht erreicht, wenn die Anwendung plötzlich bei jeder Anfrage einen HTTP-500-Fehler zurückgibt.
Besser ist eine Warnmeldung auf Basis von Abweichungen vom Normalzustand
Beim Monitoring lohnt es sich, zwei Dinge voneinander zu trennen: die minimale Anzahl von Ereignissen und die Abweichung vom typischen Fehlerniveau.
Der Mindestschwellenwert schützt vor Fehlalarmen. Wenn eine ruhige Anwendung normalerweise nur ein oder zwei Fehler pro Tag erzeugt, sollte ein einzelnes zusätzliches Ereignis nicht gleich das gesamte Team alarmieren.
Der zweite Faktor hilft dagegen, plötzliche Veränderungen zu erkennen. Wenn eine Anwendung in einem vergleichbaren Zeitraum normalerweise 20 Fehler erzeugt und plötzlich ein Vielfaches davon auftritt, ist das eine wesentlich wertvollere Information als eine reine Zahl ohne Kontext.
Der Normalzustand muss unabhängig vom aktuellen Ausfall bestimmt werden
Das ist ein wichtiges Detail bei der Entwicklung eines solchen Mechanismus. Der Normalzustand darf nicht ausschließlich anhand der letzten Minuten oder Stunden bestimmt werden.
Wenn ein Ausfall schleichend beginnt und die Anzahl der Fehler über mehrere Stunden hinweg steigt, erhöhen die aktuellen Daten nach und nach den Referenzwert. Das System könnte die steigende Fehlerzahl dann genau in dem Moment als neuen Normalzustand betrachten, in dem Sie eine Warnung am dringendsten benötigen.
Deshalb sollte der Referenzwert auf einer längeren Historie und aggregierten Statistiken basieren. So verändert ein einzelner Vorfall nicht sofort das Bild des normalen Anwendungsbetriebs.
Warum die Unterdrückung wiederholter Warnmeldungen genauso wichtig ist
Selbst ein guter Mechanismus zur Erkennung von Anomalien kann störend werden, wenn jedes weitere Messintervall eine neue Nachricht auslöst.
Ein Ausfall kann eine Stunde, mehrere Stunden oder die ganze Nacht dauern. Wird alle paar Minuten eine neue Warnmeldung verschickt, lässt sich nach Dutzenden von Nachrichten nur noch schwer erkennen, wann das Problem tatsächlich begonnen hat und welche Meldungen lediglich Wiederholungen sind.
Deshalb sollte das Monitoring wiederholte Benachrichtigungen unterdrücken. Die erste Warnmeldung informiert über das Problem, während weitere Vorkommnisse in der Monitoring-Historie sichtbar bleiben, ohne das E-Mail-Postfach mit zusätzlichen Nachrichten zu überfluten.
Eine gute Warnmeldung sollte nicht über alles informieren
Das Ziel von Monitoring besteht nicht darin, möglichst viele Benachrichtigungen zu versenden. Entscheidend ist, Informationen genau dann zu übermitteln, wenn sie relevant sind.
Ein fester Schwellenwert beantwortet die Frage: „Sind mehr als X Fehler aufgetreten?“ Anomaliebasiertes Monitoring beantwortet dagegen eine wesentlich wichtigere Frage: „Weicht das Verhalten der Anwendung deutlich von dem ab, was normalerweise zu erwarten ist?“
Genau dieser Unterschied entscheidet darüber, ob Warnmeldungen dabei helfen, schnell auf Probleme zu reagieren, oder ob sie nach einigen Wochen nur zu einer weiteren Quelle von Benachrichtigungen werden, die man ohne großes Nachdenken stummschaltet.
