Skip to main content
Diese Seite gibt für jeden Alert, den die meisten Produktionsanwendungen benötigen, eine Startkonfiguration. Jede Vorlage nennt, was der Trigger misst, wann sich die Einrichtung lohnt, und Werte, mit denen Sie beginnen können. Behandeln Sie die Werte als Ausgangspunkte. Stellen Sie die Metrik über mindestens zwei Wochen grafisch dar, bevor Sie sich auf einen Schwellenwert festlegen, und passen Sie sie dann anhand der Hinweise unter Alerts optimieren an. Mit welcher Vorlage Sie auch beginnen: Geben Sie dem Trigger einen Namen, der sagt, was falsch ist, eine Beschreibung, die sagt, was dagegen zu tun ist, und ein verlinktes Dashboard. Diese drei Felder machen aus der resultierenden Benachrichtigung etwas, worauf eine reagierende Person handeln kann, und sie sind unter Die Benachrichtigung soll sich selbst erklären behandelt.

​
Die vier Alerts, die Sie zuerst einrichten

Wenn Sie Alerting von Grund auf einrichten, decken diese vier die meisten realen Vorfälle ab:
  1. Ein uptime monitor auf einem Health-Check-Endpoint.
  2. Ein Fehlerraten-Trigger auf Ihrem web-namespace.
  3. Ein p95-Antwortzeit-Trigger auf nutzerorientiertem Traffic.
  4. Check-ins für geplante Jobs.
Fügen Sie Host- und saturation-Alerts hinzu, sobald diese stabil sind. Alle Vorlagen dieser Seite auf einmal hinzuzufügen ist ein zuverlässiger Weg, Alert-Müdigkeit zu erzeugen.

​
Ist die App erreichbar?

Verwenden Sie: Uptime monitoring Eine externe Prüfung, ob Ihr Endpoint noch antwortet. Es ist der einzige Alert, der noch funktioniert, wenn Ihre App überhaupt nichts an AppSignal senden kann, weshalb die meisten Teams ihn zuerst einrichten. AppSignal ruft die URL jede Minute aus vier Regionen ab und meldet einen Fehler, wenn die Antwort nicht im 2xx-Bereich liegt oder nicht innerhalb von 30 Sekunden eintrifft. Jede Region wird separat verfolgt, sodass ein Monitor einen Alert pro fehlschlagender Region öffnet. Ein echter Ausfall öffnet bis zu vier Alerts, und ein Netzwerkproblem zwischen einer Region und Ihrem Endpoint öffnet einen Alert, während es Ihrer Anwendung gut geht. Das ist der Hauptgrund, bei uptime monitors einen warm-up zu setzen: Ein Fehler in einer einzelnen Region, der sich innerhalb einer Minute auflöst, sendet keine Benachrichtigung. Ein uptime monitor erzeugt außerdem Metriken mit Tags für Region und Monitor-Name, sodass Sie Anomaly-detection-Trigger auf die Antwortzeit pro Region hinzufügen können, wenn Sie feineres Alerting als „erreichbar oder nicht” benötigen. Die Überwachung des Ablaufs von SSL-Zertifikaten ist als AppSignal Labs-Funktion verfügbar. Nach der Aktivierung schalten Sie sie für einen einzelnen https://-Monitor ein, anstatt einen Trigger von Hand zu bauen, und AppSignal benachrichtigt Sie, wenn das Zertifikat weniger als 14 Tage Restlaufzeit hat, über dieselben notifier wie der Monitor. Ein ablaufendes Zertifikat ist ein sich langsam entwickelndes Problem, leiten Sie es daher an E-Mail oder Chat statt an On-Call.

​
Stoßen Nutzer auf Fehler?

Verwenden Sie: Einen Anomaly-detection-Trigger auf die Fehlerrate, eingegrenzt auf einen namespace Die Fehlerrate ist der schnellste Indikator dafür, dass Nutzer Fehler erleben, und sie bleibt aussagekräftig, während sich der Traffic verändert. Der vorgeschlagene Trigger in AppSignal beginnt bei 20 %, was absichtlich zurückhaltend ist, damit eine neue App nicht sofort Alerts erzeugt. Senken Sie ihn, sobald Sie Ihre Baseline kennen. Erstellen Sie einen separaten, nachsichtigeren Trigger für background. Job-Fehler werden meist erneut versucht, sie rechtfertigen daher selten dieselbe Dringlichkeit wie fehlschlagende Web-Anfragen. Zwei Fehlerraten-Trigger mit unterschiedlichen Schwellenwerten funktionieren gut, solange jeder ein anderes Ziel hat. Ein Trigger an Ihrer normalen Verschlechterungsgrenze geht an den Chat, und ein zweiter an einem viel höheren Schwellenwert, etwa 50 %, bedeutet ein schwerwiegendes Problem und sollte On-Call benachrichtigen. Zwei Schwellenwerte, die auf denselben notifier zeigen, verdoppeln nur die Benachrichtigungen.

