Fehlerbehebung bei Benachrichtigungsrichtlinien

Auf dieser Seite wird erläutert, warum sich einige Benachrichtigungsrichtlinien möglicherweise anders als beabsichtigt verhalten. Weiter werden mögliche Lösungen für diese Situationen aufgezeigt.

Informationen zu den Variablen, die sich beispielsweise durch die Auswahl des Testwiederholungsfensters auf eine Benachrichtigungsrichtlinie auswirken können, finden Sie unter Verhalten von messwertbasierten Benachrichtigungsrichtlinien.

Richtlinie zur Laufwerksauslastung bedingt unerwartete Vorfälle

Sie haben eine Benachrichtigungsrichtlinie erstellt, um die „verwendete“ Kapazität der Festplatten in Ihrem System zu überwachen. Mit dieser Richtlinie wird der Messwert agent.googleapis.com/disk/percent_used überwacht. Sie möchten nur benachrichtigt werden, wenn die Auslastung einer physischen Festplatte den in der Bedingung festgelegten Grenzwert überschreitet. Diese Richtlinie löst jedoch Vorfälle aus, wenn die Laufwerksauslastung jedes physischen Laufwerks unter dem Schwellenwert liegt.

Eine bekannte Ursache für unerwartete Vorfälle bei solchen Richtlinien ist, dass die Bedingungen nicht auf das Monitoring physischer Laufwerke beschränkt sind. Stattdessen überwachen diese Richtlinien alle Laufwerke, einschließlich virtueller Laufwerke, darunter Loopback-Geräte. Wenn ein virtuelles Laufwerk so entworfen wurde, dass seine Auslastung bei 100 % liegt, würde dies die Richtlinie dazu motivieren, einen Vorfall auszulösen.

Betrachten Sie beispielsweise folgende Ausgabe des Linux-Befehls df, der den auf bereitgestellten Dateisystemen verfügbaren Speicherplatz für ein System zeigt:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Für dieses System sollte eine Richtlinie für Benachrichtigungen zur Datenträgerauslastung konfiguriert werden, um die Zeitreihen für die Loopback-Geräte /dev/loop0 und /dev/loop1 herauszufiltern. Sie können beispielsweise den Filter device !=~ ^/dev/loop.* hinzufügen, um alle Zeitreihen auszuschließen, deren Label device nicht mit dem regulären Ausdruck ^/dev/loop.* übereinstimmt.

Häufige Ursachen für anomale Vorfälle

Sie haben eine Benachrichtigungsrichtlinie erstellt und die Richtlinie scheint vorzeitig oder fälschlicherweise Vorfälle zu erstellen.

Es gibt verschiedene Gründe, warum Sie eine Benachrichtigung über Vorfälle erhalten, die nicht korrekt zu sein scheinen:

• Wenn es eine Datenlücke gibt, insbesondere bei den Benachrichtigungsrichtlinien mit Bedingungen für das Fehlen von Messwerten oder „weniger als“-Schwellenwerten, kann ein Vorfall erstellt werden, der anomal zu sein scheint. Manchmal wird die Datenlücke im Vorfall nicht angezeigt und manchmal wird sie automatisch korrigiert:

  • In Diagrammen sind Lücken möglicherweise nicht zu sehen, da die Werte für fehlende Daten interpoliert werden. Selbst bei mehreren Minuten an fehlenden Daten werden die fehlenden Punkte im Diagramm ergänzt, um einen visuellen Zusammenhang herzustellen. Eine solche Lücke in den zugrunde liegenden Daten kann ausreichen, um einen Vorfall zu erstellen.

  • Punkte in logbasierten Messwerten können zu spät eintreffen und automatisch für die vergangenen 10 Minuten aufgefüllt werden. Das Backfill-Verhalten korrigiert die Lücke effektiv. Die Lücke wird ausgefüllt, sobald die Daten eintreffen. Somit kann eine nicht mehr erkennbare Lücke in einem logbasierten Messwert zum Erstellen eines Vorfalls geführt haben.

• Bedingungen für fehlende Messwerte oder Messwertschwellen, die eine Untergrenze festlegen, werden mit einer kleinen Abfrageverzögerung in Echtzeit ausgewertet. Der Status der Bedingung kann sich zwischen der Zeit der Bewertung und der Zeit ändern, zu dem der entsprechende Vorfall in Monitoring sichtbar ist.

• Bedingungen, die so konfiguriert sind, dass ein Vorfall auf Basis einer einzelnen Messung erstellt wird, können dazu führen, dass Vorfälle vorzeitig oder falsch erscheinen. Achten Sie zur Vermeidung dieser Situation darauf, dass mehrere Messungen erforderlich sind, bevor ein Vorfall erstellt wird. Dazu legen Sie das Retest-Zeitfenster einer Bedingung auf mehr als das Doppelte der Stichprobenrate des Messwerts fest.

  Wenn ein Messwert beispielsweise alle 60 Sekunden als Stichprobe verwendet wird, legen Sie das Zeitfenster für den erneuten Test auf mindestens 3 Minuten fest. Wenn Sie das Fenster für den erneuten Test auf den aktuellsten Wert oder auf gleich 0 Sekunden festlegen, kann eine einzelne Messung dazu führen, dass ein Vorfall erstellt wird.

• Wenn die Bedingung einer Benachrichtigungsrichtlinie bearbeitet wird, kann es einige Minuten dauern, bis die Änderung in der Benachrichtigungsinfrastruktur wirksam wird. Während dieses Zeitraums erhalten Sie möglicherweise Benachrichtigungen zu Vorfällen, die die ursprünglichen Bedingungen der Benachrichtigungsrichtlinie erfüllt haben.

• Wenn Zeitreihendaten eingehen, kann es bis zu einer Minute dauern, bis die Daten in der gesamten Benachrichtigungsinfrastruktur verfügbar sind. Während dieses Vorgangs kann es vorkommen, dass eine Benachrichtigungsrichtlinie eine Bedingung als erfüllt bewertet, obwohl die Zeitreihendaten noch nicht im Zeitreihendiagramm angezeigt werden. Daher erhalten Sie möglicherweise eine Benachrichtigung, obwohl das Diagramm nicht darauf hinweist, dass die Bedingung erfüllt ist. Um die Wahrscheinlichkeit dieser Situation zu verringern, sollten Sie einen Ausrichtungszeitraum von mindestens fünf Minuten verwenden.

• Durch die Umbenennung des App Hub-Labels metadata.system_labels.apphub_host_project_id in metadata.system_labels.apphub_application_container werden möglicherweise einige neue Vorfälle generiert und einige offene Vorfälle nicht geschlossen.

  Sie müssen nichts unternehmen. Benachrichtigungen werden automatisch geschlossen, wenn nach Ablauf des Zeitraums für das automatische Schließen keine Daten mehr eingehen. Weitere Informationen finden Sie unter Teilweise Messwertdaten.

Vorfall wird nicht geschlossen, wenn keine Daten mehr eingehen

Sie folgen der Anleitung unter Teilweise Messwertdaten und konfigurieren eine Benachrichtigungsrichtlinie, um Vorfälle zu schließen, wenn keine Daten mehr eingehen. In einigen Fällen werden keine Daten mehr empfangen, ein offener Vorfall wird aber nicht automatisch geschlossen.

Wenn die zugrunde liegende Ressource, die von einer Benachrichtigungsrichtlinie überwacht wird, das Label metadata.system_labels.state enthält und die Richtlinie nicht in der Monitoring Query Language geschrieben ist, kann Monitoring den Status der Ressource ermitteln. Wenn der Status einer Ressource als „Deaktiviert“ bekannt ist, schließt Monitoring Vorfälle nicht automatisch, wenn keine Daten mehr eingehen. Sie können diese Vorfälle jedoch manuell schließen.

Details zu Vorfällen können aufgrund eines Berechtigungsfehlers nicht angezeigt werden

Rufen Sie in der Google Cloud Console die Seite „Vorfälle“ auf und wählen Sie einen Vorfall aus. Sie erwarten, dass die Detailseite geöffnet ist. Die Detailseite wird jedoch nicht geöffnet und die Meldung „Berechtigung verweigert“ wird angezeigt.

Wenn Sie alle Vorfalldetails mit Ausnahme von Messwertdaten ansehen möchten, müssen Sie die IAM-Rollen „Monitoring Cloud Console Incident Viewer“ (roles/monitoring.cloudConsoleIncidentViewer) und „Stackdriver Accounts Viewer“ (roles/stackdriver.accounts.viewer) haben.

Wenn Sie alle Vorfalldetails, einschließlich der Messwertdaten, aufrufen und Vorfälle bestätigen oder schließen möchten, müssen Sie die IAM-Rollen „Monitoring-Betrachter“ (roles/monitoring.viewer) und „Monitoring Cloud Console Incident Editor“ (roles/monitoring.cloudConsoleIncidentEditor) haben.

Benutzerdefinierte Rollen können die zur Anzeige von Vorfalldetails erforderlichen Berechtigung nicht erteilen.

Bei Erfüllung der Bedingung wird kein Vorfall erstellt

