> ## Documentation Index > Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Alerting in der Produktion > Richten Sie Alerting für eine Produktionsumgebung in Schichten ein, prüfen Sie Ihre Abdeckung auf Lücken und entscheiden Sie, wie schnell Sie von welcher Art von Ausfall erfahren müssen. 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](/alerting/recipes). Wenn Sie bereits Alerts haben und diese zu störend sind, gehen Sie zu [Alerts optimieren](/alerting/tuning). ## 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](/application/markers/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**](/application/notification-settings#first-in-deploy) funktioniert. **Teilen Sie Ihre App in [namespaces](/application/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](/uptime-monitoring/setup) 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](/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](/metrics/custom) 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: | Wenn das passiert | Was es erkennt | | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Die Anwendung ist überhaupt nicht erreichbar | [Uptime monitor](/uptime-monitoring/setup) | | Die Anwendung antwortet, gibt aber Fehler zurück, sodass Aktionen wie das Hinzufügen eines Artikels zum Warenkorb fehlschlagen | Fehlerraten-Trigger auf dem nutzerorientierten namespace | | Die Anwendung antwortet langsam | `p90`- oder `p95`-Performance-Trigger | | Es kommen überhaupt keine Anfragen mehr an, weil etwas Vorgelagertes ausgefallen ist, bevor sie die App erreichten | Throughput-Untergrenze oder ein Trigger auf throughput gleich `0` | | Ein background-Worker stirbt, sodass Bestätigungs-E-Mails oder Rechnungen nicht mehr versendet werden | Absence-Alert auf einem Job-Counter oder ein heartbeat-[Check-in](/check-ins) | | Ein geplanter Job läuft nicht, sodass die heutigen Daten fehlen | Cron-[Check-in](/check-ins) | | Eine Queue staut sich, sodass Arbeit angenommen wird, aber Stunden zur Verarbeitung braucht | Trigger auf Queue-Tiefe oder Queue-Zeit | | Einem Host geht Festplatte, Speicher oder Swap aus, sodass die Anwendung abrupt stoppt | Host-Metrik-Trigger | | Eine Abhängigkeit fällt zeitweise aus, Retries gelingen aber, etwa bei einem Zahlungsanbieter oder Lieferpartner | [Log trigger](/logging/triggers) oder eine aus diesen Log-Zeilen extrahierte Metrik | | Ein Geschäftsprozess stoppt, ohne dass in AppSignal Fehler auftauchen, etwa wenn Aufträge, Zahlungen oder Buchungen nicht mehr durchgehen | Benutzerdefinierte Metrik gleich `0` oder unter einem Mindestschwellenwert | | Ein TLS-Zertifikat läuft bald ab, sodass Browser warnen, die Seite sei nicht sicher | SSL-Ablaufüberwachung, verfügbar als [AppSignal Labs](/labs)-Funktion | | Eine Metrik wird überhaupt nicht mehr gemeldet | Ein Trigger mit aktiviertem **treat missing datapoints as 0** | 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](/anomaly-detection#data-processing).** 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](/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](/alerting/tuning#make-the-notification-explain-itself). * **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](/alerting/tuning#review-triggers-regularly) 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 * Wählen Sie Konfigurationen aus den [Vorlagen für Alerts](/alerting/recipes). * Reduzieren Sie das Volumen mit [Alerts optimieren](/alerting/tuning). * Legen Sie [Benachrichtigungs-Defaults pro namespace](/application/notification-settings#organization-and-app-namespace-defaults) fest. * Richten Sie [Check-ins](/check-ins) für geplante Arbeit ein.