Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie Ausrichtungszeiträume und Zeitfenster für erneute Tests beschrieben werden bestimmen, wann eine Bedingung erfüllt ist, wie Benachrichtigungsrichtlinien mehrere und wie Benachrichtigungsrichtlinien fehlende Datenpunkte ersetzen. Außerdem wird die maximale Anzahl offener Vorfälle für eine Richtlinie beschrieben. die Anzahl der Benachrichtigungen pro Vorfall, und warum es zu Verzögerungen bei Benachrichtigungen kommt.

Dieser Inhalt gilt nicht für logbasierte Benachrichtigungsrichtlinien. Informationen zu logbasierten Benachrichtigungsrichtlinien finden Sie unter Logs überwachen

Ausrichtungszeiträume und Zeitfenster für erneute Tests

Cloud Monitoring wertet den Ausrichtungszeitraum und das Zeitfenster für den erneuten Test aus wenn ermittelt wird, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt ist.

Ausrichtungszeitraum

Bevor Zeitreihendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie Regularisiert sind, sodass die Benachrichtigungsrichtlinie regelmäßig Daten zum Auswerten enthält. Der Regularisierungsprozess wird als Ausrichtung bezeichnet.

Die Ausrichtung umfasst zwei Schritte:

  • Das Unterteilen der Zeitreihen in regelmäßige Zeitintervalle, auch Bucketing genannt mit den Daten. Das Intervall ist der Ausrichtungszeitraum.

  • Einen einzelnen Wert für die Punkte im Ausrichtungszeitraum berechnen Ihre Auswahl wie dieser einzelne Punkt berechnet wird, können Sie alle Werte summieren oder oder den Höchstwert verwenden. Die Funktion, die die Datenpunkte kombiniert wird als Aligner bezeichnet. Das Ergebnis dieser Kombination ist wird als ausgerichteter Wert bezeichnet.

    Weitere Informationen zur Abstimmung finden Sie unter Ausrichtung: Regularisierung innerhalb der Reihe:

Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten beträgt, wird um 13:00 Uhr der Ausrichtungszeitraum enthält die Stichproben, die zwischen 12:55 Uhr und 13:00 Uhr empfangen wurden. Um 13:01 Uhr geht der Ausrichtungszeitraum eine Minute weiter und enthält die zwischen 12:56 Uhr und 13:01 Uhr eingegangenen Stichproben.

In Monitoring wird ein Ausrichtungszeitraum so konfiguriert:

Google Cloud Console

Sie konfigurieren den Kalibrierungszeitraum, indem Sie auf der Seite Benachrichtigungsbedingungen einen Wert für die folgenden Felder auswählen:

  • Rollierendes Fenster: Gibt den auszuwertenden Zeitraum an.
  • Funktion für rollierendes Zeitfenster: Gibt die mathematische Funktion an, die auf das Datenfenster angewendet werden soll.

Weitere Informationen zu verfügbaren Funktionen Siehe Aligner in der API-Referenz. Mit einigen Aligner-Funktionen werden die Daten sowohl ausgerichtet also auch von einer Messwertart oder einem Messwerttyp in eine andere oder einen anderen konvertiert. Eine detaillierte Weitere Informationen zu Arten, Typen und Conversions

API

Sie konfigurieren den Alignierungszeitraum, indem Sie die Felder aggregations.alignmentPeriod und aggregations.perSeriesAligner in den Strukturen MetricThreshold und MetricAbsence festlegen.

Weitere Informationen zu den verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Ein Teil des Aligners können die Daten mithilfe von Funktionen und konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine detaillierte Weitere Informationen zu Arten, Typen und Conversions

Um die Auswirkungen des Ausrichtungszeitraums auf einen Zustand in einer Benachrichtigung zu veranschaulichen Bedingung für Messwertschwellen, Überwachen eines Messwerts mit einem Stichprobenzeitraum von einer Minute. Angenommen, der Ausrichtungszeitraum ist auf 5 Minuten und der Aligner auf sum eingestellt. Außerdem wird davon ausgegangen, dass die Bedingung erfüllt ist. wenn der ausgerichtete Wert der Zeitreihe bei und dass die Bedingung jede Minute ausgewertet wird. In diesem Beispiel beträgt der Ausrichtungszeitraum zwei Minuten und das Fenster für die erneute Prüfung der im nächsten Abschnitt beschrieben wird, beträgt drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

