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 auf eine Benachrichtigungsrichtlinie auswirken können, durch die Auswahl des Fensters für den erneuten Test. Siehe z. B. Verhalten von messwertbasierten Benachrichtigungsrichtlinien.

Richtlinie zur Laufwerksauslastung bedingt unerwartete Vorfälle

Sie haben eine Benachrichtigungsrichtlinie erstellt, um die Kapazität der Laufwerke in Ihrem System. Diese Richtlinie überwacht den Messwert agent.googleapis.com/disk/percent_used. Sie erwarten, nur benachrichtigt zu werden, wenn ein physisches Laufwerk genutzt wird den Grenzwert überschreitet, den Sie in der Bedingung festgelegt haben. Dieses erstellt, wenn die Laufwerksauslastung physisches Laufwerk kleiner als der Grenzwert ist.

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 Benachrichtigungsrichtlinie zur Laufwerksauslastung konfiguriert werden, um die Zeitreihe für die Loopback-Geräte /dev/loop0 und /dev/loop1. Zum Beispiel könnten Sie Fügen Sie den Filter device !=~ ^/dev/loop.* hinzu, mit dem alle Zeitreihen ausgeschlossen werden. dessen 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 zeigt der Vorfall nicht die Datenlücke, manchmal aber automatisch korrigiert:

    • In Diagrammen sind beispielsweise keine Lücken zu sehen, weil die Werte für Fehlende Daten werden interpoliert. Auch wenn die Daten von einigen Minuten nicht vorhanden ist, verbindet das Diagramm fehlende Punkte für visuelle Kontinuität. Ein solches kann eine Lücke in den zugrunde liegenden Daten ausreichen, damit eine Benachrichtigungsrichtlinie erstellen Sie einen Vorfall.

    • Punkte in logbasierten Messwerten können zu spät eintreffen und aufgefüllt werden. bis zu 10 Minuten zurückliegen. Das Backfill-Verhalten korrigiert die Lücke effektiv. Die Lücke wird ausgefüllt, sobald die Daten eintreffen. Daher kann es zu einer Lücke in einem logbasierten Messwert kommen, die nicht mehr sichtbar ist. hat eine Benachrichtigungsrichtlinie zum Erstellen eines Vorfalls geführt.

  • 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. Bis Um das zu verhindern, sollten Sie sicherstellen, dass mehrere Messungen erforderlich sind, bevor ein Vorfall wird durch Festlegen des Fensters für den erneuten Test einer Bedingung erstellt mehr als doppelt so hoch wie die Stichprobenrate des Messwerts ist.

    Wenn beispielsweise jedes Mal eine Stichprobe 60 Sekunden. Legen Sie dann das Fenster für den erneuten Test auf mindestens 3 Minuten fest. Wenn Sie im Fenster des erneuten Tests auf den neuesten Wert oder 0 Sekunden kann eine einzige Messung zu einem Vorfall führen.

  • Wenn die Bedingung einer Benachrichtigungsrichtlinie bearbeitet wird, kann es mehrere Minuten warten, bis die Änderung über die Benachrichtigungsinfrastruktur übertragen wurde. Während dieses Zeitraums können Sie Benachrichtigungen über Vorfälle erhalten, die die ursprünglichen Bedingungen der Benachrichtigungsrichtlinie erfüllt.

  • Wenn Zeitreihendaten eintreffen, kann es bis zu einer Minute dauern, bis die Daten angezeigt werden. die gesamte Benachrichtigungsinfrastruktur umfasst. Während dieser Zeit kann eine Benachrichtigungsrichtlinie eine Bedingung als erfüllt bewerten, auch wenn die Zeitreihendaten noch nicht in das Zeitreihendiagramm übernommen wurden. Deshalb erhalten Sie möglicherweise eine Benachrichtigung, obwohl das Diagramm nicht dass die Bedingung erfüllt ist. Um die Wahrscheinlichkeit zu verringern, sollten Sie einen Ausrichtungszeitraum von mindestens fünf Minuten festlegen.

