Fehlerbehebung bei Alarmen
Mit den Informationen zur Fehlerbehebung können Sie allgemeine Probleme erkennen und beheben, die beim Arbeiten mit Alarmen in Monitoring auftreten können.
Stellen Sie vor der Fehlerbehebung sicher, dass Sie wissen, wie Alarme ausgewertet werden. Siehe Illustration of Alarm Evaluation.
Alarm wird nicht ausgelöst
Der Alarm erfüllte die Bedingung für den Brand, aber er feuerte nicht. Beispiel: Eine Compute-Instanz ist heruntergefahren.
Ursache: Lange Triggerverzögerung
Der Alarmausdruck wurde in der Triggerverzögerungsperiode für aufeinanderfolgende Minuten nicht als wahr ausgewertet.
Das folgende Bild des Metrikdiagramms eines Alarms enthält einen schattierten Bereich, der die Triggerverzögerungsperiode angibt. In diesem Beispiel lautet die Alarmübersicht, die auf der Seite mit den Alarmdetails angezeigt wird, Alarm fires when the Mean of CpuUtilization is greater than the threshold value of 80, with a trigger delay of 10 minutes. Die Triggerverzögerung beginnt bei 1:30 (bei Überschreiten der Schwelle) und endet bei 1:40. Der Alarmausdruck wird um 1:30 auf "true" ausgewertet und dann um 1:32 auf "false" ausgewertet. Diese echte Auswertung wird nicht für die gesamte zehnminütige Triggerverzögerungsperiode fortgesetzt, sodass der Alarm nicht ausgelöst wird.
Um das Metrikdiagramm für einen Alarm anzuzeigen, holen Sie dessen Historie.
Weitere Informationen zur Auswertung von Alarmen finden Sie unter Illustration of Alarm Evaluation.
Abhilfe: Triggerverzögerung verkürzen
Wenn die Triggerverzögerung zu lang ist und der Alarm sofort ausgelöst werden soll, nachdem der Schwellenwert überschritten wurde, aktualisieren Sie den Alarm, um eine kürzere Triggerverzögerung zu verwenden. Stellen Sie beispielsweise die Triggerverzögerung auf eine Minute ein. Siehe Triggerverzögerung für einen Alarm definieren und Monitoring Query Language-(MQL-)Referenz.
Ursache: Intervall ist kürzer als die Emissionsfrequenz
Der Alarmausdruck wurde auf "true" ausgewertet, wodurch der Alarm ausgelöst wird. Im nächsten Intervall wurde der Alarm jedoch gelöscht, obwohl der letzte Datenpunkt den Schwellenwert überschritten hat. Der Alarm wurde gelöscht, weil das Intervall kürzer als die Emissionshäufigkeit für die ausgewählte Metrik ist.
Das folgende Bild des Metrikdiagramms eines Alarms zeigt stündliche Datenpunkte für die ausgewählte Metrik StoredBytes aus dem Metrik-Namespace oci_object_storage an. Die Alarmabfrage ist StoredBytes[1m].sum() > 800000000, die ein Intervall von einer Minute angibt. Dieses Intervall ist kürzer als die Emissionsfrequenz der Metrik, also eine Stunde. (Die Häufigkeit wird unter Object Storage-Metriken dokumentiert.)
In diesem Beispiel wird der Alarm um 3:00 Uhr ausgelöst und um 3:01 Uhr gelöscht. Wenn das Intervall auf eine Stunde gesetzt wurde, wird die Auswertung des Alarmausdrucks auf "true" gesetzt, und der Alarm wird bis 4:00 Uhr weiter ausgelöst.
Um das Metrikdiagramm für einen Alarm anzuzeigen, holen Sie dessen Historie.
Weitere Informationen zur Auswertung von Alarmen finden Sie unter Illustration of Alarm Evaluation.
Abhilfe: Intervall erhöhen
Wenn der Alarm ausgelöst werden soll, aktualisieren Sie das Alarmintervall so, dass es mit der Emissionsfrequenz der Metrik übereinstimmt oder länger ist. Beispiel: Aktualisieren Sie für die Metrik StoredBytes das Alarmintervall auf mindestens eine Stunde, wenn der Alarm um 3:01 Uhr ausgelöst werden soll, und fahren Sie mit dem Auslösen bis 4:00 im vorherigen Beispiel fort. Siehe Intervall für eine Alarmabfrage auswählen und Monitoring Query Language-(MQL-)Referenz.
Ursache: Falsche Abmessungen
Der Alarmausdruck wurde nicht als "true" ausgewertet, wenn eine Ressource die im Alarm definierte Bedingung erfüllt hat, weil die Ressource mit Dimensionen herausgefiltert wurde.
Beispiel: Ein Alarm mit Dimensionen, die für Availability-Domain 1 ausgewählt sind. Die Ressource, die diese Bedingung erfüllt hat, befindet sich in Availability-Domain 2. Bei der Alarmauswertung werden nur Ressourcen berücksichtigt, die mit den angegebenen Dimensionen übereinstimmen.
Abhilfe: Dimensionen aktualisieren
Entfernen Sie die Dimensionen, oder aktualisieren Sie sie, um die Ressource einzuschließen. Siehe Dimensionen für eine Alarmabfrage auswählen.
Ursache: Falsche Abfrage
Häufige Beispiele:
- In der Alarmabfrage kann die Metrik
MemoryUtilizationangegeben werden, wenn SieCpuUtilizationauswählen wollten. - In der Alarmabfrage kann die Statistik
mean()angegeben werden, wenn der Alarm stattdessen die Summe der Datenpunkte in einem Intervall (sum()) überwachen soll.
Um die Abfrage nach einem Alarm zu prüfen, holen Sie die zugehörigen Details.
Informationen zu Abfrageelementen finden Sie in der Monitoring Query Language-(MQL-)Referenz. Weitere Informationen zur Auswertung von Alarmen finden Sie unter Illustration of Alarm Evaluation.
Fehlerbehebung: Abfrage aktualisieren
Ursache: Der Alarm ist deaktiviert
Behebung: Diesen Alarm aktivieren
Alarm sendet keine Benachrichtigung
Wenn der Alarm ausgelöst wird, wird keine Benachrichtigung gesendet.
Ursache: Alarm oder Dimension wird unterdrückt
Abhilfe: Entfernen der Unterdrückung
Siehe Unterdrückung aus einem einzelnen Alarm entfernen und Unterdrückungen aus mehreren Alarmen entfernen.
Ursache: Abonnement ist nicht Teil des konfigurierten Themas
Nehmen wir zum Beispiel an, dass Sie keine Alarmnachrichten in Ihrem Posteingang erhalten. Das für den Alarm angegebene Thema hat möglicherweise kein E-Mail-Abonnement für die gewünschte E-Mail-Adresse.
Informationen zum Prüfen, ob das Thema das erwartete Abonnement enthält, finden Sie unter Details eines Themas abrufen.
Abhilfe: Thema aktualisieren, um Abonnement einzuschließen
Siehe Abonnement erstellen.
Sie können den Alarm auch aktualisieren, um ein neues Thema und Abonnement zu referenzieren, oder ein vorhandenes Thema, das das gewünschte Abonnement enthält. Siehe Thema als Benachrichtigungsziel für einen Alert auswählen.
Alarm sendet zu viele Benachrichtigungen
Wenn der Alarm ausgelöst wird, sendet er mehr Benachrichtigungen als erwartet.
Ursache: Wiederholungsbenachrichtigungen sind aktiviert
Der Alarm ist so konfiguriert, dass Alarmbenachrichtigungen wiederholt werden, wenn der Alarm ohne Unterbrechung ausgelöst wird.
Abhilfe: Wiederholungsbenachrichtigungen deaktivieren
Ursache: Split-Benachrichtigungen sind aktiviert
Der Alarm ist so konfiguriert, dass er eine Benachrichtigung für jeden ausgelösten Metrikstream sendet. Beispiel: Wenn 50 Metrikstreams ausgelöst werden, sendet der Alarm 50 Benachrichtigungen. Dieses Verhalten wird bei geteilten Benachrichtigungen erwartet. Siehe Szenario: Nachrichten nach Metrikstream aufteilen.
Beispiel: Die folgende Abbildung zeigt ein Alarmmetrikdiagramm mit zwei Metrikstreams, die den Schwellenwert um 1:30 Uhr überschreiten, wodurch der Alarm ausgelöst wird.
Die folgende Alarmmeldung wird für die Compute-Instanz mit dem Metrikwert 87 gesendet.
Die folgende Alarmmeldung wird für die Compute-Instanz mit dem Metrikwert 95 gesendet.
Um das Metrikdiagramm für einen Alarm anzuzeigen, holen Sie dessen Historie.
Alarm zurückgesetzt
Die Alarmhistorie zeigt einen RESET-Übergangsstatus an.
Ein Alarm wird zurückgesetzt, um die Prüfung auf eine abwesende Metrik zu stoppen, die den Auslösestatus ausgelöst hat. Weitere Informationen finden Sie unter Informationen zur internen Zurücksetzungsperiode.
Alarm wird nicht gespeichert (404-Fehler)
Wenn Sie versuchen, einen neuen oder aktualisierten Alarm zu speichern, wird ein 404-Fehler angezeigt, der die Erstellung oder Aktualisierung des Alarms verhindert.
Ursache: Unzureichende Policys
Ein 404-Fehler gibt an, dass Sie nicht über die erforderlichen IAM-Policys verfügen.
Abhilfe: Erforderliche Policys abrufen
Alarm wird kontinuierlich ausgelöst und gelöscht
Beheben Sie Fehler bei einem Alarm, der ständig zwischen den Statuswerten Firing und OK wechselt.
Entweder ist das Alarmintervall zu klein, oder die Triggerverzögerung ist zu groß (oder beides). Die Ressource gibt die angegebene Metrik häufiger als das Alarmintervall aus.
Beispiel: Die Metrik DatabaseAvailability wird alle 5 Minuten ausgegeben.
API-Anforderung (relevante Teile):
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[1m].absent()",
"pendingDuration":"PT3M",Konsolenkonfiguration:
| Feld | Wert |
|---|---|
| Metrik-Namespace | oci_autonomous_database |
| Metrikname | DatabaseAvailability |
| Intervall | 1 Minute |
| Statistik | Mittelwert |
| Triggerregel |
|
| Nachrichtengruppierung | Benachrichtigungen über Metrikstreams hinweg gruppieren |
- Beispiel: Alarm wechselt Status
Das folgende Beispiel enthält einen Alarm, dessen Status zwischen Firing und OK von 1:00 Uhr und 1:08 Uhr wechselt. Beachten Sie den Status OK um 1:01 Uhr, 1:02 Uhr, 1:06 Uhr und 1:07 Uhr. Zu diesen Zeiten haben die Alarmauswertungsergebnisse die Bedingung für das Intervall von einer Minute erfüllt. Die Statusänderung stand jedoch aufgrund der Triggerverzögerung von drei Minuten intern aus. Der Alarmstatus wurde um 1:03 Uhr und 1:08 Uhr in Firing geändert, da drei aufeinander folgende Auswertungen die Bedingung erfüllt haben.
| Zeit | Wert im Metrikdiagramm* | Alarmbedingung erfüllt? | Alarmstatus |
|---|---|---|---|
| 1:00 Uhr | 0 |
Nein | OK |
| 1:01 Uhr | 1 |
Ja. Statusänderung steht intern aus | OK |
| 1:02 Uhr | 1 |
Ja. Statusänderung steht intern aus | OK |
| 1:03 Uhr | 1 |
Ja | Firing |
| 1:04 Uhr | 1 |
Ja | Firing |
| 1:05 Uhr | 0 |
Nein | OK |
| 1:06 Uhr | 1 |
Ja. Statusänderung steht intern aus | OK |
| 1:07 Uhr | 1 |
Ja. Statusänderung steht intern aus | OK |
| 1:08 Uhr | 1 |
Ja | Firing |
* Bei einem Wert im Metrikdiagramm bedeutet 0, dass die Metrik vorhanden ist, und 1, dass die Metrik fehlt. Ein Beispielmetrikdiagramm finden Sie unter Abwesenheitsalarm erstellen.
Um dieses Problem zu beheben, aktualisieren Sie die folgende Alarmkonfiguration:
- Alarmintervall größer/gleich Häufigkeit der Metrikausgabe. Siehe Intervall für eine Alarmabfrage auswählen.
- Triggerverzögerung zur Berücksichtigung der Latenz. Siehe Triggerverzögerung für einen Alarm festlegen.
Beispiel: Ändern Sie das Intervall in 10 Minuten und die Triggerverzögerung in 1 Minute.
API-Anforderung (relevante Teile):
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[10m].absent()",
"pendingDuration":"PT1M",Konsolenkonfiguration:
| Feld | Wert |
|---|---|
| Metrik-Namespace | oci_autonomous_database |
| Metrikname | DatabaseAvailability |
| Intervall | 10 Minuten |
| Statistik | Mittelwert |
| Triggerregel |
|
| Nachrichtengruppierung | Benachrichtigungen über Metrikstreams hinweg gruppieren |
- Beispiel: Metrik ist vorhanden, Alarm ist
OK - In diesem Beispiel ist die Metrik zu den erwarteten Zeiten (alle fünf Minuten) vorhanden: 2:00 Uhr, 2:05 Uhr und 2:10 Uhr. Der Alarm wertet zu jedem Zeitpunkt das Vorhandensein der Metrik in den letzten zehn Minuten aus. Der Alarmstatus bleibt für die aufgeführten Zeiten
OK.
- Beispiel: Metrik fehlt, Alarm ist
Firing - In diesem Beispiel ist die Metrik um 2:00 Uhr vorhanden, fehlt jedoch um 2:05 Uhr und 2:10 Uhr. Da das Alarmintervall zehn Minuten beträgt, wurde die Alarmbedingung um 2:05 nicht erfüllt. Um 2:10 Uhr ändert sich der Alarmstatus in
Firing, weil die Alarmbedingung erfüllt ist (im Intervall von zehn Minuten waren null Metriken vorhanden).