Mit der Anomaly detection können Sie Trigger so konfigurieren, dass Benachrichtigungen gesendet werden, wenn ein Metrikwert einen Schwellenwert überschreitet oder unterschreitet. Zum Beispiel: wenn die Fehlerrate einer Anwendung 5 % übersteigt oder der freie Speicher unter 100 MB fällt.
Anomaly detection prüft Metrikwerte einmal pro Minute. Wenn eine Metrik eine Schwellenwertbedingung erreicht, öffnet AppSignal einen Alert und benachrichtigt die ausgewählten notifier. AppSignal benachrichtigt sie erneut, wenn die Schwellenwertbedingung nicht mehr erfüllt ist.
Verwenden Sie die Einstellungen warm-up und cooldown, um zu steuern, wann ein neuer Alert geöffnet und geschlossen wird.
Hinweise zur Wahl von Schwellenwerten und dazu, das Alert-Volumen handhabbar zu halten, finden Sie unter Alerts optimieren und Vorlagen für Alerts.
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.
Sie können Trigger mit einer Vielzahl von Metriken konfigurieren:
- 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
Verwenden Sie Anomaly detection und warm-up nicht, um zu prüfen, ob stündliche Jobs, tägliche Jobs oder Cron-Jobs laufen.
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.
Bei einigen Metriken müssen zusätzlich Tags ausgewählt werden. Zum Beispiel, wenn Sie eine benutzerdefinierte Metrik mit Tags an AppSignal senden:
Wählen Sie beim Erstellen eines Triggers für diese Metrik auch Tags aus.
Wenn Sie Tags eingeben, listet AppSignal die für diese Metrik gesehenen Tag-Kombinationen auf und warnt Sie, wenn die eingegebene Kombination in der letzten Stunde nicht gesehen wurde. Diese Warnung bedeutet meist, dass der Trigger auf keine Daten passen wird.
Verwenden Sie eine der Tag-Key-Kombinationen, die AppSignal für die Metrik auflistet, etwa 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.
Justieren Sie einen Trigger nicht neu, während Sie über ihn noch einen aktiven Alert verfolgen.
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 Metrik 0 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
Sie können Ihre Incidents auch einfach nach ihrem Zustand filtern.
Um einen Incident weiter zu untersuchen, können Sie die Incident-Zusammenfassung öffnen. Hier finden Sie alle Werkzeuge und Informationen, die Sie benötigen, um die Anomalie hinter Ihrem Alert genauer zu untersuchen. Auf der Zusammenfassungsseite haben Sie Zugriff auf:
- 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.
Alle diese Funktionen sind in unserer intuitiven Oberfläche leicht zugänglich:
