Skip to main content
Auf dieser Seite geht es darum, Produktions-Alerting von Anfang an richtig aufzusetzen: was Sie einrichten, in welcher Reihenfolge, wie Sie die Funktion bestätigen und wie Sie prüfen, dass nichts Wichtiges unbeobachtet bleibt. Sie setzt voraus, dass Sie wissen, bei welchen Bedingungen Sie alarmieren möchten. Falls noch nicht, beginnen Sie mit den Vorlagen für Alerts. Wenn Sie bereits Alerts haben und diese zu störend sind, gehen Sie zu Alerts optimieren.

​
Bevor Sie einen Trigger erstellen

Drei Einrichtungsschritte machen jeden folgenden Alert nützlicher, und alle drei sind vorab leichter umzusetzen als nachträglich. Fügen Sie Ihre notifier hinzu. Trigger verweisen auf notifier. Wenn Sie diese zuerst erstellen, können Sie jeden Alert direkt beim Aufbau weiterleiten, anstatt später alles noch einmal durchzugehen. Richten Sie mindestens zwei Ziele ein: eines für Dringendes, etwa ein On-Call-Tool, und eines für Nicht-Dringendes, etwa einen Team-Chat-Kanal. notifier werden einmal für die Organisation konfiguriert und über Apps hinweg gemeinsam genutzt. Senden Sie deploy markers. Die meisten Produktionsvorfälle beginnen mit einem Release. Ein Marker verwandelt „Wann hat das angefangen?” in eine Frage, die Sie in Sekunden beantworten können, und er ist die Grundlage dafür, dass die Einstellung First in Deploy funktioniert. Teilen Sie Ihre App in namespaces auf. namespaces sind der wichtigste Hebel, um mit unterschiedlichen Schweregraden zu alarmieren, ohne jeden Alert einzeln zu konfigurieren. Wenn web-, background- und admin-Traffic alle in einem namespace landen, muss jeder Schwellenwert, den Sie festlegen, für alle drei gleichzeitig passen – und passt damit meist zu keinem.

​
Alerts in Schichten hinzufügen

Alle Alerts auf einmal hinzuzufügen erzeugt am ersten Tag zu viele Benachrichtigungen und bringt dem Team bei, sie zu ignorieren. Fügen Sie eine Schicht hinzu, leben Sie eine Woche damit und ergänzen Sie dann die nächste.
  1. Erreichbarkeit. Ein uptime monitor auf einem Health-Check-Endpoint. Das ist der einzige Alert, der noch funktioniert, wenn Ihre Anwendung überhaupt nichts mehr melden kann.
  2. Für Nutzer sichtbare Symptome. Fehlerrate und Antwortzeit in Ihrem nutzerorientierten namespace. Diese Alerts entsprechen Fehlern oder langsamen Antwortzeiten, die Nutzer erleben.
  3. Geplante Arbeit und background-Arbeit. Check-ins für Cron-Jobs und Worker-heartbeats sowie ein Absence-Alert für jede Queue, in der niemals keine Aktivität herrschen sollte.
  4. saturation. Festplatte, Speicher und Swap des Hosts. Das sind Ursachen und keine Symptome, leiten Sie sie daher an den Chat und nicht an On-Call.
  5. Geschäftsmetriken. Benutzerdefinierte Metriken für die anwendungsspezifische Aktivität, die nur Sie messen können, etwa abgeschlossene Zahlungen oder Anmeldungen pro Minute.
Die Schichten eins und zwei decken die meisten realen Vorfälle ab. Schicht fünf erkennt anwendungsspezifische Ausfälle, die andere Alerts nicht erkennen können.

​
Rauschen aus Staging und Tests aus der Produktion heraushalten

Produktions-Alerting bleibt nur dann glaubwürdig, wenn Rauschen aus Nicht-Produktionsumgebungen es nie erreicht.
  • Geben Sie jeder Umgebung ihre eigene App in AppSignal, damit Schwellenwerte und notifier pro Umgebung festgelegt und nicht gemeinsam genutzt werden.
  • Geben Sie Staging einen eigenen Chat-Kanal oder lassen Sie Staging-Trigger ganz ohne notifier. Ein Trigger ohne notifier zeichnet weiterhin Alerts auf, die Sie später prüfen können, ohne jemanden zu benachrichtigen.
  • Verwenden Sie unterschiedliche Schwellenwerte. Staging-Traffic ist geringer und verändert sich stärker als Produktions-Traffic, daher öffnet ein auf Produktionsdaten abgestimmter Schwellenwert möglicherweise nie einen Alert oder öffnet zu häufig Alerts.
  • Halten Sie persönliche Test-Kanäle aus Produktions-Apps heraus. Ein notifier kann von mehreren Apps genutzt werden, und Trigger-Alerts werden über die an jedem Trigger ausgewählten notifier weitergeleitet.

​
Ihre Abdeckung prüfen

Zu viele Benachrichtigungen sind der sichtbare Fehler. Der verborgene Fehler ist ein Ausfall, zu dem niemand alarmiert wurde. Arbeiten Sie die Fehlerarten statt der Funktionen durch und prüfen Sie, dass es für jede einen Alert gibt: Die letzte Zeile fehlt am häufigsten. Jeder andere Alert in dieser Liste benötigt eintreffende Daten, bevor er öffnen kann. Zwei Fragen sind nützlich, um das gesamte Set zu prüfen. Erstens: Erreicht der Alert für jede abgedeckte Zeile jemanden, der zu der Tageszeit handeln kann, zu der er am wahrscheinlichsten öffnet? Zweitens: Wie viele Ihrer letzten Produktionsvorfälle wurden zuerst von einem Menschen und nicht von einem Alert gemeldet? Diese zweite Zahl ist ein nützliches Maß für die Abdeckung.

​
Entscheiden, wie schnell Sie es erfahren müssen

Erkennung erfolgt nicht sofort, und es lohnt sich, bewusst zu entscheiden, wie viel Verzögerung jeder Alert tragen darf. Drei Faktoren summieren sich zur Zeit zwischen dem Beginn eines Problems und dem Eintreffen einer Benachrichtigung:
  • Aggregation. Metriken werden einmal pro Minute ausgewertet, es dauert also immer bis zu eine Minute, bis der betreffende Wert überhaupt berücksichtigt wird.
  • Verarbeitung. AppSignal wartet eine Minute, bis die Daten von all Ihren Servern eingetroffen sind, bevor es sie auswertet.
  • warm-up. Die Anzahl der Minuten, die AppSignal wartet, bevor der Alert geöffnet wird.
warm-up verzögert den Alert. Hat ein Trigger einen warm-up von 2 Minuten, muss die Metrik 2 Minuten lang über oder unter dem Schwellenwert bleiben, bevor AppSignal den Alert öffnet. Dies sind angemessene Zielwerte dafür, wie schnell Sie von welcher Art von Ausfall erfahren müssen:
  • Checkout oder Zahlungen defekt, sodass Kunden nicht kaufen, buchen oder Geld überweisen können. So schnell wie möglich, also wenig oder kein warm-up.
  • Site oder App nicht erreichbar. 1–2 Minuten.
  • Erhöhte Fehlerrate, sodass Kunden auf Fehler stoßen. 1–2 Minuten.
  • Verschlechterung der Antwortzeit, sodass Anfragen länger als üblich dauern. 1–3 Minuten.
  • Queue staut sich, sodass Arbeit noch verarbeitet wird, aber verspätet ankommt. 1–3 Minuten.
  • Festplattennutzung nähert sich der Kapazitätsgrenze. 10–60 Minuten.
Wenn ein Alert störend ist, aber auch schnell sein muss, lösen Sie das nicht mit einem längeren warm-up. Grenzen Sie stattdessen den Umfang ein oder verschieben Sie den Schwellenwert – beides reduziert Fehlalarme, ohne Erkennungszeit zu kosten.
Anomaly detection kann Ihnen nicht sagen, dass etwas innerhalb eines Zeitfensters nicht passiert ist, das kürzer ist als die Daten, die sie erhält. Verwenden Sie einen langen warm-up nicht als Ersatz für Check-ins, wenn Sie geplante Arbeit überwachen.

​
Einen Alert prüfen, bevor Sie sich darauf verlassen

Ein Trigger, der auf nichts passt, kann wie ein gesundes System aussehen. Bevor Sie einen Alert als Abdeckung zählen, bestätigen Sie all das Folgende:
  1. Die Chart-Vorschau zeigt Daten. Eine leere Vorschau im Trigger-Formular bedeutet, dass der Trigger derzeit auf nichts passt.
  2. Der hostname löst auf. Wenn das hostname-Feld warnt, dass der Host nicht gefunden wurde, beobachtet der Trigger wahrscheinlich eine Maschine, die umbenannt oder ersetzt wurde.
  3. Die Tag-Kombination ist bekannt. AppSignal warnt, wenn eine Tag-Kombination in der letzten Stunde nicht gesehen wurde. Verwenden Sie eine der im Trigger-Formular aufgeführten Tag-Key-Kombinationen und setzen Sie jeden Wert auf einen exakten Wert oder einen Wildcard.
  4. Ein notifier ist angehängt. Ein Trigger ohne notifier zeichnet Alerts auf, ohne Benachrichtigungen zu senden.
  5. Der notifier funktioniert. Senden Sie eine Testbenachrichtigung und bestätigen Sie, dass sie im erwarteten Kanal ankommt und nicht in einem, der ähnlich aussieht.
  6. Bei Absence-Alerts sind fehlende Daten behandelt. Bestätigen Sie für jeden Trigger, dessen Schwellenwert null oder ein Mindestwert ist, dass treat missing datapoints as 0 aktiviert ist, sonst öffnet er genau in dem Fall nicht, für den Sie ihn gebaut haben.

​
Alerting nach der Einrichtung pflegen

Alerting ist nicht fertig, wenn es eingerichtet ist.
  • Schreiben Sie das Runbook in den Trigger. Ein Name, der sagt, was falsch ist, eine Beschreibung, die sagt, was zu tun ist, und ein verlinktes Dashboard. Behandelt unter Die Benachrichtigung soll sich selbst erklären.
  • Justieren Sie nicht während eines Vorfalls nach. Das Ändern von Trigger-Einstellungen kann den Alert beeinflussen, den Sie gerade verfolgen, einschließlich des Schließens oder Ersetzens des aktiven Alert-Zustands.
  • Prüfen Sie vierteljährlich. Alerting verfällt, während Hosts ersetzt, Services umbenannt und Traffic wächst. Die Prüf-Checkliste behandelt, worauf zu achten ist.
  • Fügen Sie nach jedem Vorfall einen Alert hinzu und entfernen Sie auch einen. Die Nachbetrachtung eines Vorfalls ist der beste Zeitpunkt, sowohl zu bemerken, was fehlte, als auch, was ohne Handlungsbedarf geöffnet wurde.

​
Nächste Schritte