| System | Verwenden Sie es für | Beispiel |
|---|---|---|
| Uptime monitoring | Eine externe Prüfung, ob Ihre öffentlichen Endpoints noch antworten | Alert, wenn ein Health-Check-Endpoint aus keiner Region mehr eine 2xx-Antwort zurückgibt |
| Incident notifications | Fehler- und Performance-Incidents, die AppSignal in Ihrer App bereits erkennt | Benachrichtigen Sie das Team, wenn ein Fehler zum ersten Mal nach einem Deploy auftritt oder wenn ein geschlossener Incident wieder auftritt |
| Anomaly detection triggers | Schwellenwert-Alerts auf integrierte und benutzerdefinierte Metriken | Alert, wenn die Fehlerrate über 5% bleibt, die p95-Antwortzeit steigt, der throughput fällt oder die Festplattennutzung 85% überschreitet |
| Log triggers | Muster in Logs, die alarmieren sollen, auch wenn sie nie zu einem incident oder zu einer Metrik werden | Alert, wenn ein Zahlungsanbieter wiederholt Timeouts protokolliert |
| Check-in triggers | Cron-Jobs, heartbeats und andere Prozesse, die pünktlich melden sollen | Alert, wenn ein nächtlicher Job nicht fertig wird oder ein Worker keine heartbeats mehr sendet |
Was Alerts sind
Alerts verwandeln Telemetriedaten in Handlungen. Sie helfen Ihnen, Fragen wie diese zu beantworten:- Ist die App nicht erreichbar?
- Sehen Nutzer mehr Fehler als üblich?
- Ist der Traffic gefallen, weil etwas Vorgelagertes ausgefallen ist, bevor die Anfragen die App erreichten?
- Staut sich eine background-Warteschlange?
- Läuft ein geplanter Job nicht mehr?
Das richtige Alerting-System wählen
Verwenden Sie Incident notifications, wenn AppSignal bereits einen incident hat und Sie steuern möchten, wer wie oft benachrichtigt wird. Dies ist eine solide Standardoption für Exceptions und langsame Actions, von denen Sie bereits wissen, dass sie wichtig sind. Verwenden Sie Anomaly detection triggers, wenn Sie schwellenwertbasiertes Alerting für Metriken wünschen. Dies ist die flexibelste Option für eine SRE-orientierte Abdeckung, einschließlich Fehlerrate, Antwortzeit-Perzentile, throughput, Queue-Zeit, host-Metriken und benutzerdefinierten Metriken. Verwenden Sie Log triggers, wenn das Signal in Logs existiert, aber noch nicht als eigener incident oder als Metrik. Sie eignen sich gut für integrationsspezifische Ausfälle, etwa wenn eine Bank oder ein Anbieter Timeouts hat, während der Rest des Systems gesund erscheint. Verwenden Sie Check-in triggers, wenn Erfolg bedeutet, „dieser Prozess hat pünktlich gemeldet”. Sie sind das richtige Werkzeug für Cron-Jobs, heartbeats, Worker und geplante Aufgaben.Ein praktisches Starter-Set
Für die meisten Produktions-Apps sieht ein nützliches Starter-Set so aus:- Eine uptime-Prüfung für Ihren öffentlichen Health-Check-Endpoint.
- Ein anomaly trigger für die
web-Fehlerrate. - Ein anomaly trigger für die
p90- oderp95-Antwortzeit auf kritischem, nutzerorientiertem Traffic. - Ein anomaly trigger für throughput-Einbrüche.
- Ein anomaly trigger für Queue-Zeit, Queue-Tiefe oder background-Job-backlog.
- Host-Metrik-Trigger für CPU, Speicher und Festplatte.
- Check-ins für Cron-Jobs, geplante Aufgaben und langlaufende Worker.
Beliebte Alerts für den Einstieg
Dies sind gängige erste Alerts für Teams, die eine breite Abdeckung ohne zu viel Rauschen wünschen:| Alert | Warum er hilft | AppSignal-Funktion |
|---|---|---|
Fehlerrate im web-namespace | Das schnellste Signal, dass Nutzer auf Fehler stoßen | Anomaly detection trigger |
p90- oder p95-Antwortzeit für kritische Actions | Durchschnittswerte verbergen eine langsame Erfahrung für einen Teil Ihres Traffics | Anomaly detection trigger |
| Throughput-Einbruch | Ein starker Einbruch bedeutet oft, dass etwas Vorgelagertes ausgefallen ist, bevor Anfragen Ihre App erreichten | Anomaly detection trigger |
| Queue-Zeit oder wachsender backlog | Frühwarnung, bevor Nutzer Verzögerungen bemerken | Anomaly detection trigger |
| CPU-, Speicher- und Festplattennutzung | Infrastruktur-Frühwarnung bei saturation und Kapazitätsproblemen | Anomaly detection trigger |
| Health-Check-Endpoint schlägt fehl | Bestätigt, dass die App von außerhalb Ihrer Infrastruktur nicht erreichbar ist | Uptime monitoring |
| Fehlender heartbeat von Cron-Job oder Worker | Bestätigt, dass die erwartete background-Arbeit weiterhin läuft | Check-in trigger |
Wofür SREs typischerweise eine Abdeckung wünschen
Wenn Sie die Alert-Abdeckung von Grund auf aufbauen, sind dies die üblichen Prioritäten:- Für Nutzer sichtbare Fehler
- Langsame Nutzeranfragen, insbesondere bei
p90oderp95 - Traffic-Einbrüche und ungewöhnliche throughput-Änderungen
- Wachstum von background-Queues und verzögerte Jobs
- Host-saturation wie CPU, Speicher und Festplatte
- Geplante Jobs, die nicht starten, nicht fertig werden oder nicht melden
- Probleme mit externen Abhängigkeiten wie langsame Bank-APIs, Timeouts oder Retry-Stürme
Alerts erfolgreich konfigurieren
Gutes Alerting dreht sich vor allem um Umfang und Routing:- Fügen Sie zunächst notifier auf den Seiten Integrations und Notifications hinzu. Jeder Trigger kann einen anderen notifier verwenden, sodass Sie nach Schweregrad routen können.
- Senden Sie dringende Produktions-Alerts an ein On-Call-Tool wie PagerDuty, Opsgenie oder einen anderen Webhook-notifier.
- Senden Sie Warnungen und Verschlechterungen an Chat oder E-Mail, zum Beispiel Slack. Geben Sie Staging einen eigenen Kanal oder schalten Sie es stumm.
- Legen Sie Benachrichtigungs-Defaults pro namespace fest, damit
web,backgroundundadminstandardmäßig unterschiedliche Teams benachrichtigen können. - Beginnen Sie mit Alerts, die an die Nutzerauswirkung gekoppelt sind, und ergänzen Sie später engere operative Prüfungen, sobald Sie sehen, was nützlich ist.
Störende Alerts vermeiden
Das ist der Teil, der einen nützlichen Alert von einem unterscheidet, den das Team ignorieren lernt:- Legen Sie Schwellenwerte anhand echter Historie fest, nicht durch Raten. Sehen Sie sich den Verlauf der Metrik über einige Wochen an, bevor Sie einen Schwellenwert wählen.
- Verwenden Sie warm-up-Fenster, damit eine Bedingung mehrere Minuten anhalten muss, bevor der Alert geöffnet wird. Drei bis fünf Minuten sind ein üblicher Startpunkt, und die meisten Fehlalarme sind einminütige Ausreißer.
- Verwenden Sie mindestens einen einminütigen warm-up bei uptime-Monitoren, um kurze Netzwerkschluckauf zu überbrücken.
- Fügen Sie einen cooldown hinzu, damit ein flatterndes Signal zu einem längeren Alert wird, anstatt sich wiederholt zu öffnen und zu schließen.
- Bevorzugen Sie Raten gegenüber absoluten Zählwerten, wenn sich der Traffic im Tagesverlauf ändert. Die Fehlerrate ist meist nützlicher als die reine Fehleranzahl.
- Bevorzugen Sie
p90oderp95für latenz-sensitive Alerts, statt sich auf Durchschnittswerte zu verlassen. - Grenzen Sie Alerts nach namespace, Action oder Tags ein, damit die Benachrichtigung genau sagt, was betroffen ist.
- Ein guter, anhaltender Alert ist besser als fünf zappelige. Senden Sie nur dringende, kundenrelevante Alerts an On-Call und alles andere an den Chat.
Uptime monitoring einrichten
- Erstellen Sie einen dedizierten Health-Check-Endpoint, falls Sie noch keinen haben.
- Fügen Sie einen uptime monitor für diesen Endpoint hinzu.
- Wählen Sie einen notifier für Downtime-Benachrichtigungen.
- Legen Sie mindestens einen einminütigen warm-up fest, damit kurze Netzwerkschluckauf keine Alerts öffnen.
- Ignorieren Sie den Health-Check-Endpoint in Ihrer AppSignal-App, wenn Sie diese Anfragen nicht auf Ihr monatliches Anfragevolumen anrechnen möchten.
Beispiele
Beispiel für eine Incident notification
Verwenden Sie Incident notifications, wenn AppSignal bereits einen Fehler- oder Performance-incident erstellt hat und Sie hauptsächlich das richtige Benachrichtigungsverhalten benötigen. Zum Beispiel:- Verwenden Sie First in Deploy für Produktionsfehler, die nur einmal pro Release alarmieren sollen.
- Verwenden Sie First After Close für Incidents, die durch externe Systeme verursacht werden und sich ohne deploy erholen können.
- Verwenden Sie Every Nth per Hour oder Every Nth per Day für laute bekannte Fehler, bei denen das Volumen wichtiger ist als jedes einzelne Auftreten.
Beispiel für einen Log trigger
Verwenden Sie Log triggers, wenn Logs das Signal enthalten, das Sie benötigen. Zum Beispiel kann ein Zahlungs- oder Anmeldeprozess erneut versuchen, wenn eine Bank-API langsam ist, sodass ein einzelner Fehler möglicherweise keinen dringenden Page rechtfertigt, ein anhaltendes Muster jedoch schon.SQL
Beispiel für einen Alert auf eine benutzerdefinierte Metrik
Wenn Sie benutzerdefinierte Metriken senden, können Sie mit Anomaly detection darauf alarmieren. Zum Beispiel könnten Sie senden:- Einen Counter für erfolgreiche Zahlungen oder Anmeldungen
- Ein Gauge für Queue-Tiefe oder aktive Worker-Anzahl
- Eine Measurement für die Antwortzeit des Anbieters
- Stellen Sie sie zuerst grafisch dar und prüfen Sie ihre jüngste Historie.
- Wählen Sie das Feld, das zu Ihrer Fragestellung passt:
gauge,counter,count,mean,p90oderp95. - Filtern Sie nach Tags wie
provider=bank-aoderregion=eu, wenn Sie einen engeren Alert benötigen. - Fügen Sie den passenden notifier für den Schweregrad des Problems hinzu.
- Fügen Sie warm-up und cooldown hinzu, bevor Sie sich in der Produktion auf den Alert verlassen.
Nächste Schritte
- Sehen Sie sich die Benachrichtigungseinstellungen für incident-basiertes Alerting an.
- Erstellen Sie Anomaly detection triggers für Metriken und Schwellenwerte.
- Richten Sie Uptime monitoring für eine externe Health-Prüfung ein.
- Erstellen Sie Process Monitoring und Check-ins für Cron-Jobs und heartbeats.
- Verwenden Sie Log triggers für Log-basiertes Alerting.