Abbildung zur Veranschaulichung der Auswirkungen des Ausrichtungszeitraums auf das Fenster bzw. die Dauer der erneuten Prüfung.

Jede Zeile in der Abbildung stellt eine einzelne Bewertung der Bedingung dar. Die Zeitachsendaten werden angezeigt. Die Punkte im Ausrichtungszeitraum werden mit blauen Punkten dargestellt, ältere Punkte sind schwarz. Jede Zeile enthält den ausgerichteten Wert und Gibt an, ob dieser Wert größer als der Grenzwert von zwei ist. Für die Zeile mit der Beschriftung start ergibt sich der Wert 1, der unter dem Grenzwert liegt. Bei der nächsten Auswertung ergibt die Summe der Stichproben im Ausrichtungszeitraum zwei. Bei der dritten Bewertung beträgt die Summe drei, und da dieser Wert größer als der Grenzwert ist, wird ein Timer für das Fenster für die erneute Prüfung gestartet.

Fenster noch einmal testen

Die Bedingung einer Benachrichtigungsrichtlinie hat ein Fenster zum erneuten Testen, das verhindert, dass Bedingung aufgrund einer einzelnen Messung oder Prognose nicht erfüllt ist. Angenommen, das Fenster für den erneuten Test einer Bedingung ist auf 15 eingestellt. Minuten. Im Folgenden wird das Verhalten der Bedingung je nach Typ beschrieben:

  • Bedingungen für Messwertschwellen sind erfüllt, wenn für eine einzelner Zeitreihe, die jede ausgerichtete Messung in einem 15-Minuten-Intervall gegen um den Grenzwert zu erreichen.
  • Bedingungen für fehlende Messwerte werden erfüllt, wenn für eine Zeitachse in einem 15-Minuten-Intervall keine Daten eingehen.
  • Die Prognosebedingungen sind erfüllt, wenn jede Prognose erzeugt wurde während In einem 15-Minuten-Zeitfenster wird vorhergesagt, dass die Zeitreihe den Grenzwert überschreitet. innerhalb des Prognosefensters.

Bei Richtlinien mit einer Bedingung wird ein Vorfall erstellt und Benachrichtigungen werden gesendet, wenn die Bedingung erfüllt ist. Diese Vorfälle bleiben offen, während ob die Bedingung weiterhin erfüllt ist.

Google Cloud Console

Sie können das Fenster für die erneute Prüfung mithilfe des Felds Fenster für erneute Prüfung in der Schritt Benachrichtigungstrigger konfigurieren:

API

Sie konfigurieren das Fenster für den erneuten Test, indem Sie das Feld duration in den Strukturen MetricThreshold und MetricAbsence festlegen.

In der Abbildung oben sind drei Auswertungen eines Messwertschwellenwerts dargestellt. . Im Zeit start + 2 minutes ist der ausgerichtete Wert größer als der Grenzwert. Die Bedingung ist jedoch nicht erfüllt, da das Fenster für die erneute Prüfung auf drei Minuten. Die folgende Abbildung zeigt die Ergebnisse für die nächste der Bedingung ausgewertet wird:

Abbildung, die die Auswirkungen des Fensters für die erneute Prüfung veranschaulicht.

Auch wenn der ausgerichtete Wert größer als der Grenzwert ist, Zeit start + 2 minutes, wird die Bedingung erst beim ausgerichteten Wert erfüllt für drei Minuten größer als der Grenzwert ist. Dieses Ereignis tritt zum Zeitpunkt start + 5 minutes auf.

Eine Bedingung setzt das Fenster für den erneuten Test jedes Mal zurück, wenn eine Messung oder Prognose erfolgt die Bedingung nicht erfüllt. Dieses Verhalten wird im Folgenden veranschaulicht: Beispiel:

Beispiel: Diese Benachrichtigungsrichtlinie enthält eine Bedingung für einen Messwertschwellenwert, gibt ein fünfminütiges Fenster für den erneuten Test an.

Wenn die Latenz der HTTP-Antwort mehr als zwei Sekunden beträgt,
Wenn die Latenz fünf Minuten lang über dem Grenzwert liegt,
erstellen Sie einen Vorfall und senden eine E-Mail an das Supportteam.

Die folgende Abfolge zeigt, wie sich das Fenster für den Wiederholungstest auf die Bewertung der Bedingung auswirkt:

  1. Die HTTP-Latenz liegt unter zwei Sekunden.
  2. In den nächsten drei Minuten ist die HTTP-Latenz größer als zwei Sekunden.
  3. Bei der nächsten Messung liegt die Latenz unter zwei Sekunden. Also setzt die Bedingung das Fenster für den nächsten Test zurück.
  4. In den nächsten fünf Minuten ist die HTTP-Latenz größer als damit die Bedingung erfüllt ist.

    Da die Benachrichtigungsrichtlinie eine Bedingung hat, sendet Monitoring Benachrichtigungen, wenn die Bedingung erfüllt ist.

Das Fenster für den erneuten Test sollte lang genug sein, um falsch-positive Ergebnisse zu minimieren. um sicherzustellen, dass Vorfälle zeitnah geöffnet werden können.

Best Practices zum Festlegen des Ausrichtungszeitraums und des Zeitfensters für erneute Tests

Mit dem Ausrichtungszeitraum legen Sie fest, wie viele Stichproben mit dem Aligner kombiniert werden:

  • Der Mindestwert des Ausrichtungszeitraums für einen Messwerttyp ist der Wert Stichprobenzeitraum dieses Messwerttyps. Lautet der Messwerttyp beispielsweise wird alle 300 Sekunden eine Stichprobe erstellt, dann sollte der Ausrichtungszeitraum mindestens 300 Sekunden Wenn Sie jedoch fünf Stichproben kombinieren möchten, legen Sie den Parameter Ausrichtungszeitraum auf 5 × 300 Sekunden oder 1.500 Sekunden festlegen.

  • Der maximale Wert des Ausrichtungszeitraums beträgt 24 Stunden weniger als die Aufnahme Verzögerung des Messwerttyps. Wenn z. B. die Verzögerung bei der Aufnahme eines Messwerts beträgt 6 Stunden, ist der Maximalwert für den Ausrichtungszeitraum 18 Stunden.

Legen Sie im Fenster für den erneuten Test fest, wie schnell die Benachrichtigung ausgegeben werden soll. Beispiel: wenn Sie das Fenster für die erneute Prüfung auf 20 Minuten Bedingung für fehlende Messwerte darf es 20 Minuten lang keine Daten geben, bis die Bedingung erfüllt ist. Wenn Sie eine schneller reagierende Benachrichtigungsrichtlinie festlegen möchten, legen Sie für das Zeitfenster für den Wiederholungstest einen kleineren Wert fest. Um die reaktionsschnellste Benachrichtigungsrichtlinie zu erhalten, Fenster für die erneute Prüfung auf null setzen. Ein einzelner ausgerichteter Wert führt zu diesen Arten von erfüllt sein müssen.

Die Bedingungen der Benachrichtigungsrichtlinie werden mit einer festen Häufigkeit ausgewertet. Die Entscheidungen, die den Sie für den Ausrichtungszeitraum vornehmen und das Fenster für den erneuten Test wie oft die Bedingung ausgewertet wird.

Richtlinien mit mehreren Bedingungen

Eine Benachrichtigungsrichtlinie kann bis zu sechs Bedingungen enthalten.

Wenn Sie die Cloud Monitoring API verwenden oder Ihre Benachrichtigungsrichtlinie mehrere Bedingungen enthält, müssen Sie angeben, wann ein Vorfall geöffnet wird. Zum Konfigurieren mehrere Bedingungen kombinieren, führen Sie einen der folgenden Schritte aus:

Google Cloud Console

Sie konfigurieren die Optionen für die Kombination im Schritt Trigger mit mehreren Bedingungen.

API

Sie konfigurieren Kombinatoroptionen mit dem Feld combiner der AlertPolicy-Struktur.

In dieser Tabelle sind die Einstellungen in der Google Cloud Console in der Cloud Monitoring API und eine Beschreibung jeder Einstellung:

Google Cloud Console
Richtlinie löst Wert aus
Cloud Monitoring API
Kombinationswert
Bedeutung
Eine beliebige Bedingung wird erfüllt OR Ein Vorfall wird geöffnet, wenn eine Ressource dazu führt, dass eine der Bedingungen erfüllt wird.
Alle Bedingungen werden erfüllt
, auch für verschiedene
Ressourcen pro Bedingung.

(Standard)
AND Ein Vorfall wird geöffnet, wenn beide Bedingung erfüllt ist, auch wenn unterschiedliche Ressource sorgt dafür, dass diese Bedingungen erfüllt sind.
Alle Bedingungen werden erfüllt AND_WITH_MATCHING_RESOURCE Ein Vorfall wird geöffnet, wenn nur eine Ressource alle Bedingungen erfüllt. Diese Einstellung ist die strengste Kombinationsoption.

In diesem Kontext bedeutet der Begriff met, dass die Konfiguration der Bedingung als wahr ausgewertet wird. Beispiel: Wenn die Konfiguration Any time series is greater than 10 for 5 minutes lautet und die Anweisung wahr ergibt, wird die Bedingung erfüllt.

Beispiel

Nehmen wir als Beispiel ein Google Cloud-Projekt mit zwei VM-Instanzen, vm1 und vm2. Angenommen, Sie erstellen eine Benachrichtigungsrichtlinie mit zwei Bedingungen:

  • Die Bedingung mit dem Namen CPU usage is too high überwacht die CPU-Nutzung der Instanzen. Diese Bedingung ist erfüllt, wenn die CPU-Nutzung einer beliebigen Instanz über 100 ms/s für 1 Minute.
  • Die Bedingung namens Excessive utilization überwacht die CPU-Auslastung der Instanzen. Diese Bedingung wird erfüllt, wenn die CPU-Auslastung einer Instanz 1 Minute lang über 60 % liegt.

Gehen Sie erst einmal davon aus, dass beide Bedingungen falsch ergeben.

Nehmen wir als Nächstes an, dass die CPU-Auslastung von vm1 1 Minute lang 100 ms/s überschreitet. Weil die CPU-Auslastung für eine Minute größer als der Grenzwert ist, CPU usage is too high ist erfüllt. Wenn die Bedingungen mit Beliebige Bedingung erfüllt kombiniert wird, wird ein Vorfall erstellt, da eine Bedingung erfüllt ist. Wenn die Bedingungen mit Alle Bedingungen sind erfüllt oder Alle Bedingungen werden auch bei verschiedenen Ressourcen für jede Bedingung erfüllt angezeigt werden, ist ein Vorfall nicht erstellt. Diese Kombinationsauswahl erfordert, dass beide Bedingungen erfüllt sind.

Nehmen wir nun an, dass die CPU-Auslastung von vm1 weiterhin über 100 ms/s liegt und die CPU-Auslastung von vm2 1 Minute lang 60 % überschreitet. Dadurch werden beide Bedingungen erfüllt. Im Folgenden wird beschrieben, was je nach Kombination der Bedingungen geschieht:

  • Jede Bedingung wird erfüllt: Ein Vorfall wird erstellt, wenn eine Ressource dazu führt, dass eine Bedingung erfüllt wird. In diesem Beispiel führt vm2 die Bedingung Excessive utilization aus.

    Wenn vm2 die Bedingung CPU usage is too high erfüllt, dann das auch zu einem Vorfall führt. Ein Vorfall wird aus folgenden Gründen erstellt: vm1 und vm2, die zur Erfüllung der Bedingung CPU usage is too high führen sind unterschiedliche Ereignisse.

  • Alle Bedingungen werden erfüllt, auch von verschiedenen Ressourcen pro Bedingung: Es wird ein Vorfall erstellt, da beide Bedingungen erfüllt werden.

  • Alle Bedingungen werden erfüllt: Ein Vorfall wird nicht erzeugt, weil dieser Kombinator erfordert, dass dieselbe Ressource alle Bedingungen erfüllt. In diesem Beispiel wird kein Vorfall erzeugt, weil vm1 bewirkt, dass CPU usage is too high erfüllt wird, während vm2 bewirkt, dass Excessive utilization erfüllt wird.

Unvollständige Messwertdaten

Wenn keine Zeitreihendaten eingehen oder Daten verspätet sind, Monitoring klassifiziert die Daten als fehlend. Fehlende Daten können verhindern, dass Vorfälle abgeschlossen werden. Verzögerungen bei der Dateneingabe aus Cloud-Drittanbieter bis zu 30 Minuten dauern, wobei Verspätungen von 5 bis 15 Minuten am häufigsten sind. Eine lange eine Verzögerung – länger als das Fenster für den erneuten Test – dazu führen kann, dass Bedingungen „Unbekannt“ Bundesstaat. Wenn die Daten schließlich eintreffen, kann Monitoring den jüngsten Verlauf der Bedingungen bereits verloren haben. Bei einer späteren Prüfung der Zeitachsendaten ist dieses Problem möglicherweise nicht erkennbar, weil es keinen Beleg für die Verzögerungen mehr gibt, sobald die Daten eingetroffen sind.

Google Cloud Console

Sie können konfigurieren, wie Monitoring eine Bedingung für Messwertgrenzwerte bewertet, wenn keine Daten mehr eingehen. z. B. wenn ein Vorfall offen ist und eine erwartete Messung nicht ankommt, soll Monitoring den Vorfall öffnen oder sofort schließen? Sollen auch Vorfälle geöffnet werden, wenn keine Daten mehr eingehen und kein Vorfall offen ist? Wie lange sollte ein Vorfall offen bleiben, nachdem keine Daten mehr eingehen?

Es gibt zwei konfigurierbare Felder, die angeben, wie Messwertgrenzwertbedingungen in Monitoring ausgewertet werden, wenn keine Daten mehr eingehen:

  • So konfigurieren Sie, wie Monitoring den Ersatzwert bestimmt für fehlende Daten verwenden Sie das von Ihnen festgelegte Feld Auswertung fehlender Daten. im Schritt Bedingungstrigger aus. Dieses Feld ist deaktiviert, wenn die Fenster zum erneuten Testen ist auf Keine erneute Prüfung festgelegt.

    Das Zeitfenster für den Wiederholungstest ist das Feld „duration“ (Dauer) in der Cloud Monitoring API.

  • So konfigurieren Sie, wie lange Monitoring wartet, bevor es geschlossen wird nach dem Eintreffen der Daten noch offen ist, verwenden Sie Dauer des automatischen Schließens eines Vorfalls. Die Dauer für das automatische Schließen legen Sie im Schritt Benachrichtigung fest. Die Standarddauer für das automatische Schließen ist für 7 Tage.

Im Folgenden werden die verschiedenen Optionen für das fehlende Datenfeld beschrieben:

Google Cloud Console
Feld „Bewertung fehlender Daten“
Fazit Details
Fehlende Daten leer Offene Vorfälle bleiben offen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen erreicht, startet der Timer für das automatische Schließen mit einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

Fehlende Datenpunkte, die als Werte behandelt werden, die gegen die Richtlinienbedingung verstoßen Offene Vorfälle bleiben offen.
Neue Vorfälle können geöffnet werden.

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten eintreffen für die Dauer des automatischen Schließens plus 24 Stunden, wenn der Vorfall geschlossen ist.

Unter Bedingungen, die nicht erfüllt sind, führt diese Einstellung dazu, dass Bedingung für Messwertschwelle so, dass sie sich wie ein metric-absence condition verhält. Wenn Daten nicht innerhalb der im Fenster für die erneute Prüfung festgelegten Zeit eintreffen, gilt die Bedingung als erfüllt. Bei einer Benachrichtigungsrichtlinie mit einer Bedingung wird ein Vorfall geöffnet, wenn die Bedingung erfüllt ist.

