Alerts optimieren

Ein Alert ist nur nützlich, wenn jemand darauf reagiert. Wenn ein Team mehr Benachrichtigungen erhält, als es bearbeiten kann, beginnt es alle zu ignorieren – auch die, die wichtig war. Das ist Alert-Müdigkeit, und sie ist meist ein Konfigurationsproblem und kein Monitoring-Problem. Diese Seite behandelt, wie Sie einen bereits vorhandenen Alert optimieren. Wenn Sie erst entscheiden, bei welchen Bedingungen Sie überhaupt alarmieren möchten, beginnen Sie mit den Vorlagen für Alerts. Wenn Ihr Problem das gesamte Set und nicht ein einzelner Trigger ist, arbeitet Alert-Rauschen reduzieren die Änderungen ab, die zuerst die meisten Benachrichtigungen entfernen.

​

Anzeichen dafür, dass Ihr Alerting Optimierung braucht

• Ein Kanal erhält Alerts, denen niemand nachgeht.
• Derselbe Alert öffnet und schließt mehrmals pro Stunde.
• Ein Vorfall erzeugt viele Benachrichtigungen von vielen Hosts oder Tag-Kombinationen.
• On-Call erhält Alerts, auf die erst zu Geschäftszeiten reagiert werden kann.
• Jemand hat die Benachrichtigungen für den Alert-Kanal deaktiviert.

Jedes davon lässt sich einer bestimmten Einstellung in den folgenden Abschnitten zuordnen.

​

Schwellenwert, warm-up und cooldown

Jeder Anomaly-detection-Trigger hat drei Einstellungen, die steuern, wann Alerts öffnen und schließen. Optimieren bedeutet fast immer, eine davon anzupassen.

​

Schwellenwerte anhand der Metrikhistorie festlegen

Stellen Sie die Metrik vor der Wahl eines Schwellenwerts über mindestens zwei Wochen grafisch dar und betrachten Sie ihren normalen Bereich, einschließlich der täglichen und wöchentlichen Spitzen. Ein Schwellenwert unterhalb einer routinemäßigen Montagmorgen-Spitze benachrichtigt Sie jeden Montagmorgen. Ein nützlicher Ausgangspunkt ist der Wert, den die Metrik in einer geschäftigen, aber gesunden Phase erreicht, plus genügend Spielraum, damit normale Schwankungen ihn nicht überschreiten. Wenn Sie nicht beschreiben können, was Sie beim Überschreiten des Schwellenwerts tun würden, ist es wahrscheinlich nicht der richtige Schwellenwert.

​

warm-up verwenden, um Ausreißer herauszufiltern

warm-up ist die Zeit, die AppSignal wartet, bevor ein Alert geöffnet wird. Während dieser Wartezeit muss die Metrik – je nach Trigger – über oder unter dem Schwellenwert bleiben. Mit einem warm-up von 0 kann AppSignal einen Alert öffnen, sobald die Metrik den Schwellenwert überschreitet. Verwenden Sie warm-up, um Alerts für kurze Metrik-Ausreißer zu vermeiden, etwa einen langsamen deploy, eine Garbage-Collection-Pause oder einen neu startenden Host. Beginnen Sie für die meisten Produktions-Alerts mit null bis zwei Minuten. Verwenden Sie einen längeren warm-up nur dann, wenn die Metrik häufig ausschlägt und sich schnell erholt. Legen Sie warm-up danach fest, wie stark sich die Metrik von Minute zu Minute verändert. Eine Metrik, die sich schnell ändert, braucht oft einen warm-up. Eine Metrik, die sich allmählich ändert, braucht oft wenig oder keinen. Nützliche warm-ups sind meist kurz. Ab etwa 10 Minuten verzögern Sie überwiegend die Benachrichtigung, statt sie zu verbessern. Wenn Sie 30 oder 60 Minuten benötigen, um Benachrichtigungen zu reduzieren, prüfen Sie stattdessen Schwellenwert oder Umfang.

​

cooldown verwenden, wenn Alerts wiederholt öffnen und schließen