Vorfall ist nicht geschlossen, wenn keine Daten eingehen

Sie folgen den Anweisungen in Teilmesswertdaten und konfigurieren Sie eine Benachrichtigungsrichtlinie, um Vorfälle zu schließen, wenn keine Daten eingehen. Manchmal gehen keine Daten mehr ein, aber es gibt keinen offenen Vorfall. automatisch geschlossen.

Wenn die zugrunde liegende Ressource, die von einer Benachrichtigungsrichtlinie überwacht wird, Folgendes enthält: Das Label metadata.system_labels.state und wenn diese Richtlinie nicht verfasst ist, mit der Monitoring Query Language den Status ermitteln der Ressource. Wenn der Status einer Ressource deaktiviert ist, dann Beim Monitoring werden Vorfälle nicht automatisch geschlossen, wenn Daten nicht mehr ankommen. Sie können diese Vorfälle jedoch manuell schließen.

Vorfalldetails können aufgrund eines Berechtigungsfehlers nicht aufgerufen werden

Rufen Sie in der Google Cloud Console die Seite „Vorfälle“ auf und wählen Sie um den Vorfall anzuzeigen. 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 der Messwertdaten sehen möchten, benötigen Sie die IAM-Rollen (Identity and Access Management, Identitäts- und Zugriffsverwaltung) von Betrachter von Monitoring Cloud Console-Vorfällen (roles/monitoring.cloudConsoleIncidentViewer) und Betrachter von Stackdriver-Konten (roles/stackdriver.accounts.viewer)

Um alle Vorfalldetails, einschließlich der Messwertdaten, anzuzeigen und Bestätigen oder schließen Sie Vorfälle und stellen Sie sicher, dass Sie die IAM Rollen von Monitoring-Betrachter (roles/monitoring.viewer) und Bearbeiter von Monitoring Cloud Console-Vorfällen (roles/monitoring.cloudConsoleIncidentEditor).

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

Vorfall wird nicht erstellt, wenn Bedingung erfüllt ist

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

Wenn nach der Bedingung der Benachrichtigungsrichtlinie eines der folgenden Kriterien erfüllt ist erfüllt ist, öffnet Monitoring den Vorfall nicht.

  • Die Benachrichtigungsrichtlinie ist zurückgestellt.
  • Die Benachrichtigungsrichtlinie ist deaktiviert.
  • Die Benachrichtigungsrichtlinie hat die maximale Anzahl an Vorfällen, die gleichzeitig geöffnet werden können.

  • Der Status der Ressource, die von der Benachrichtigungsrichtlinie überwacht wird, ist bekannt deaktiviert. Monitoring kann den Status einer Ressource bestimmen, wenn diese den metadata.system_labels.state-Label und wenn die Benachrichtigungsrichtlinie nicht konfiguriert ist in der Monitoring Query Language erstellt.

Vorfalldetails mit falschem Projekt

Sie erhalten eine Benachrichtigung und in der Bedingungsübersicht wird die Google Cloud-Projekt, in dem der Vorfall erstellt wurde, d. h., es werden die Projektumfangs definieren. Sie erwarten jedoch, dass bei dem Vorfall der Name des Google Cloud-Projekt, in dem die Zeitreihe gespeichert ist, Monitoring zum Erstellen des Vorfalls

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

  • Wenn bei den Aggregationsoptionen das Label entfernt wird, in dem die Projekt-ID gespeichert ist, in den Vorfallsinformationen das Projekt, das den Umfang festlegt. Wenn Sie beispielsweise die Daten nur nach Zone gruppieren, gruppiert der Parameter nach der Gruppierung wird das Label entfernt, in dem die Projekt-ID gespeichert ist.

  • Wenn die Aggregationsoptionen das Label mit der Projekt-ID beibehalten, enthalten die Vorfallsbenachrichtigungen den Namen des Google Cloud-Projekts, speichert die Zeitreihe, die zum Auftreten des Vorfalls führt. Damit das Label der Projekt-ID erhalten bleibt, fügen Sie den Parameter Label project_id im Gruppierungsfeld enthalten oder die Zeitreihe nicht gruppieren.