Fehlende Datenpunkte werden als Werte behandelt, die nicht gegen die Richtlinienbedingung verstoßen Offene Vorfälle werden geschlossen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, ist sie nicht mehr erfüllt, wenn Daten nicht mehr ankommen. Wenn ein Vorfall für diese Bedingung offen ist, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt werden, ist das auch dann der Fall, wenn keine Daten mehr eingehen.

API

Sie können konfigurieren, wie Monitoring eine Messwertschwellenbedingung, wenn keine Daten eingehen. z. B. wenn ein Vorfall offen ist und eine erwartete Messung nicht ankommt, soll Monitoring den Vorfall öffnen oder sofort schließen? Ähnlich verhält es sich, wenn keine Daten eingehen kein Vorfall offen ist, soll ein Vorfall geöffnet werden? Und schließlich: Sollte ein Vorfall geöffnet bleiben, nachdem keine Daten eingehen?

Es gibt zwei konfigurierbare Felder, die festlegen, wertet Bedingungen für Messwertschwellen aus, wenn keine Daten eingehen:

  • So konfigurieren Sie, wie Monitoring den Ersatzwert bestimmt für fehlende Daten: evaluationMissingData verwenden der MetricThreshold-Struktur fest. Dieses Feld wird ignoriert, wenn das Feld duration null ist.

  • So konfigurieren Sie, wie lange Monitoring wartet, bevor es geschlossen wird Für einen offenen Vorfall, nachdem keine Daten eingehen, verwenden Sie das Feld autoClose. in der AlertStrategy-Struktur.

Im Folgenden werden die verschiedenen Optionen für das fehlende Datenfeld beschrieben:

API
Feld „evaluationMissingData
Fazit Details
EVALUATION_MISSING_DATA_UNSPECIFIED Offene Vorfälle bleiben offen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen erreicht, startet der Timer für das automatische Schließen mit einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt werden, ist das auch dann der Fall, wenn keine Daten mehr eingehen.

EVALUATION_MISSING_DATA_ACTIVE Offene Vorfälle bleiben offen.
Neue Vorfälle können geöffnet werden.

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen für die Dauer der automatischen Schließen-Funktion plus 24 Stunden wenn der Vorfall geschlossen ist.

Unter Bedingungen, die nicht erfüllt sind, führt diese Einstellung dazu, dass Bedingung für Messwertschwelle so, dass sie sich wie ein metric-absence condition verhält. Wenn Daten nicht innerhalb der im Feld „Dauer“ angegebenen Zeit ankommen, gilt die Bedingung als erfüllt. Für eine Benachrichtigungsrichtlinie mit eine Bedingung, die erfüllt ist, führt dazu, dass ein Vorfall geöffnet wird.

EVALUATION_MISSING_DATA_INACTIVE Offene Vorfälle werden geschlossen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, ist sie nicht mehr erfüllt, wenn Daten nicht mehr ankommen. Wenn ein Vorfall für diese Bedingung offen ist, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

Sie können Probleme aufgrund fehlender Daten minimieren, indem Sie einen der folgenden Schritte ausführen:

  • Wenden Sie sich an Ihren Cloud-Drittanbieter, um Möglichkeiten zur Reduzierung Latenz bei der Messwerterfassung.
  • Verwenden Sie in Ihren Bedingungen längere Zeiträume für die Wiederholung von Tests. Längeres Zeitfenster für erneute Tests verwenden hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger reaktionsschnell ist.
  • Wählen Sie Messwerte mit einer geringeren Verzögerung bei der Erfassung aus:

    • Monitoring-Agent-Messwerte, insbesondere wenn der Agent auf VM-Instanzen in Drittanbieterclouds ausgeführt wird
    • Benutzerdefinierte Messwerte, wenn Sie ihre Daten direkt in Monitoring
    • Logbasierte Messwerte, wenn die Erfassung von Logeinträgen nicht verzögert wird

Weitere Informationen finden Sie unter Übersicht zum Monitoring-Agent Übersicht über benutzerdefinierte Messwerte und logbasierte Messwerte:

Wann sendet Monitoring Benachrichtigungen und erstellt Vorfälle?