cooldown ist die Anzahl der Minuten, die die Metrik erholt bleiben muss, bevor der Alert schließt und ein neuer Alert öffnen kann. Bei „mehr als”-Triggern bedeutet das, dass die Metrik unter dem Schwellenwert bleibt. Bei „weniger als”-Triggern bedeutet es, dass die Metrik über dem Schwellenwert bleibt. Ohne cooldown erzeugt eine Metrik, die ihren Schwellenwert wiederholt überschreitet, einen Strom von Öffnungs- und Schließbenachrichtigungen für einen einzigen Vorfall. Ein kurzer cooldown verwandelt diesen Strom in einen einzelnen Alert. Setzen Sie ihn etwas länger als den Zeitraum, in dem sich die Metrik üblicherweise über und unter den Schwellenwert bewegt. cooldown ist eine gezielte Korrektur und kein Standard. Die meisten Trigger brauchen ihn nie, weil die meisten Metriken nicht genau auf ihrem Schwellenwert liegen. Lassen Sie ihn bei 0, bis Sie einen Trigger sehen, der für einen klar erkennbaren einzelnen Vorfall wiederholt öffnet und schließt, und setzen Sie ihn dann anhand der tatsächlichen Länge dieser Lücken.

​

Umfang: ein Trigger kann viele Alerts öffnen

Das ist die häufigste Ursache für viele Benachrichtigungen aus einem Vorfall. Ein Trigger öffnet nicht einen Alert. Er öffnet einen Alert pro passender Serie. Bei Host-Triggern bedeutet das einen Alert pro Host. Das hostname-Feld akzeptiert einen Wildcard, und sein Standardwert * passt auf jeden Host, der an die App meldet. Eine Flotte von 30 Hosts, die gleichzeitig einen CPU-Schwellenwert überschreitet, erzeugt 30 Alerts. Grenzen Sie den Umfang ein, damit die Benachrichtigung genau sagt, was betroffen ist:

• Legen Sie einen bestimmten hostname fest oder ein Präfix wie web-*, statt den Standard * zu belassen.
• Fügen Sie Tags hinzu, damit der Trigger nur die Serien beobachtet, die Sie interessieren, etwa mountpoint=/ für die Festplattennutzung oder region=eu für eine benutzerdefinierte Metrik.
• Grenzen Sie Trigger für Fehlerrate und Antwortzeit auf einen einzelnen namespace ein, damit web, background und admin unterschiedliche Schwellenwerte und unterschiedliche notifier haben können.

Wenn Sie Tags hinzufügen, warnt AppSignal Sie, falls die Tag-Kombination in der letzten Stunde nicht gesehen wurde. Diese Warnung bedeutet meist, dass der Trigger nie auf Daten passen wird. Verwenden Sie eine der im Trigger-Formular aufgeführten Tag-Key-Kombinationen und setzen Sie jeden Wert auf einen exakten Wert oder einen Wildcard. uptime monitors verhalten sich genauso. Jede der vier Regionen wird separat verfolgt, sodass ein Monitor vier Alerts für einen einzigen Ausfall öffnen kann – und einen Alert, wenn eine einzelne Region einen ansonsten gesunden Endpoint nicht erreichen kann.

​

Eine Metrik wählen, die die Nutzerauswirkung widerspiegelt

Das Ändern von Trigger-Einstellungen kann einen Trigger nicht reparieren, der die falsche Metrik beobachtet. Bevorzugen Sie Raten gegenüber Zählwerten. Die Fehleranzahl überschreitet einen festen Schwellenwert immer dann, wenn der Traffic wächst, und benachrichtigt Sie so an Ihren geschäftigsten Tagen, unabhängig davon, ob etwas nicht stimmt. Die Fehlerrate bleibt stabil, während sich der Traffic verändert. Verwenden Sie Zählwerte nur für Metriken, bei denen jedes Auftreten zählt, etwa Fehler in einem Zahlungsablauf. Bevorzugen Sie Perzentile gegenüber Mittelwerten. Eine mittlere Antwortzeit verbirgt eine langsame Erfahrung für einen Teil Ihres Traffics. Wenn 5 % der Anfragen 8 Sekunden brauchen, bewegt sich der Mittelwert kaum. Alarmieren Sie stattdessen auf p90 oder p95. Bevorzugen Sie für Nutzer sichtbare Symptome gegenüber Ursachen. Alarmieren Sie bei Fehlern, Latenz, Traffic oder fehlgeschlagenen Geschäftsaktionen und nutzen Sie Dashboards, um die Ursache zu finden. Hohe CPU-Nutzung ist selbst kein Problem, wenn die Antwortzeiten in Ordnung sind. So bleibt die Zahl der Alerts proportional zur Zahl der echten Vorfälle. Setzen Sie fehlende Daten bewusst auf null. Ein Trigger geht davon aus, dass jede Minute ein Datenpunkt eintrifft. Aktivieren Sie für Metriken, die nur melden, wenn etwas passiert, etwa einen Counter, die Option treat missing datapoints as 0, damit der Alert schließt, wenn die Aktivität endet. Lassen Sie sie deaktiviert, wenn eine Datenlücke „keine Information” statt „null” bedeutet.

