> ## 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.
# Anomalie-Erkennung
Mit der [Anomalie-Erkennung](https://appsignal.com/redirect-to/app?to=alerts) 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 100MB fällt.
Die Anomalie-Erkennung funktioniert, indem sie Änderungen an Metrikwerten im Minutentakt erkennt. Wenn eine Schwellenwertbedingung erreicht wird, benachrichtigen wir Sie über den durch dieses Ereignis erstellten neuen Alarm und benachrichtigen Sie erneut, wenn der Schwellenwert nicht mehr erreicht wird.
Damit Sie zu einem für Sie passenden Zeitpunkt benachrichtigt werden, können Sie [Aufwärm- und Abkühlzeiten](#warm-up-and-cooldown) definieren, um zu steuern, wann ein neuer Alarm geöffnet wird.
## Alarmzustände
Alarme können fünf verschiedene Zustände haben:
| Zustand | Beschreibung |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Aufwärmend | Der Alarm befindet sich in seiner Aufwärmphase. Sie können pro Trigger konfigurieren, dass eine Bedingung für eine bestimmte Zeit erfüllt sein muss, bevor Sie alarmiert werden. |
| Offen | Der Alarm ist aktiv geworden, weil er seine Schwellenwertbedingung erreicht hat. |
| Geschlossen | Der Alarm ist nicht mehr aktiv und wurde geschlossen. |
| Abkühlend | Der Alarm liegt nicht mehr über seiner Schwellenwertbedingung, wird aber erst am Ende der Abkühlzeit beendet oder erneut geöffnet. |
| Beendet | Der Alarm ist beendet. Es wird kein weiterer Alarm gesendet. Wenn die Trigger-Bedingungen erneut ausgelöst werden, geht ein neuer Alarm in die Aufwärmphase über. |
### Wann werde ich benachrichtigt?
Nachdem Sie Benachrichtigungen konfiguriert haben, werden Sie benachrichtigt, wenn ein Alarm in die offene Phase übergeht. Sie werden durch alle Erinnerungen benachrichtigt, die Sie für diese Phase konfiguriert haben, und wenn der Alarm geschlossen wird.
### E-Mail-Alarme
Alarm-E-Mails enthalten eine Übersicht über neue Alarme, Erinnerungen und den Status anderer Alarme, die noch nicht beendet sind.
## Trigger erstellen und konfigurieren
Die Anomalie-Erkennung kann pro App im Bereich [„Anomalie-Erkennung"](https://appsignal.com/redirect-to/app?to=alerts) in der App-Navigation konfiguriert werden. Standardmäßig sehen Sie die neuesten Alarme, die durch die für die App konfigurierten Trigger erstellt wurden.
In der oberen Navigation können Sie zur [Trigger-Seite](https://appsignal.com/redirect-to/app?to=triggers) wechseln, um neue Trigger zu erstellen und bestehende zu bearbeiten.
Sie können Trigger im Bereich [„Anomalie-Erkennung"](https://appsignal.com/redirect-to/app?to=triggers) im Navigationsmenü Ihrer Anwendung erstellen und verwalten.
Sie können Trigger mit einer Vielzahl von Metriken konfigurieren:
* Fehlerraten
* (Absolute) Fehleranzahlen
* App-Durchsatz
* Performance von Aktionen (langsame Aktionen)
* Wartezeit in der Warteschlange
* Host-Metriken
* CPU-Last
* Festplatten-I/O
* Festplattennutzung
* Lastdurchschnitte
* Speichernutzung
* Netzwerknutzung
### Aufwärm- und Abkühlphase
Sie können Aufwärm- und Abkühleinstellungen für jeden Trigger konfigurieren und so die Zeit festlegen, die das System wartet, bevor ein Alarm geöffnet oder geschlossen wird.
### Aufwärmphase
Es wird nicht empfohlen, die Anomalie-Erkennung und die Aufwärmfunktion zu verwenden,
um zu prüfen, ob Dienste wie stündliche/tägliche Jobs und Cronjobs laufen.
Wenn die Schwellenwertbedingung eines Triggers erreicht wird, öffnet er normalerweise einen Alarm; zum Beispiel, wenn die Fehlerrate höher als 5 % ist.
Wenn auf dem Trigger eine Aufwärmphase konfiguriert wurde, öffnet AppSignal erst dann einen Alarm, wenn diese Zeit verstrichen ist und der Schwellenwert-Trigger weiterhin erfüllt ist; zum Beispiel, wenn die Fehlerrate länger als 3 Minuten höher als 5 % ist.
Wenn für einen Trigger eine Aufwärmphase konfiguriert ist, wird der Alarm erst geöffnet, nachdem die Aufwärmzeit verstrichen ist. Die Schwellenwertbedingung muss während der gesamten Aufwärmphase erfüllt sein, damit der Alarm geöffnet wird.
AppSignal benachrichtigt Sie, wenn der Alarmstatus von Aufwärmen auf Offen wechselt.
### Abkühlphase
Durch einen Trigger geöffnete Alarme werden automatisch geschlossen, wenn die Schwellenwertbedingung nicht mehr erfüllt ist. Um eine übermäßige Benachrichtigung zu vermeiden, können Sie Abkühlphasen konfigurieren.
Wenn Sie eine Abkühlphase für einen Trigger konfiguriert haben, wird kein neuer Alarm erstellt, es sei denn, die Bedingungen des Triggers werden erfüllt, nachdem die Abkühlphase abgelaufen ist.
Zum Beispiel:
1. Ein Alarm wird geöffnet, weil die Fehlerrate höher als 5 % ist.
2. Die Fehlerrate sinkt, also wird der Alarm automatisch geschlossen.
3. Der Trigger für den Alarm hat eine Abkühlphase von zwei Minuten.
4. Die Fehlerrate steigt erneut über 5 %.
5. AppSignal erstellt keinen neuen Alarm, es sei denn, die Fehlerrate übersteigt 5 % nach Ablauf der Abkühlphase.
### Tags
Einige Metriken erfordern, dass auch Tags ausgewählt werden. Wenn Sie zum Beispiel eine benutzerdefinierte Metrik an AppSignal senden, die Tags enthält:
```ruby Ruby theme={null}
Appsignal.set_gauge("my_metric_name", 100, :namespace => "web", :action => "hello")
```
Dann müssen Sie beim Erstellen eines Triggers für diese Metrik ebenfalls Tags auswählen.
## Fehlende Datenpunkte als 0
Standardmäßig gehen Trigger davon aus, dass jede Minute ein Datenpunkt gesendet wird.
In bestimmten Situationen ist das möglicherweise nicht praktikabel, z. B. beim Inkrementieren eines Zählers nur dann, wenn eine bestimmte Aktion auftritt. In solchen Fällen können Sie die Option `"When checked, we will treat missing datapoints as a value of 0"` verwenden. Wenn diese Option aktiviert ist, geht das System davon aus, dass ein fehlender Datenpunkt den Wert null hat. Dies hilft sicherzustellen, dass der Alarm wie erwartet geschlossen wird, wenn in der nächsten Minute keine Daten empfangen werden.
## Datenverarbeitung
Die von Triggern zum Erstellen von Alarmen verwendeten Metriken werden nicht sofort verarbeitet, wenn die Metriken von Ihrer Anwendung an AppSignal gesendet werden.
Ihre Metrikdaten durchlaufen mehrere Systeme, bevor sie unseren Prozessor erreichen. Die Daten können auch von mehreren Servern gesendet werden, die [Daten in unterschiedlichen Intervallen senden](/appsignal/how-appsignal-operates#agent).
Der Prozessor wartet dann\*, bis alle Daten für eine Minute eingetroffen sind, bevor er diese Daten verarbeitet und Alarme erstellt oder aktualisiert.
Wenn Sie Probleme mit den von AppSignal für die Anomalie-Erkennung gemeldeten Metriken haben, stellen Sie sicher, dass die Server Ihrer Anwendung alle gleichzeitig melden, indem Sie sie mit [NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) konfigurieren. Falsche oder unterschiedliche gemeldete Zeiten für Daten, die von mehreren App-Servern gesendet werden, können dazu führen, dass Alarme nie geöffnet oder geschlossen werden.
Mehr darüber, wie AppSignal Daten für die Anomalie-Erkennung verarbeitet und was das für die Alarme bedeutet, erfahren Sie in unserer [Dokumentation zum Datenlebenszyklus][data life cycle].
\*: Weitere Informationen zu den Details der Wartezeit finden Sie auf unserer [Seite zum Datenlebenszyklus][data life cycle].
[data life cycle]: /appsignal/data-life-cycle.html
## Vorfälle verwalten
Sie können alle Alarm-Vorfälle auf der Seite „Anomalie-Probleme" in der AppSignal-App ansehen. Die Issues-Seite zeigt eine Übersicht aller offenen Alarm-Vorfälle, 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 Vorfälle auch einfach nach ihrem [Zustand](#alert-states) filtern.
Um einen Vorfall weiter zu untersuchen, können Sie die Vorfallsübersicht öffnen. Hier finden Sie alle Werkzeuge und Informationen, die Sie benötigen, um die Anomalie, die Ihren Alarm ausgelöst hat, näher zu untersuchen. Auf der Übersichtsseite haben Sie Zugriff auf:
* **Alarm-Informationen:** Der Metrikname, der Alarmzustand und die Tags des Alarms.
* **Häufigkeitsdiagramm:** Eine visuelle Darstellung des Auftretens des Alarms.
* **Vorfall-Einstellungen:** Möglichkeit, den Alarm zu schließen, seinen Schweregrad festzulegen und einem Teammitglied zuzuweisen.
* **Trigger-Informationen:** Die Bedingungen, die zum Auslösen des Alarms erforderlich sind.
* **Letzte Vorkommen:** Eine Tabelle der jüngsten Vorkommen mit Start-/Endzeit, Zustand und Spitzenwert.
* **Logbuch:** Ein Logbuch zur Erfassung wichtiger Alarm-Informationen für Ihr Team oder Ihr zukünftiges Ich.
* **Zugriff auf den Time Detective:** Verwenden Sie das Time-Detective-Werkzeug, um den Zustand Ihrer Anwendung zum Zeitpunkt des letzten Auftretens des Alarms anzusehen.
Alle diese Funktionen sind über unsere intuitive Benutzeroberfläche leicht zugänglich:
