Plötzliche Anstiege der Fehleranzahl erkennen

Die Anzahl der Fehler allein sagt nicht immer, dass etwas schiefläuft. Eine Anwendung mit viel Traffic kann mehr Ereignisse erzeugen als ein kleines Projekt, und ein kurzzeitiger Anstieg der Ausnahmen bedeutet nicht immer eine Störung.

Deshalb sollten Alerts zu Fehlern nicht nur die reine Ereigniszahl berücksichtigen, sondern auch das typische Fehlerniveau des jeweiligen Projekts.

Warum funktioniert ein fester Schwellenwert nicht immer?

Ein Schwellenwert wie „100 Fehler" kann für ein Projekt passend sein und für ein anderes völlig nutzlos. Bei einer großen Anwendung können 100 Fehler ein normales Niveau sein, während bei einem kleinen Dienst schon ein Dutzend ähnlicher Ereignisse ein ernstes Problem bedeuten kann.

Deutlich nützlicher ist es, eine Abweichung vom typischen Verhalten der Anwendung zu erkennen.

Wie sieht die Reaktion auf einen Anstieg aus?

Weicht die Ereigniszahl deutlich vom beobachteten Niveau ab, kann das System dies als Signal werten, das Aufmerksamkeit erfordert. Der Mechanismus berücksichtigt außerdem eine Mindestanzahl an Ereignissen, damit eine einzelne zufällige Ausnahme keinen unnötigen Alarm auslöst.

Warum bekommst du nicht bei jedem Fehler eine E-Mail?

Ein wiederkehrendes Problem kann Hunderte Ereignisse erzeugen. Für jedes davon eine eigene Benachrichtigung zu versenden, würde das Monitoring schnell in eine Lärmquelle verwandeln.

Deshalb werden Benachrichtigungen zeitlich begrenzt. Eine andauernde Störung sollte nicht alle paar Sekunden identische Nachrichten erzeugen.

Was solltest du nach einem Alert tun?

Prüfe zuerst, welcher Fehler für den Anstieg verantwortlich ist und wann er zum ersten Mal aufgetreten ist. Vergleiche diesen Zeitpunkt anschließend mit den letzten Deployments und Konfigurationsänderungen.

Der Verlauf der Vorkommenszahl zeigt schnell, ob das Problem noch zunimmt oder nur ein kurzer Ausschlag war.