​

Nach Schweregrad routen, nicht aus Gewohnheit

Alles an einen Kanal zu senden verursacht Alert-Müdigkeit. Jeder Trigger kann seinen eigenen notifier verwenden, nutzen Sie das also, um dringende Alerts von solchen zu trennen, die warten können. Geben Sie Staging einen eigenen Kanal oder lassen Sie dessen Trigger ohne notifier. Staging-Alerts, die in einem Produktionskanal eintreffen, sind einer der schnellsten Wege, einem Team beizubringen, diesen Kanal zu ignorieren. Schweregrad ist nicht die einzige nützliche Aufteilung. Sobald Sie mehr als eine Handvoll Trigger haben, halten getrennte Chat-Kanäle pro Domäne – etwa einer für Anwendungsfehler und einer für Infrastruktur – jeden Kanal klein genug, dass die Menschen, die ihn beobachten, erkennen, wenn etwas ungewöhnlich ist. Ein einzelner Kanal, der alles erhält, macht es leichter, wichtige Benachrichtigungen zu übersehen.

​

Incidents und Trigger unterschiedlich routen

Routing hat zwei Ebenen, und sie verhalten sich unterschiedlich. Wählen Sie bei Anomaly-detection-Triggern die notifier am Trigger selbst. Werden alle notifier entfernt, bleibt der Trigger aktiv und zeichnet weiterhin Alerts auf, sendet aber keine Benachrichtigungen. Legen Sie für Fehler- und Performance-Incidents Benachrichtigungs-Defaults pro namespace fest, statt jeden Incident einzeln zu konfigurieren. Ein admin-namespace, der auf Never Notify gesetzt ist, entfernt eine ganze Kategorie wenig hilfreicher Benachrichtigungen auf einmal. In den namespace-Defaults routen Sie außerdem web-, background- und admin-Incidents an unterschiedliche Ziele. notifier werden einmal für die Organisation konfiguriert und können über Apps hinweg genutzt werden, daher braucht ein von vielen Apps genutzter notifier Umsicht. Prüfen Sie vor dem Bearbeiten, wo ein notifier verwendet wird.

​

Die Benachrichtigung soll sich selbst erklären

Alert-Müdigkeit hängt nicht nur davon ab, wie viele Benachrichtigungen eintreffen. Sie hängt auch davon ab, wie viel Arbeit es kostet, jede einzelne zu verstehen. Ein Alert, der sagt, dass eine Zahl einen Schwellenwert überschritten hat, zwingt die reagierende Person, erst herauszufinden, was dieser Schwellenwert bedeutet. Ein Alert, der sich selbst erklärt, kann sofort bearbeitet oder bewusst ignoriert werden. Drei Felder liefern diesen Kontext, und alle drei sollten bei jedem Trigger ausgefüllt werden. Name. Sagen Sie, was falsch ist, nicht welche Metrik sich bewegt hat. Eine Trigger-Liste, in der viele Einträge Custom metric heißen, lässt sich nicht prüfen oder triagieren. Beschreibung. Behandeln Sie sie als einzeiliges Runbook. Geben Sie an, was die Bedingung bedeutet und was die reagierende Person dagegen tun soll. Das sind die beiden Fragen, die eine reagierende Person beantworten muss, und die Beschreibung ist der beste Ort dafür:

• „Dieser Host swappt, daher ist jede Anfrage, die er bedient, langsamer. Prüfen Sie, was den Speicher belegt, und benachrichtigen Sie den Operations-Kanal.”
• „Weniger als 100 MB freier Speicher. Prüfen Sie, was ihn belegt, und schaffen Sie Kapazität, bevor der Kernel Prozesse beendet.”
• „Dieser Service hat ein bekanntes Speicherleck. Der Speicher wächst, bis der Kernel den Prozess beendet; starten Sie ihn also neu und eskalieren Sie nur, wenn es innerhalb einer Stunde erneut auftritt.”