Cloud Monitoring sendet eine Benachrichtigung, wenn eine Zeitreihe eine Bedingung erfüllt. Die Benachrichtigung wird an alle gesendet Benachrichtigungskanäle. Sie können eine Benachrichtigung nicht auf einen bestimmten Kanal oder auf einen Teil der Kanäle Ihrer Richtlinie beschränken.

Wenn Sie wiederholte Benachrichtigungen konfigurieren, gilt Folgendes: die gleiche Benachrichtigung an eine bestimmte für Ihre Benachrichtigungsrichtlinie.

Sie erhalten möglicherweise mehrere einzelne Benachrichtigungen zu eine Benachrichtigungsrichtlinie zu erhalten, Folgendes zutrifft:

  • Mit einer Bedingung werden mehrere Zeitreihen überwacht.

  • Eine Richtlinie enthält mehrere Bedingungen. In diesem Fall werden die Benachrichtigungen, empfangen, abhängig vom Wert der Multi-Bedingung der Benachrichtigungsrichtlinie Trigger:

    • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, für jede Zeitreihe, bei der eine Bedingung erfüllt ist, sendet die Benachrichtigungsrichtlinie eine Benachrichtigung und erstellt einen Vorfall.

      Sie können Cloud Monitoring nicht so konfigurieren, dass nur ein Vorfall erstellt und nur eine Benachrichtigung senden, wenn die Benachrichtigungsrichtlinie mehrere .

    • Jede Bedingung wird erfüllt: Die Benachrichtigungsrichtlinie sendet eine Benachrichtigung, wenn eine Zeitachse dazu führt, dass eine Bedingung erfüllt wird.

    Weitere Informationen finden Sie unter Richtlinien mit mehreren Bedingungen.

Sie werden auch bei Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt wurden, benachrichtigt wann die Bedingung erfüllt ist und wenn sie nicht mehr erfüllt wird. Benachrichtigungsrichtlinien, die mit der Google Cloud Console erstellt wurden, senden keine Benachrichtigung, wenn die Bedingung nicht mehr erfüllt ist, es sei denn, Sie haben dieses Verhaltens.

Wenn Monitoring keine Benachrichtigungen sendet oder keine Vorfälle erstellt

In den folgenden Situationen werden von Monitoring keine Vorfälle erstellt. oder Benachrichtigungen senden, wenn die Bedingungen einer Benachrichtigungsrichtlinie erfüllt sind:

  • Die Benachrichtigungsrichtlinie ist deaktiviert.
  • Die Benachrichtigungsrichtlinie ist zurückgestellt.
  • Monitoring hat das Limit für die maximale Anzahl von offenen Vorfälle.

Deaktivierte Benachrichtigungsrichtlinien

Beim Monitoring werden keine Erstellungs- oder Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Das Monitoring die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie weiter.

Wenn Sie eine deaktivierte Richtlinie aktivieren, wertet Monitoring die Werte aller Bedingungen im letzten Zeitraum für den erneuten Test. Das letzte Zeitfenster für die erneute Prüfung kann Daten enthalten, die vor, während und nach der Prüfung erfasst wurden. die Richtlinie aktiviert wurde. Die Bedingungen einer deaktivierten Richtlinie können sofort erfüllt werden wieder aktivieren, selbst bei großen Testfenstern.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie, die eine bestimmte und dass Sie diese Richtlinie deaktivieren. In der folgenden Woche wird der Prozess fällt aus. Da die Benachrichtigungsrichtlinie deaktiviert ist, werden Sie nicht benachrichtigt. Wenn Sie den Prozess neu starten und die Benachrichtigungsrichtlinie sofort aktivieren, Das Monitoring erkennt, dass der Prozess und erstellt einen Vorfall.

Die Vorfälle im Zusammenhang mit einer deaktivierten Benachrichtigungsrichtlinie bleiben so lange offen, bis der Richtlinie für das automatische Schließen abläuft.

Zurückgestellte Benachrichtigungsrichtlinien