​
Wann Sie stattdessen die Fehleranzahl verwenden

Die Fehleranzahl überschreitet einen festen Schwellenwert immer dann, wenn der Traffic wächst, und benachrichtigt Sie so an geschäftigen Tagen, unabhängig davon, ob etwas nicht stimmt. Verwenden Sie sie nur dort, wo jedes Auftreten zählt und das Volumen naturgemäß niedrig ist, etwa in einem Zahlungs- oder Anmelde-namespace. Grenzen Sie sie eng ein und setzen Sie einen niedrigen Schwellenwert.

​
Werden Anfragen langsam?

Verwenden Sie: Einen Anomaly-detection-Trigger auf die Performance, gemessen in Millisekunden Durchschnittswerte verbergen langsame Anfragen für einen Teil Ihres Traffics. Wenn eine von 20 Anfragen 8 Sekunden dauert, während der Rest schnell ist, bewegt sich der Durchschnitt kaum, aber 5 % der Nutzer erleben eine langsame Anfrage. Perzentile lösen das. Ein p95 von 400 ms bedeutet, dass 95 von 100 Anfragen innerhalb von 400 ms fertig waren und die langsamsten fünf länger brauchten. Alarmieren Sie bei p90 oder p95 statt beim Durchschnitt, damit Sie ein Problem bemerken, das einen Teil Ihres Traffics betrifft. Der von AppSignal vorgeschlagene Trigger verwendet einen Mittelwert über 500 ms, was ein sinnvoller erster Alert ist, eine teilweise Verschlechterung aber übersieht. Wechseln Sie zu p95, sobald Sie eine Baseline haben. Um einen einzelnen kritischen Pfad statt eines ganzen namespace zu beobachten, verwenden Sie einen auf eine Action eingegrenzten Performance-Trigger. Checkout, Anmeldung und Suche sind übliche Kandidaten. Geben Sie jedem einen passenden Schwellenwert: Eine Seite, die eine Drittanbieter-API aufruft, darf berechtigterweise 10 Sekunden brauchen, eine Startseite nicht.

​
Ist der Traffic verschwunden?

Verwenden Sie: Einen Anomaly-detection-Trigger auf den throughput, gemessen in Anfragen pro Minute Ein starker Einbruch des throughput bedeutet meist, dass ein Fehler auftrat, bevor Anfragen Ihre App erreichten: eine abgelaufene Domain, ein falsch konfigurierter Load Balancer oder ein CDN-Ausfall. Dieser Fehler ist für Ihre anderen Alerts unsichtbar, denn eine App, die keinen Traffic erhält, meldet keine Fehler und keine langsamen Anfragen. Legen Sie den Schwellenwert anhand Ihrer ruhigsten Phase fest, nicht anhand Ihres Durchschnitts, sonst benachrichtigt der Trigger Sie jede Nacht. Wenn Ihr Traffic zu stark schwankt, damit eine feste Untergrenze funktioniert, alarmieren Sie stattdessen darauf, dass der Traffic genau null erreicht, wie im folgenden Abschnitt beschrieben.

​
Auf zu hohen Traffic alarmieren

Traffic weit über Ihrer normalen Spitze kann ebenfalls einen Trigger brauchen. Er kann aus erwartetem Wachstum stammen, etwa einer erfolgreichen Kampagne, oder aus einem Problem, etwa einem Bot, der Ihren Katalog abgreift, oder einem Client, der in einer Schleife wiederholt. In beiden Fällen hilft der Alert, zu reagieren, bevor der Traffic Ihre Kapazität erschöpft. Setzen Sie den Vergleich auf More than mit einem Schwellenwert deutlich über Ihrer geschäftigsten normalen Stunde und leiten Sie ihn an den Chat. Er ist selten dringend genug für eine On-Call-Benachrichtigung, erklärt aber viele andere Alerts, die kurz darauf eintreffen.

​
Hat die Aktivität aufgehört?