Das dritte Beispiel ist bemerkenswert. Eine bekannte Ursache am Trigger zu dokumentieren verhindert, dass dieselbe Untersuchung von der jeweils zuständigen On-Call-Person wiederholt wird, und es sagt der reagierenden Person, wann sie nicht handeln soll. Dashboard. Jeder Trigger kann ein Dashboard verlinken, und der Link ist in der Benachrichtigung enthalten. Verlinken Sie das Dashboard, das die Metrik im Kontext zusammen mit verwandten Metriken zeigt. Das gibt der reagierenden Person einen Ausgangspunkt für die Untersuchung.

​

Was Sie nicht optimieren können und was nicht alarmieren sollte

Zwei Dinge an Trigger-Alerts lassen sich nicht optimieren, und eine Kategorie von Metriken sollte von vornherein nicht alarmieren. Häufigkeitsoptionen gelten für Incidents und Log triggers, nicht für Alerts von Anomaly-detection-Triggern. Fehler- und Performance-Benachrichtigungen verwenden Optionen für Incident-Benachrichtigungen wie Every Occurrence, First in Deploy, First After Close und Never Notify, festgelegt pro namespace in den Benachrichtigungs-Defaults. Log triggers haben ähnliche Schwellenwert-Optionen. Alerts von Anomaly-detection-Triggern folgen stattdessen dem Alert-Zustandsautomaten. Nur E-Mail wiederholt sich, solange ein Anomaly-Alert offen bleibt. E-Mail-notifier haben ein Reminder interval von 15 Minuten, 30 Minuten oder 1 Stunde. Slack, PagerDuty, Opsgenie und Webhooks haben kein Äquivalent. Was Sie stattdessen tun können. Um zu verhindern, dass ein Trigger jemanden benachrichtigt, entfernen Sie seine notifier oder archivieren Sie ihn. Wenn ein offener Alert weiterhin Erinnerungen senden muss, bis jemand handelt, kombinieren Sie E-Mail mit einem On-Call-Tool, das eine eigene Eskalationsrichtlinie hat. Wenn ein langlaufender Alert einen Chat-Kanal füllt, liegt die Ursache im wiederholten Öffnen und Schließen und nicht in Erinnerungen, die Lösung ist also ein längerer cooldown. Entscheiden Sie in anderen Fällen, ob die Bedingung überhaupt eine Benachrichtigung senden sollte.

• Alarmieren Sie bei einer Fehlerrate über 5 % in web für drei Minuten, nicht bei jeder einzelnen Exception, so selten sie auch ist.
• Alarmieren Sie, wenn sich die p95-Antwortzeit im Checkout verdoppelt, nicht bei einem Mittelwert, der von 180 ms auf 200 ms gestiegen ist.
• Alarmieren Sie bei einem throughput von null, wo er normalerweise 400 req/min beträgt, nicht bei Traffic, der sich über Nacht halbiert, wie er es jede Nacht tut.
• Alarmieren Sie bei einer Festplatte, die 85 % erreicht und pro Stunde einen Punkt zulegt, nicht bei CPU, die während eines deploys für eine Minute 100 % erreicht.
• Alarmieren Sie bei einem nächtlichen Rechnungsjob, der sich nie gemeldet hat, nicht bei demselben Job, der zwei Minuten zu spät startet.
• Alarmieren Sie bei einem Zahlungsanbieter mit 50 Timeouts in einer Stunde, nicht bei einer Anfrage, die einen Timeout hatte und beim Retry erfolgreich war.

Wenn eine Metrik interessant, aber nicht handlungsrelevant ist, stellen Sie sie auf ein Dashboard, statt Benachrichtigungen dafür zu senden.

​

Trigger regelmäßig prüfen

Alert-Konfigurationen veralten. Trigger überleben die Vorfälle, die sie motiviert haben, Schwellenwerte für den Traffic des letzten Jahres passen nicht mehr, und in einem Trigger benannte Hosts werden ersetzt. Prüfen Sie Ihre Trigger etwa vierteljährlich und fragen Sie für jeden:

1. Hat er in den letzten 90 Tagen einen Alert geöffnet? Falls nicht, öffnen Sie ihn und prüfen Sie die Chart-Vorschau. Keine Daten oder eine Warnung im hostname-Feld, dass der Host nicht gefunden wurde, bedeutet, dass er etwas beobachtet, das nicht mehr existiert. Umbenannte oder ersetzte Hosts sind die übliche Ursache, und der Trigger benachrichtigt Sie nicht, wenn er auf nichts passt.
2. Hat jemand darauf reagiert? Ein Alert, auf den niemand reagiert, sollte nachjustiert, umgeleitet oder archiviert werden.
3. Hat er viele Alerts für einen Vorfall geöffnet? Grenzen Sie seinen Umfang ein.
4. Ist sein notifier noch der richtige? Nicht dringende Probleme an On-Call zu senden ist eine Hauptquelle von Alert-Müdigkeit.
5. Erklärt er sich selbst? Ein Trigger ohne Namen und ohne Beschreibung lässt sich nicht triagieren, weil niemand sagen kann, was er tut, ohne ihn zu rekonstruieren.
6. Ist er ein Duplikat? Zwei Trigger mit derselben Metrik, demselben Schwellenwert und demselben notifier senden zwei Benachrichtigungen für ein Problem.
7. Ist noch jemand dafür verantwortlich? Trigger, die von Personen erstellt wurden, die das Unternehmen verlassen haben, sind am wahrscheinlichsten veraltet und werden am seltensten geprüft.

Sie können jeden konfigurierten Trigger mit der AppSignal CLI oder über den MCP server auflisten, um sie zu prüfen, ohne jeden einzelnen in der Oberfläche zu öffnen.

​

Zusammenfassung: einen Trigger optimieren, der zu viele Benachrichtigungen sendet

Dieser Abschnitt führt nichts Neues ein. Er ordnet die vorherigen Abschnitte anhand eines Beispiels: ein Trigger auf Host-CPU-Nutzung über 80 %, ohne warm-up, ohne cooldown und mit dem Standard-hostname *, der mehrere On-Call-Benachrichtigungen pro Nacht sendet, obwohl es kein für Nutzer sichtbares Problem gibt.

1. Prüfen Sie die Metrik. CPU-Nutzung ist eine Ursache und kein für Nutzer sichtbares Symptom, und Antwortzeit sowie Fehlerrate sind während der CPU-Spitzen beide gesund.
2. Grenzen Sie den Umfang ein. Die Spitzen kommen von background-Workern, daher wird der hostname zu web-*.
3. Legen Sie den Schwellenwert anhand der Historie fest. Zwei Wochen Daten zeigen, dass web-Hosts in der Abendspitze routinemäßig 85 % erreichen, daher wandert der Schwellenwert auf 95 %.
4. Fügen Sie einen warm-up hinzu. Zwei Minuten, weil eine kurze CPU-Spitze normal ist und On-Call nicht benachrichtigen sollte.
5. Fügen Sie einen cooldown hinzu. Setzen Sie einen kurzen cooldown, damit ein Host nahe dem Schwellenwert einen Alert statt sechs erzeugt.
6. Leiten Sie ihn um. Dauerhafte CPU-saturation ist ein Kapazitätsproblem und kein Ausfall, daher geht sie an den Team-Chat und der On-Call-notifier wird entfernt.
7. Fügen Sie den fehlenden Alert hinzu. Das Team brauchte einen Alert für die Nutzerauswirkung, daher ergänzt es einen p95-Antwortzeit-Trigger auf dem web-namespace, geroutet an On-Call. Alerting in der Produktion behandelt, wie Sie den Rest finden.

Das Ergebnis sind weniger Benachrichtigungen, und die verbleibenden beschreiben etwas, worauf eine Person reagieren kann.

​

Nächste Schritte

• Wählen Sie mit den Vorlagen für Alerts, was Sie überwachen.
• Prüfen Sie Einrichtungsreihenfolge und Abdeckung mit Alerting in der Produktion.
• Sehen Sie sich im Detail an, wie warm-up und cooldown funktionieren.
• Konfigurieren Sie die Benachrichtigungseinstellungen für Fehler- und Performance-Incidents.
• Richten Sie Check-ins für geplante Arbeit ein, statt lange warm-ups zu verwenden.