Alarmzustände
Alerts können fünf Zustände haben:
Wann werde ich benachrichtigt?
AppSignal benachrichtigt Sie bei zwei Zustandsübergängen: wenn ein Alert öffnet und wenn er behoben ist. E-Mail kann zusätzlich Erinnerungen senden, solange ein Alert offen bleibt. Jeder andere Kanal, einschließlich Slack, PagerDuty, Opsgenie und Webhooks, wird nur bei den Übergängen „geöffnet” und „behoben” benachrichtigt. Alerts werden an die am Trigger ausgewählten notifier gesendet, nicht an jeden für die App konfigurierten notifier.Einen Trigger stummschalten
Anders als Fehler-Incidents haben Alerts keine Optionen zur Benachrichtigungshäufigkeit. Es gibt keine Einstellung Never Notify oder Every Nth per Hour, weil Benachrichtigungen dem Alert-Zustandsautomaten folgen und nicht einer Anzahl von Vorkommen. Um zu verhindern, dass ein Trigger jemanden benachrichtigt, entfernen Sie seine notifier. Um zu verhindern, dass er überhaupt Alerts erzeugt, archivieren Sie ihn. Das Routing von Trigger-Alerts wird am Trigger selbst gesteuert. Wählen Sie die notifier aus, die Alerts von diesem Trigger erhalten sollen, oder entfernen Sie alle notifier, um den Trigger aktiv zu halten, ohne Benachrichtigungen zu senden.E-Mail-Alarme
Alert-E-Mails enthalten eine Übersicht neuer Alerts, Erinnerungen und den Status anderer Alerts, die noch nicht beendet sind.Trigger erstellen und konfigurieren
Konfigurieren Sie Anomaly detection pro App im Abschnitt „Anomaly detection” in der App-Navigation. Die Alert-Übersicht zeigt die neuesten Alerts, die von den für die App konfigurierten Triggern erstellt wurden. Öffnen Sie die Triggers-Seite, um Trigger zu erstellen und zu bearbeiten. Wählen Sie Add trigger, um die Metrik-Auswahl zu öffnen, und wählen Sie dann eine Trigger-Art unter Tracing, Host metrics oder Other. Trigger für benutzerdefinierte Metriken sind unter Other als Custom metrics aufgeführt.
- Fehlerraten
- (Absolute) Fehleranzahlen
- App-throughput
- Performance von Actions (langsame Actions)
- Queue-Zeit
- Host-Metriken
- CPU-Last
- Festplatten-I/O
- Festplattennutzung
- Load Averages
- Speichernutzung
- Netzwerknutzung
warm-up und cooldown
Sie können warm-up- und cooldown-Einstellungen für jeden Trigger konfigurieren. Diese Einstellungen legen fest, wie lange AppSignal wartet, bevor ein Alert geöffnet und geschlossen wird.warm-up
Wenn die Schwellenwertbedingung eines Triggers erreicht wird, öffnet er üblicherweise einen Alert. Zum Beispiel, wenn die Fehlerrate höher als 5 % ist. Hat ein Trigger eine warm-up-Phase, öffnet AppSignal den Alert erst, nachdem die Schwellenwertbedingung während der gesamten warm-up-Phase erfüllt geblieben ist. Zum Beispiel muss die Fehlerrate länger als 3 Minuten über 5 % bleiben. AppSignal benachrichtigt Sie, wenn der Alert-Status von warm-up zu offen wechselt.cooldown
Von einem Trigger geöffnete Alerts werden automatisch geschlossen, wenn die Schwellenwertbedingung nicht mehr erfüllt ist. Konfigurieren Sie eine cooldown-Phase, um wiederholte Öffnungs- und Schließbenachrichtigungen für dasselbe Problem zu vermeiden. Wenn Sie eine cooldown-Phase konfigurieren, erstellt AppSignal keinen neuen Alert, sofern die Trigger-Bedingung nicht nach Ablauf der cooldown-Phase erneut erfüllt wird. Zum Beispiel:- Ein Alert öffnet, weil die Fehlerrate höher als 5 % ist.
- Die Fehlerrate fällt, der Alert wird also geschlossen.
- Der Trigger hat eine cooldown-Phase von zwei Minuten.
- Die Fehlerrate steigt erneut über 5 %.
- AppSignal erstellt keinen neuen Alert, sofern die Fehlerrate nicht nach Ende der cooldown-Phase 5 % übersteigt.
Tags
Bei einigen Metriken müssen zusätzlich Tags ausgewählt werden. Zum Beispiel, wenn Sie eine benutzerdefinierte Metrik mit Tags an AppSignal senden:
namespace oder namespace, queue. Tag-Werte können exakte Werte wie namespace=web oder Wildcards wie queue=* sein.
Ein Trigger kann mehrere Alerts öffnen
Ein Trigger öffnet einen Alert pro passender Serie, nicht einen Alert insgesamt. Ein Trigger, der auf 30 Hosts passt, öffnet 30 Alerts, wenn alle 30 den Schwellenwert überschreiten. Bei Host-Metrik-Triggern lässt sich das leicht übersehen, weil das hostname-Feld Wildcards unterstützt und sein Standardwert* auf jeden Host passt, der an die App meldet. Geben Sie einen bestimmten hostname oder ein Präfix wie web-* ein, um zu begrenzen, welche Hosts ein Trigger erfasst.
Dasselbe gilt für Tags bei jeder anderen Metrik. Je enger der Tag-Filter, desto spezifischer der Alert und desto weniger Benachrichtigungen erzeugt ein einzelner Vorfall.
Trigger bearbeiten und archivieren
Das Ändern oder Archivieren eines Triggers kann die daran hängenden Alerts und Incidents beeinflussen. Das Bearbeiten oder Archivieren eines Triggers kann diese Auswirkungen haben:- Alerts, die sich noch in ihrer warm-up-Phase befinden, werden verworfen.
- Offene Alerts werden geschlossen und als archiviert markiert.
- Wenn Sie einen Trigger bearbeiten, werden offene Anomaly-Incidents des vorherigen Triggers mit dem neuen Trigger verknüpft, sodass Incident-Historie und Logbuch über die Bearbeitung hinweg verfügbar bleiben.
- Wenn Sie einen Trigger archivieren, ohne ihn zu ersetzen, werden offene Anomaly-Incidents dieses Triggers geschlossen.
Fehlende Datenpunkte als 0
Standardmäßig gehen Trigger davon aus, dass jede Minute ein Datenpunkt gesendet wird. Das ist in Situationen möglicherweise nicht umsetzbar, etwa wenn ein Counter nur erhöht wird, wenn eine bestimmte Action auftritt. Aktivieren Sie in diesen Fällen Treat missing datapoints as 0. AppSignal behandelt einen fehlenden Datenpunkt dann als null, was dabei hilft, dass ein Alert schließt, wenn in der nächsten Minute keine Daten eintreffen. Das ermöglicht außerdem Alerts auf Abwesenheit, etwa das Alarmieren, wenn eine Metrik0 erreicht.
Datenverarbeitung
Die Metriken, die Trigger zum Erstellen von Alerts verwenden, werden nicht sofort verarbeitet, wenn die Metriken von Ihrer Anwendung an AppSignal gesendet werden. Ihre Metrikdaten durchlaufen mehrere Systeme, bevor sie bei unserem Prozessor ankommen. Die Daten können außerdem von mehreren Servern gesendet werden, die Daten in unterschiedlichen Intervallen senden. Der Prozessor wartet dann*, bis alle Daten für eine Minute eingetroffen sind, bevor er diese Daten verarbeitet und Alerts erstellt oder aktualisiert. Wenn Sie Probleme mit den Metriken haben, die AppSignal für Anomaly detection meldet, stellen Sie sicher, dass die Server Ihrer Anwendung gleichzeitig melden, indem Sie sie über NTP konfigurieren. Falsche oder abweichende gemeldete Zeiten von mehreren App-Servern können verhindern, dass Alerts geöffnet oder geschlossen werden. Mehr darüber, wie AppSignal Daten für Anomaly detection verarbeitet und was das für die Alerts bedeutet, erfahren Sie in unserer Dokumentation zum Datenlebenszyklus. *: Weitere Informationen zu den Wartezeiten finden Sie auf unserer Seite zum Datenlebenszyklus.Vorfälle verwalten
Sie können alle Alert-Incidents auf der Seite Anomaly Issues in der AppSignal-App ansehen. Die Issues-Seite zeigt eine Übersicht aller offenen Alert-Incidents, sortiert nach ihrem letzten Auftreten, mit Spalten für die Anomalie:- Name
- Status
- Zuständige
- Zustand
- Zeitpunkt der letzten Zustandsänderung
- Alert-Informationen: Der Metrikname, der Alert-Zustand und die Tags des Alerts.
- Häufigkeitsdiagramm der Vorkommen: Eine visuelle Darstellung des Auftretens des Alerts.
- Incident-Einstellungen: Möglichkeit, den Alert zu schließen, seinen Schweregrad festzulegen und ihn einem Teammitglied zuzuweisen.
- Trigger-Informationen: Die Bedingungen, die zum Auslösen des Alerts erforderlich sind.
- Letzte Vorkommen: Eine Tabelle der neuesten Vorkommen mit Start- und Endzeit, Zustand und Spitzenwert.
- Logbuch: Ein Logbuch, um wichtige Informationen zu diesem Alert für Ihr Team oder Ihr künftiges Selbst festzuhalten.
- Zugriff auf Time Detective: Verwenden Sie Time Detective, um den Zustand Ihrer Anwendung beim letzten Auftreten des Alerts anzusehen.