Sie haben eine Benachrichtigungsrichtlinie mit einer Bedingung erstellt. Das Diagramm für die Benachrichtigungsrichtlinie zeigt, dass die überwachten Daten gegen die Bedingung verstoßen, aber Sie haben keine Benachrichtigung erhalten und es wurde kein Vorfall erstellt.

Wenn nach Erfüllung der Bedingung der Benachrichtigungsrichtlinie eines der folgenden Kriterien zutrifft, wird der Vorfall nicht geöffnet.

• Die Benachrichtigungsrichtlinie ist pausiert.
• Die Benachrichtigungsrichtlinie ist deaktiviert.
• Die Benachrichtigungsrichtlinie hat die maximale Anzahl von Vorfällen erreicht, die gleichzeitig geöffnet werden können.

• Der Status der Ressource, die von der Benachrichtigungsrichtlinie überwacht wird, ist als deaktiviert bekannt. Monitoring kann den Status einer Ressource ermitteln, wenn die Ressource das Label metadata.system_labels.state enthält und die Benachrichtigungsrichtlinie nicht mit der Monitoring Query Language geschrieben wurde.

In der Liste mit den Details zum Vorfall wird das falsche Projekt angezeigt

Sie erhalten eine Benachrichtigung und in der Zusammenfassung der Bedingung wird dasGoogle Cloud -Projekt aufgeführt, in dem der Vorfall erstellt wurde, d. h. das Projekt, in dem der Umfang festgelegt wurde. Sie erwarten jedoch, dass im Vorfall der Name des Google Cloud -Projekts aufgeführt ist, in dem die Zeitreihen gespeichert sind, die dazu geführt haben, dass Monitoring den Vorfall erstellt hat.

Die in der Bedingung einer Benachrichtigungsrichtlinie angegebenen Aggregationsoptionen bestimmen das Google Cloud Projekt, auf das in einer Benachrichtigung verwiesen wird:

• Wenn durch die Aggregationsoptionen das Label entfernt wird, in dem die Projekt-ID gespeichert ist, wird im Vorfallbericht das Projekt zur Bereichsdefinition aufgeführt. Wenn Sie die Daten beispielsweise nur nach Zone gruppieren, wird nach der Gruppierung das Label entfernt, in dem die Projekt-ID gespeichert ist.

• Wenn die Aggregationsoptionen das Label beibehalten, in dem die Projekt-ID gespeichert ist, enthalten die Benachrichtigungen zu Vorfällen den Namen des Google Cloud Projekts, in dem die Zeitreihe gespeichert ist, die den Vorfall verursacht. Wenn Sie das Label für die Projekt-ID beibehalten möchten, fügen Sie das Label project_id in das Gruppierungsfeld ein oder gruppieren Sie die Zeitreihen nicht.

Vorfall kann nicht manuell geschlossen werden

Sie haben eine Benachrichtigung zu einem Vorfall in Ihrem System erhalten. Sie rufen die Seite mit den Vorfalldetails auf und klicken auf Vorfall schließen. Sie erwarten, dass der Vorfall geschlossen wird, erhalten aber die Fehlermeldung:

Unable to close incident with active conditions.

Sie können einen Vorfall nur schließen, wenn im letzten Benachrichtigungszeitraum keine Beobachtungen eingehen. Der Benachrichtigungszeitraum, der in der Regel einen Standardwert von 5 Minuten hat, wird als Teil der Bedingung der Benachrichtigungsrichtlinie definiert und ist konfigurierbar. Die vorherige Fehlermeldung weist darauf hin, dass im Benachrichtigungszeitraum Daten empfangen wurden.

Der folgende Fehler tritt auf, wenn ein Vorfall aufgrund eines internen Fehlers nicht geschlossen werden kann:

Unable to close incident. Please try again in a few minutes.

Wenn Sie die vorherige Fehlermeldung sehen, können Sie den Vorgang zum Schließen wiederholen oder den Vorfall automatisch von Monitoring schließen lassen.

Weitere Informationen finden Sie unter Vorfälle verwalten.

Mit Richtlinien mit mehreren Bedingungen werden mehrere Benachrichtigungen erstellt

Sie haben eine Benachrichtigungsrichtlinie mit mehreren Bedingungen erstellt und diese Bedingungen mit einem logischen AND verknüpft. Sie erwarten, dass Sie eine Benachrichtigung erhalten und ein Vorfall erstellt wird, wenn alle Bedingungen erfüllt sind. Sie erhalten jedoch mehrere Benachrichtigungen und sehen, dass mehrere Vorfälle erstellt werden.