Monitoring sendet keine Benachrichtigungen und erstellt keine Vorfälle für eine Benachrichtigungsrichtlinie, die zurückgestellt ist. Wir empfehlen die Schlummerfunktion. wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie nur kurze Benachrichtigungen erhalten. Beispielsweise können Sie vor der Wartung einer virtuellen Maschine (VM) eine Schlummerfunktion erstellen und den Schlummerkriterien die Benachrichtigungsrichtlinien hinzufügen, die die Instanz überwachen.

Wenn Sie eine Benachrichtigungsrichtlinie pausieren, werden in Monitoring alle offenen Vorfälle im Zusammenhang mit der Richtlinie geschlossen. Überwachung können nach Ablauf der Schlummerfunktion neue Vorfälle öffnen. Weitere Informationen finden Sie unter Benachrichtigungen deaktivieren

Einschränkungen bei Benachrichtigungen und offenen Vorfällen

Eine Benachrichtigungsrichtlinie kann für viele Ressourcen gelten und ein Problem alle Ressourcen dazu führen können, dass die Benachrichtigungsrichtlinie Vorfälle für jede . Für jede Zeitreihe, die eine Bedingung erfüllt, wird ein Vorfall geöffnet.

Um eine Überlastung des Systems zu vermeiden, gleichzeitig geöffnet werden kann,ist auf 1.000 begrenzt.

Stellen Sie sich beispielsweise eine Richtlinie vor, die für 2000 Compute Engine und jede Instanz führt dazu, dass die Bedingungen für Benachrichtigungen erfüllt sind. Monitoring begrenzt die Anzahl der offenen Vorfälle auf 1.000. Alle verbleibenden Bedingungen, die erfüllt sind, bis einige der offenen Vorfälle für diese Richtlinie geschlossen werden.

Aufgrund dieser Beschränkung kann ein einzelner Benachrichtigungskanal bis zu 1.000 Benachrichtigungen gleichzeitig. Wenn Ihre Benachrichtigungen hat die Richtlinie mehrere Benachrichtigungskanäle, dann gilt diese Beschränkung für jeden unabhängig vom Benachrichtigungskanal.

Latenz

Latenz bezieht sich auf die Verzögerung zwischen der Erfassung einer und wann der Messwertdatenpunkt als Zeitreihendaten sichtbar wird. Die Latenz wirkt sich darauf aus, wann Benachrichtigungen gesendet werden. Wenn z. B. eine überwachte eine Latenz von bis zu 180 Sekunden hat, Das Monitoring erstellt bis zu 180 Sekunden lang keinen Vorfall. wird die Bedingung der Benachrichtigungsrichtlinie als "true" ausgewertet. Weitere Informationen finden Sie unter Latenz von Messwertdaten.

Die folgenden Ereignisse und Einstellungen tragen zur Latenz bei:

  • Verzögerung der Messwerterfassung: Die Zeit, die Monitoring benötigt, um Messwerte erfassen können. Für Google Cloud-Werte sind die meisten Messwerte nicht nach der Erfassung 60 Sekunden lang sichtbar; Die Verzögerung hängt jedoch davon ab, auf den Messwert. Berechnung von Benachrichtigungsrichtlinien dauert eine zusätzliche Verzögerung zwischen 60 und 90 Sekunden. Bei AWS CloudWatch-Messwerten ist die Sichtbarkeitsverzögerung mehrere Minuten dauern. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten (ab dem Ende des Zeitfensters für den erneuten Test).

  • Testfenster: Das für die Bedingung konfigurierte Fenster. Bedingungen sind nur dann erfüllt, wenn während des gesamten erneuten Tests eine Bedingung erfüllt ist . Eine von fünf Minuten festgelegte Zeit für die erneute Prüfung führt beispielsweise dazu, eine Verzögerung von mindestens fünf Minuten nach der Ereignis zuerst ein.

  • Zeit bis zum Eintreffen der Benachrichtigung: Auch innerhalb von Benachrichtigungskanälen wie E-Mail und SMS können unabhängig vom übermittelten Inhalt Netzwerk- oder sonstige Latenzen auftreten – manchmal in der Größenordnung von mehreren Minuten. Auf einigen Kanälen wie SMS und Slack kann nicht garantiert werden, dass die Nachrichten zugestellt werden.

Nächste Schritte