Jedes Monitoring beginnt mit der Angst, etwas zu verpassen — also sind die ersten Alerts grosszügig. Ein paar Monate später ist der Alarmkanal stummgeschaltet, der E-Mail-Filter schiebt alles in einen Ordner, und den Vorfall, der wirklich zählt, findet ein Kunde. Das ist Alert Fatigue — und sie ist fast nie ein Problem der Menschen, sondern ein Designproblem der Alerts.
Alert Fatigue ist der schleichende Verlust von Vertrauen in Alerts. Sie entsteht, wenn sich zu viele Benachrichtigungen als irrelevant, doppelt oder nicht umsetzbar herausstellen. Jeder Fehlalarm lehrt das Team, dass der nächste Alert wohl warten kann. Das Gefährliche: Diese Lektion stimmt meistens — bis sie es nicht tut.
Man sieht sie meist, bevor jemand sie benennt: ein Alarmkanal, den das halbe Team stummgeschaltet hat, Emoji-Reaktionen statt Antworten, Alerts, die innerhalb von Sekunden quittiert werden (zu schnell, um irgendetwas angesehen zu haben), und der Satz „ach, der kommt immer".
„CPU über 85 %" oder „Speicher über 90 %" löst oft aus und bedeutet selten, dass Nutzer betroffen sind. Alarmieren Sie auf das, was Nutzer oder Kunden erleben — Fehlerrate, fehlgeschlagene Jobs, Arbeit, die nicht passiert ist — und lassen Sie Ressourcenmetriken für die Diagnose auf Dashboards. Eine ausgelastete Ressource, die niemand bemerkt, ist kein Vorfall.
Eine fehlgeschlagene Anfrage oder ein fehlgeschlagener Job ist in jedem echten System normal; Timeouts und vorübergehende Netzwerkfehler passieren. Alarmieren Sie auf ein Muster: „5 Fehler innerhalb von 10 Minuten" statt „jeder Fehler". Diese eine Änderung entfernt meist den Grossteil des Rauschens — und genau so arbeitet QueueHawks Fehlerraten-Regel für Background-Jobs.
Ein Problem, das zwei Stunden dauert, sollte nicht jede Minute eine Nachricht erzeugen. Nutzen Sie einen Cooldown: Nach einem Alert bleibt es für eine festgelegte Zeit ruhig, solange die Bedingung besteht, danach höchstens eine Erinnerung. Dreissig Minuten sind für die meisten Teams ein guter Startwert.
Ohne Entwarnung sieht niemand im Kanal, ob etwas noch kaputt ist. Man prüft von Hand — oder nimmt, häufiger, einfach an, dass es sich erledigt hat. Senden Sie die Entwarnung immer, und genau einmal.
„Fehlerrate überschritten" ist nicht umsetzbar. Welche Anwendung? Welche Umgebung — Produktion oder Staging? Welcher Job oder Endpunkt? Was war der letzte Fehler? Ein Alert, der erst drei Tools öffnen lässt, bevor klar ist, ob er zählt, wird verschoben. Gehören in die Nachricht selbst: Anwendung, Umgebung, betroffene Job-Typen, letzte Exception und ein direkter Link.
Leiten Sie nach Dringlichkeit und Zielgruppe weiter. Produktionsausfälle in den Team-Kanal (oder per Webhook in ein Bereitschaftstool), Staging-Fehler und Warnungen mit niedriger Priorität in einen eigenen Kanal oder eine E-Mail-Zusammenfassung. Landet Staging-Rauschen neben Produktions-Alerts, werden auch die Produktions-Alerts stummgeschaltet.
Alerts sammeln sich an. Gehen Sie einmal im Monat jeden ausgelösten Alert durch und stellen Sie eine Frage: Hat er zu einer Handlung geführt? Wenn nicht: Schwellwert erhöhen, Zeitfenster vergrössern, Weiterleitung ändern oder löschen. Einen Alert zu löschen, der nie zu einer Handlung führte, senkt die Sicherheit nicht — er erhöht die Chance, dass die übrigen gelesen werden.
Beim Leiserstellen gibt es eine Falle. Die wichtigsten Ausfälle geplanter und Hintergrundarbeit erzeugen überhaupt keinen Fehler: ein gestoppter Scheduler, ein abgestürzter Worker, ein entfernter Server. Leisere Fehler-Alerts helfen dort nicht — es braucht eine eigene Heartbeat-Prüfung, die auslöst, wenn ein erwartetes Signal ausbleibt. Wählen Sie ihren Timeout sorgfältig: zu kurz, und jeder Deploy sieht wie ein Ausfall aus (eine direkte Quelle von Alarmmüdigkeit), zu lang, und Sie erfahren es eine Stunde zu spät. Der Heartbeat-Timeout-Rechner hilft beim Wert.
Den Gesamtzusammenhang liefert Was ist Monitoring?; die Begriffe erklärt das Monitoring-Glossar.
Alert Fatigue (Alarmmüdigkeit) entsteht, wenn ein Team so viele irrelevante, doppelte oder nicht handlungsrelevante Alerts bekommt, dass niemand mehr darauf reagiert — auch nicht auf die wichtigen. Es ist ein Vertrauensproblem: Jeder Fehlalarm senkt die Chance, dass der nächste echte gelesen wird.
Typische Ursachen sind Alerts auf Ursachen statt Symptome (CPU, Speicher), Schwellwerte auf Einzelereignisse statt Zeitfenster, keine Deduplizierung bei andauernden Problemen, Alerts ohne Kontext, ein einziger Kanal für alles und Alerts, die nie überprüft oder gelöscht werden.
Eine allgemeingültige Zahl gibt es nicht, aber eine nützliche Regel aus der SRE-Praxis lautet: Jeder Alarm sollte eine menschliche Handlung erfordern. Bekommt eine Person in Bereitschaft regelmässig mehr Alerts, als sie ordentlich untersuchen kann — oft genannt werden mehr als zwei echte Vorfälle pro Schicht —, muss das Alerting angepasst werden, nicht die Person.
Ja. Eine Entwarnung schliesst den Kreis, verhindert, dass jemand etwas untersucht, das sich bereits erholt hat, und macht im Kanalverlauf sichtbar, wie lange ein Vorfall gedauert hat.
Fehlerraten- und Heartbeat-Alerts für Hangfire mit Cooldown und Entwarnung. Kostenlos für eine Application.