Verwenden Sie: Einen Anomaly-detection-Trigger mit einem Schwellenwert von genau null Einige der wertvollsten Alerts betreffen Abwesenheit statt Übermaß. Ein Queue-Consumer, der nicht mehr konsumiert, ein namespace, der keinen Traffic mehr erhält, oder eine Pipeline-Stufe, die keine Ausgabe mehr produziert, können keine Fehler, keine langsamen Anfragen und keine saturation zeigen. Die fehlende Aktivität ist das Problem. Die Aktivierung von treat missing datapoints as 0 ist es, was das funktionieren lässt. Ohne sie sendet eine Metrik, die vollständig aufhört zu melden, keine Datenpunkte, der Trigger hat also nichts auszuwerten und der Alert öffnet nie. Mit ihr behandelt AppSignal fehlende Daten als null und der Alert öffnet wie beabsichtigt. Gute Kandidaten sind throughput pro namespace, ein Counter erfolgreich verarbeiteter Jobs oder eine Prozessanzahl, die niemals auf null fallen sollte. Dieses Muster ist außerdem der zuverlässige Weg, einen Worker zu bemerken, der gestorben ist statt langsamer geworden.
Verwenden Sie das für kontinuierliche Arbeit, die immer stattfinden sollte. Verwenden Sie für Arbeit, die nach einem Zeitplan läuft, stattdessen Check-ins, die dafür gebaut sind und keinen warm-up brauchen, der lang genug ist, um die Lücke zwischen Läufen zu überbrücken.

​
Staut sich Arbeit?

Verwenden Sie: Einen Anomaly-detection-Trigger auf die Queue-Zeit, gemessen in Millisekunden Die Queue-Zeit misst, wie lange eine Anfrage oder ein Job gewartet hat, bevor Ihre App mit der Verarbeitung begann. Steigende Queue-Zeit ist eine Frühwarnung, dass die Kapazität knapp wird, meist bevor Antwortzeiten oder Fehlerraten reagieren. Ihre App meldet möglicherweise keine Fehler und keine langsamen Anfragen, während Nutzer weiterhin warten: eine Bestellung, die Stunden nach der Aufgabe bestätigt wird, oder ein Bericht, der einen Tag zu spät kommt. In der Praxis ist die Queue-Tiefe oft das einfachere Signal, auf das man alarmiert. Wenn Sie die Anzahl ausstehender Jobs oder unverarbeiteter Nachrichten bereits als benutzerdefinierte Metrik erfassen, ist ein Tiefen-Schwellenwert konkret, leicht nachvollziehbar und leicht aus der Historie festzulegen. Taggen Sie ihn nach Queue-Namen, damit ein backlog in einer Queue nicht wie ein allgemeiner Ausfall wirkt. Verwenden Sie beides, wo Sie können. Die Tiefe sagt Ihnen, dass der backlog wächst; die Queue-Zeit sagt Ihnen, dass er bereits jemanden betrifft.

​
Gehen Hosts die Ressourcen aus?

Verwenden Sie: Host-Metrik-Trigger Host-Alerts beschreiben Ursachen statt für Nutzer sichtbarer Symptome, leiten Sie sie daher an Kanäle mit geringerer Dringlichkeit als nutzerorientierte Alerts. Ein Host bei 95 % CPU mit gesunden Antwortzeiten ist kein Vorfall. Host-Alerts sind nützlich, weil sie warnen, bevor eine Ressource vollständig aufgebraucht ist – dann kann eine App abrupt stoppen und andere Alerts können gleichzeitig zu öffnen beginnen. Jeder Host-Trigger akzeptiert einen hostname, und sein Standardwert * passt auf jeden Host. Setzen Sie einen konkreten Namen oder ein Präfix wie web-*, sofern Sie nicht wirklich einen Alert pro Host in der Flotte wünschen.

​
Festplattennutzung

Das ist der klarste Host-Alert zum Konfigurieren, weil eine volle Festplatte zuverlässig Fehler verursacht und die Festplattennutzung oft vorhersehbar steigt. Legen Sie den Schwellenwert danach fest, wie schnell sich die Festplatte füllt, nicht danach, wie voll sie ist. Ein Allzweck-Host, der pro Woche einen Prozentpunkt zulegt, ist bei 80 % in Ordnung. Ein Datenbank- oder Queue-Host, der in einer Stunde 20 Punkte zulegen kann, muss Sie bei 60 % warnen, weil die verbleibende Zeit wichtiger ist als der verbleibende Platz. Das bedeutet meist mehrere Festplatten-Trigger statt einem, jeder über einen Wildcard auf eine Host-Gruppe eingegrenzt, etwa db-* bei 60 % und web-* bei 80 %. Setzen Sie außerdem einen Trigger pro mountpoint, der Sie interessiert. Ein Trigger ohne mountpoint-Tag passt auf jedes gemountete Dateisystem, einschließlich kurzlebiger Container-Mounts.