Monitoring sendet eine Benachrichtigung und erstellt einen Vorfall für jede Zeitachse, die eine Bedingung erfüllt. Wenn Sie also Benachrichtigungsrichtlinien mit mehreren Bedingungen haben, können Sie möglicherweise eine Benachrichtigung und einen Vorfall für jede Zeitachse erhalten, die dazu führt, dass die verknüpften Bedingungen erfüllt werden.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie mit zwei Bedingungen, wobei jede Bedingung drei Zeitreihen überwacht. Die Richtlinie sendet nur dann eine Benachrichtigung, wenn beide Bedingungen erfüllt sind. Wenn die Bedingungen Ihrer Richtlinie erfüllt sind, können Sie zwischen 2 (eine Zeitreihe wird in jeder Bedingung erfüllt) und 6 (alle Zeitreihen werden in jeder Bedingung erfüllt) Benachrichtigungen und Vorfälle erhalten.

Sie können Monitoring nicht so konfigurieren, dass in diesem Fall ein einzelner Vorfall erstellt und eine einzelne Benachrichtigung gesendet wird.

Weitere Informationen finden Sie unter Benachrichtigungen pro Vorfall.

Variable für ein Messwertlabel ist null

Sie erstellen eine Benachrichtigungsrichtlinie und fügen dem Dokumentationsabschnitt eine Variable für ein Messwertlabel hinzu. Sie erwarten, dass in den Benachrichtigungen der Wert der Variablen angezeigt wird. Der Wert ist jedoch auf null festgelegt.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

• Prüfen Sie, ob die Aggregationseinstellungen für die Benachrichtigungsrichtlinie das Label beibehalten, das Sie anzeigen möchten.

  Angenommen, Sie erstellen eine Benachrichtigungsrichtlinie, die die von VM-Instanzen geschriebenen Byte auf dem Datenträger überwacht. In der Dokumentation soll das Gerät aufgeführt werden, das die Benachrichtigung verursacht. Daher fügen Sie dem Feld „Dokumentation“ Folgendes hinzu: device: ${metric.label.device}.

  Sie müssen außerdem prüfen, ob der Wert des Labels device in Ihren Aggregationseinstellungen beibehalten wird. Sie können dieses Label beibehalten, indem Sie die Aggregationsfunktion auf none setzen oder dafür sorgen, dass die Gruppierungsauswahlen device enthalten.

• Prüfen Sie die Syntax und Anwendbarkeit der Variablen. Informationen zur Syntax finden Sie unter Benutzerdefinierte Dokumentation für Benachrichtigungen erstellen.

  Die Variable log.extracted_label.KEY wird beispielsweise nur für logbasierte Benachrichtigungsrichtlinien unterstützt. Diese Variable wird immer als null gerendert, wenn eine Benachrichtigungsrichtlinie einen Messwert überwacht, auch einen logbasierten Messwert.

Keine neuen Daten nach Änderungen an Messwertdefinitionen

Sie ändern die Definition eines benutzerdefinierten Messwerts, z. B. durch Ändern des Filters, den Sie in einem logbasierten Messwert verwendet haben, und die Benachrichtigungsrichtlinie spiegelt die Änderung der Messwertdefinition nicht wider.

Um dieses Problem zu beheben, erzwingen Sie die Aktualisierung der Benachrichtigungsrichtlinie, indem Sie den Anzeigenamen der Richtlinie bearbeiten.

Erstellung von Benachrichtigungsrichtlinien in der API schlägt aufgrund fehlender Messwerte fehl

Sie haben vor Kurzem einen Messwert erstellt und dann darauf verwiesen, als Sie versucht haben, eine Benachrichtigungsrichtlinie in der Cloud Monitoring API zu erstellen. Der API-Befehl schlägt jedoch fehl und es wird der folgende Fehler angezeigt:

Error 404: Cannot find metric(s) that match type = "METRIC_NAME".
If a metric was created recently, it could take up to 10 minutes to become
available. Please try again soon.

Warten Sie mindestens zehn Minuten und senden Sie die API-Anfrage dann noch einmal.

Im Diagramm der Benachrichtigungsrichtlinie wird kein Grenzwertverstoß angezeigt

Sie haben eine Benachrichtigung erhalten, dass für Ihre Benachrichtigungsrichtlinie ein Vorfall erstellt wurde. Wenn Sie jedoch die Detailseite für die Richtlinie aufrufen, wird im Diagramm nicht angezeigt, dass der Grenzwert überschritten wurde.

Versuchen Sie, den Zeitraum für das Diagramm zu verkürzen, um dieses Problem zu beheben. Sie können den Zeitraum verkürzen, indem Sie die Zeitraumauswahl in der Symbolleiste verwenden oder Zeiträume im Diagramm mit dem Mauszeiger markieren.

Diagramme haben eine begrenzte Auflösung und zeigen für einige Zeiträume möglicherweise nicht alle Messungen.