Vorfall kann nicht manuell geschlossen werden

Sie haben eine Benachrichtigung über einen Vorfall in Ihrem System erhalten. Sie gehen zur und klicken Sie auf Instanz schließen. Sie erwarten, dass der Vorfall geschlossen sein; Sie erhalten jedoch die folgende Fehlermeldung:

Unable to close incident with active conditions.

Sie können einen Vorfall nur schließen, wenn im jüngsten Zeitraum keine Beobachtungen eingegangen sind. Benachrichtigungszeitraum. Der Benachrichtigungszeitraum, der in der Regel einen Standardwert hat von 5 Minuten, wird als Teil der Bedingung der Benachrichtigungsrichtlinie definiert. ist konfigurierbar. Die vorherige Fehlermeldung zeigt an, dass die Daten Benachrichtigungszeitraum erhalten haben.

Der folgende Fehler tritt auf, wenn ein Vorfall aufgrund eines Interner Fehler:

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 erstellt, die mehrere Bedingungen enthält, und diese Bedingungen mit einem logischen AND. Sie erwarten eine Benachrichtigung und einen Vorfall erstellen, wenn alle Bedingungen erfüllt sind. Sie haben jedoch mehrere Benachrichtigungen erhalten und sehen, dass mehrere Vorfälle erstellt werden.

Monitoring sendet eine Benachrichtigung und erstellt einen Vorfall für jede Zeitreihe, die dazu führt, dass eine Bedingung erfüllt wird. Wenn Sie also Wenn Sie Benachrichtigungsrichtlinien mit mehreren Bedingungen haben, können Sie potenziell eine Benachrichtigung und einen Vorfall für jede Zeitachse, die zur Folge hat, Bedingungen erfüllt sein müssen.

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

Sie können Monitoring nicht für die Erstellung eines einzelnen Vorfalls und eine einzige Benachrichtigung senden.

Weitere Informationen finden Sie unter Benachrichtigungen nach Vorfall.

Variable für ein Messwertlabel ist null

Sie erstellen eine Benachrichtigungsrichtlinie fügen Sie im Abschnitt „Dokumentation“ eine Variable für ein Messwertlabel hinzu. Sie erwarten, dass die Benachrichtigungen den Wert der Variablen enthalten. Allerdings wird der Wert auf null festgelegt.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Achten Sie darauf, dass in den Aggregationseinstellungen für die Benachrichtigungsrichtlinie die die Sie anzeigen möchten.

    Angenommen, Sie erstellen eine Benachrichtigungsrichtlinie, die den von VM-Instanzen geschriebene Laufwerkbyte. Sie möchten, dass in der Dokumentation Gerät, das die Benachrichtigung verursacht, fügen Sie der Dokumentation hinzu Folgendes Feld: device: ${metric.label.device}.

    Außerdem muss in den Aggregationseinstellungen der Wert beibehalten werden des Labels device. Sie können dieses Label beibehalten, indem Sie die auf none setzen oder dafür sorgen, dass die Gruppierungsauswahl device enthalten.

  • Überprüfen Sie die Syntax und Anwendbarkeit der Variablen. Syntaxinformationen Siehe Benachrichtigungen mit benutzerdefinierter Dokumentation annotieren.

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

Keine neuen Daten nach Änderungen an Messwertdefinitionen

Sie können die Definition eines benutzerdefinierten Messwerts ändern, indem Sie z. B. den Filter, den Sie in einem logbasierten Messwert verwendet haben, und die Benachrichtigungsrichtlinie ist die die von Ihnen an der Messwertdefinition vorgenommene Änderung widerspiegelt.

Um dieses Problem zu beheben, erzwingen Sie die Aktualisierung der Benachrichtigungsrichtlinie. Bearbeiten Sie dazu das Feld Anzeigename der Richtlinie.