​
Speichernutzung

Prozentwerte lassen sich meist leichter über unterschiedlich große Hosts hinweg wiederverwenden. Absolute Werte sind besser, wenn Sie wissen, wie viel freie Kapazität ein bestimmter Workload benötigt.

​
Swap-Nutzung

Wenn einem Server der Speicher knapp wird, beginnt er, Daten auf die Festplatte zu verschieben, was weit langsamer ist als Speicher. Die Anwendung arbeitet weiter, es tritt also möglicherweise kein Fehler auf, aber Anfragen können langsamer werden. Hier zu alarmieren ist nützlich, weil die Auswirkung allmählich und leicht zu übersehen sein kann. Der vorgeschlagene Trigger in AppSignal benachrichtigt Sie, wenn ein Host überhaupt Swap verwendet, was ein sinnvoller Weg ist herauszufinden, ob Ihre Hosts swappen. Er ist auf Dauer meist zu empfindlich: Viele gesunde Hosts allozieren etwas Swap und berühren ihn nie wieder. Wechseln Sie, sobald Sie Ihre Baseline kennen, zu einem prozentualen Schwellenwert, damit der Alert bei echtem Speicherdruck öffnet und nicht für ein paar beim Booten allozierte Megabytes.

​
CPU-Nutzung und Load Average

Der Agent meldet CPU pro Zustand statt als einzelnen Gesamtwert, wählen Sie also den Zustand, der die Arbeit beschreibt, die Sie interessiert, und verwenden Sie iowait, wenn Sie vermuten, dass der Host auf die Festplatte wartet statt zu rechnen. Kurze CPU-Anstiege sind normal. Nur dauerhaft hohe CPU-Nutzung braucht meist eine Benachrichtigung, und selbst dann gehört sie in den Chat statt an On-Call, sofern sie nicht bereits die Antwortzeiten beeinträchtigt. Load Average ist auf Datenbank- und Worker-Hosts oft das nützlichere der beiden, weil es Prozesse zählt, die auf die Festplatte warten, und nicht nur solche, die auf die CPU warten. Er ist allerdings nicht über Maschinen hinweg vergleichbar: Ein Load Average von 60 bedeutet saturation auf einem Host mit 16 Kernen und ist gesund auf einem mit 128. Grenzen Sie einen Load-Average-Trigger über einen Wildcard auf eine Host-Klasse ein und legen Sie den Schwellenwert anhand der Kern-Anzahl dieser Maschine fest, statt einen einzelnen Trigger über eine gemischte Flotte laufen zu lassen.

​
Festplatten- und Netzwerk-throughput

Die Trigger für Festplatten-I/O und Netzwerk-Traffic erfassen von jeder Festplatte gelesene und auf sie geschriebene Daten sowie über jedes Netzwerk-Interface empfangene und gesendete Daten. Für die meisten Teams ergeben diese bessere Dashboard-Grafiken als Alerts, weil ein sinnvoller Schwellenwert stark vom Workload abhängt. Alarmieren Sie darauf, wenn Sie eine bekannte Obergrenze haben, etwa ein bereitgestelltes IOPS-Limit.

​
Ist geplante Arbeit gelaufen?

Verwenden Sie: Check-ins Anomaly detection kann Ihnen nicht zuverlässig sagen, dass geplante Arbeit nicht stattgefunden hat, weil ein Trigger nur eintreffende Daten auswertet. Verwenden Sie dafür Check-ins.
  • Cron-Check-in, für Jobs, die nach einem Zeitplan laufen. Die wichtige Einstellung ist der Cron-Ausdruck plus eine Zeitzone.
  • heartbeat-Check-in, für Worker und Prozesse, die weiterlaufen sollen. Die wichtige Einstellung ist die maximale Dauer seit dem letzten heartbeat.
Beide verwenden eine Maximum duration in Minuten statt eines warm-up. Bei einem Cron-Prozess-Monitor meldet AppSignal einen Fehler, wenn zwischen der vom Zeitplan festgelegten Startzeit und dem Ende dieser Dauer kein Ereignis eintrifft. Bei einem heartbeat meldet es einen Fehler, wenn innerhalb dieser Dauer nach dem letzten kein Ereignis eintrifft. Setzen Sie sie länger als die normale Schwankung des Jobs bei Startzeit und Laufzeit, damit ein Job, der gelegentlich einige Minuten zu spät läuft, niemanden benachrichtigt. Gute Kandidaten sind nächtliche Abrechnungsläufe, Backups, Datenexporte, Cache-Warmer und jeder langlaufende Consumer.

​
Fällt eine einzelne Abhängigkeit aus?

Verwenden Sie: Log triggers Manche Fehler werden nie zu einem Incident oder einer Metrik. Ein Zahlungsanbieter, der einen Timeout hat und beim Retry erfolgreich ist, hinterlässt keinen Fehler und keinen Latenzausschlag, der groß genug wäre, um bemerkt zu werden – ein anhaltendes Muster ist aber wissenswert. Beginnen Sie mit der Query, die die Zeilen findet. Wenn Sie sie sich bereits im Terminal ansehen, ist diese Query die, die Sie haben:
Shell
Sobald die Query nur die erwarteten Zeilen findet, erstellen Sie daraus den Trigger. Derselbe Query-Text wird wiederverwendet:
Shell
Um dasselbe in der Oberfläche zu tun, filtern Sie die Logs-Seite auf die Zeilen, die Sie interessieren, wählen Sie eine aus, um Log details zu öffnen, und erstellen Sie den Trigger im Abschnitt Actions, der Ihre Query, Severity und Quelle übernimmt. Den vollständigen Ablauf finden Sie unter Log triggers. Log triggers funktionieren anders als Metrik-Trigger, und der Unterschied ist für das Rauschen bedeutsam. Ein Log trigger wird gegen einzelne Log-Zeilen ausgewertet, während sie eintreffen, er hat daher nicht die warm-up- und cooldown-Einstellungen von Anomaly-Triggern. Steuern Sie das Benachrichtigungsvolumen stattdessen über die Schwellenwert-Einstellung:
  • First After Close für ein Problem, das sich von selbst erholt, sodass Sie eine Benachrichtigung erhalten, jedes Mal wenn das Problem nach dem Schließen zurückkehrt.
  • Nth in an hour für ein Log-Muster, das absichtlich zeitweise passt und bei dem die Anzahl passender Log-Zeilen das wichtige Signal ist.
  • Every Occurrence nur dort, wo eine einzelne Zeile wirklich zählt.
Verwenden Sie Never Notify für Muster, die Sie verfolgen und zählen möchten, ohne jemanden zu benachrichtigen.

​
warm-up und cooldown für Log-Daten erhalten

Wenn ein Log-Muster für jeden dieser Schwellenwerte zu störend ist, wandeln Sie es in eine Metrik um, anstatt direkt bei den Log-Zeilen zu alarmieren. Extrahieren Sie eine log-basierte Metrik aus den passenden Zeilen und richten Sie dann einen Anomaly-detection-Trigger auf diese Metrik. Das sind zwei Befehle. Zählen Sie zuerst die passenden Zeilen in eine Metrik. Ein counter braucht kein Feld, weil er Zeilen zählt statt einen Wert aus ihnen zu lesen:
Shell
Alarmieren Sie dann auf diese Metrik, wo warm-up und cooldown verfügbar werden:
Shell
Das gibt aus Logs abgeleiteten Daten den vollständigen Zustandsautomaten: einen Schwellenwert, einen warm-up, damit ein kurzer Anstieg ignoriert wird, und einen cooldown, damit ein wiederkehrendes Problem einen Alert erzeugt. Das ist der empfohlene Ansatz für eine Abhängigkeit, die mehrmals täglich in kurzen Phasen ausfällt.

​
Stimmt eine Geschäftsmetrik nicht?

Verwenden Sie: Einen Anomaly-detection-Trigger auf eine benutzerdefinierte Metrik Benutzerdefinierte Metriken sind der einzige Weg, bei anwendungsspezifischen Werten zu alarmieren, die AppSignal nicht ableiten kann, etwa erfolgreiche Zahlungen pro Minute, Anmeldungen oder die Größe einer Arbeits-Queue. Das ist der eine Fehler, den kein anderer Alert auf dieser Seite erkennen kann. Wenn eine Änderung bei Ihrem Zahlungsanbieter beginnt, jede Transaktion abzulehnen, bleibt Ihre App erreichbar, schnell und fehlerfrei, während nichts verkauft wird – nur eine Metrik, die Sie selbst senden, kann das erkennen. Stellen Sie die Metrik zuerst grafisch dar und legen Sie den Schwellenwert dann anhand des Gesehenen fest. Um eine benutzerdefinierte Metrik in der Alerting-Oberfläche zu prüfen, öffnen Sie Anomaly detection, gehen Sie zu Triggers, wählen Sie Add trigger und dann Custom metrics unter Other. Geben Sie den Metriknamen ein und bestätigen Sie über die Chart-Vorschau und die Tag-Kombinationen, dass AppSignal die Metrik erhalten hat.

​
Nächste Schritte