Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie anhand von Ausrichtungszeiträumen und Testzeiträumen bestimmt wird, ob eine Bedingung erfüllt ist, wie in Benachrichtigungsrichtlinien mehrere Bedingungen kombiniert werden und wie in Benachrichtigungsrichtlinien fehlende Datenpunkte ersetzt werden. Außerdem wird die maximale Anzahl offener Vorfälle für eine Richtlinie, die Anzahl der Benachrichtigungen pro Vorfall und die Ursachen für Benachrichtigungsverzögerungen beschrieben.

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

Ausrichtungszeiträume und Zeitfenster für Wiederholungstests

Cloud Monitoring wertet den Ausrichtungszeitraum und das Fenster für den erneuten Test aus, um zu ermitteln, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt wurde.

Ausrichtungszeitraum

Bevor Zeitreihendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie normalisiert werden, damit die Benachrichtigungsrichtlinie regelmäßig verteilte Daten zur Auswertung hat. Dieser Vorgang wird als Ausrichtung bezeichnet.

Die Ausrichtung umfasst zwei Schritte:

  • Unterteilen der Zeitachsen in regelmäßige Zeitintervalle, auch Daten-Bucketing genannt. Das Intervall ist der Ausrichtungszeitraum.

  • Einen einzelnen Wert für die Punkte im Ausrichtungszeitraum berechnen Sie können wählen, wie dieser einzelne Punkt berechnet werden soll. Sie können alle Werte summieren, ihren Durchschnitt berechnen oder das Maximum verwenden. Die Funktion, mit der die Datenpunkte kombiniert werden, wird als Aligner bezeichnet. Das Ergebnis der Kombination wird als ausgerichteter Wert bezeichnet.

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

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

Im Monitoring wird ein Kalibrierungszeitraum 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 Zeitraum an, der ausgewertet werden soll.
  • Funktion für rollierendes Zeitfenster: Gibt die mathematische Funktion an, die auf das Datenfenster angewendet werden soll.

Weitere Informationen zu den verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. 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 ausführliche Erläuterung finden Sie unter 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. 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 ausführliche Erläuterung finden Sie unter Arten, Typen und Conversions.

Zur Veranschaulichung der Auswirkungen eines Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie: Stellen Sie sich eine Messwertschwellenbedingung vor, die einen Messwert mit einem Stichprobenzeitraum von einer Minute überwacht. Angenommen, der Ausrichtungszeitraum ist auf 5 Minuten und der Aligner auf sum eingestellt. Nehmen wir außerdem an, dass die Bedingung erfüllt ist, wenn der ausgerichtete Wert der Zeitreihe mindestens drei Minuten lang größer als zwei ist und die Bedingung jede Minute ausgewertet wird. In diesem Beispiel beträgt der Ausrichtungszeitraum zwei Minuten und das Fenster für den Wiederholungstest, das im nächsten Abschnitt beschrieben wird, drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

Abbildung zur Auswirkung des Ausrichtungszeitraums auf das Fenster/die Dauer der Wiederholung

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 zeigt den ausgerichteten Wert und gibt an, ob der Wert über dem Schwellenwert von zwei liegt. Für die Zeile mit der Beschriftung start ergibt der ausgerichtete Wert 1, was unter dem Schwellenwert liegt. Bei der nächsten Auswertung ergibt die Summe der Stichproben im Ausrichtungszeitraum zwei. Bei der dritten Auswertung beträgt die Summe drei. Da dieser Wert über dem Schwellenwert liegt, wird ein Timer für das Zeitfenster für den Wiederholungstest gestartet.

Zeitfenster noch einmal testen

Die Bedingung einer Benachrichtigungsrichtlinie hat ein Wiederholfenster, das verhindert, dass die Bedingung aufgrund einer einzelnen Messung oder Prognose erfüllt wird. Angenommen, das Fenster für die Wiederholung eines Tests einer Bedingung ist auf 15 Minuten festgelegt. Im Folgenden wird das Verhalten der Bedingung je nach Typ beschrieben:

  • Messwertgrenzwertbedingungen sind erfüllt, wenn für eine einzelne Zeitreihe jede ausgerichtete Messung in einem 15-Minuten-Intervall den Grenzwert überschreitet.
  • Bedingungen für fehlende Messwerte werden erfüllt, wenn für eine Zeitachse in einem 15-Minuten-Intervall keine Daten eintreffen.
  • Die Prognosebedingungen sind erfüllt, wenn in jeder Prognose, die in einem 15-Minuten-Fenster erstellt wird, vorhergesagt wird, dass die Zeitreihe innerhalb des Prognosezeitraums den Grenzwert überschreitet.

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

Google Cloud Console

Sie konfigurieren das Fenster für den Wiederholungstest im Feld Fenster für Wiederholungstest im Schritt Trigger für Benachrichtigungen konfigurieren.

API

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

Die vorherige Abbildung zeigt drei Auswertungen einer Bedingung mit Messwertgrenzwert. Zum Zeitpunkt start + 2 minutes ist der ausgerichtete Wert über dem Schwellenwert. Diese Bedingung wird jedoch nicht erfüllt, da das Fenster für den Wiederholungstest auf drei Minuten festgelegt ist. Die folgende Abbildung veranschaulicht die Ergebnisse für die nächsten Auswertungen der Bedingung:

Abbildung zur Auswirkung des Fensters für den Wiederholungstest

Auch wenn der ausgerichtete Wert zum Zeitpunkt start + 2 minutes über dem Schwellenwert liegt, wird die Bedingung erst dann erfüllt, wenn der ausgerichtete Wert drei Minuten lang über dem Schwellenwert liegt. Dieses Ereignis tritt zum Zeitpunkt start + 5 minutes auf.

Das Fenster für den Wiederholungstest einer Bedingung wird jedes Mal zurückgesetzt, wenn eine Messung oder Prognose die Bedingung nicht erfüllt. Dieses Verhalten wird im folgenden Beispiel veranschaulicht:

Beispiel: Diese Benachrichtigungsrichtlinie enthält eine Bedingung für einen Messwertgrenzwert, für die ein Zeitfenster für einen erneuten Test von fünf Minuten festgelegt ist.

Wenn die HTTP-Antwortlatenz länger als zwei Sekunden ist,
und wenn die Latenz fünf Minuten lang über diesem Grenzwert liegt,
sollten ein Vorfall erstellt und eine E-Mail an das Supportteam gesendet werden.

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 liegt die HTTP-Latenz über 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 liegt die HTTP-Latenz über zwei Sekunden, sodass 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 Wiederholungstest sollte lang genug sein, um falsch positive Ergebnisse zu minimieren, aber gleichzeitig auch so kurz, dass Vorfälle möglichst frühzeitig geöffnet werden.

Best Practices für die Einstellung des Ausrichtungszeitraums und des Fensters für die Wiederholung

Der Ausrichtungszeitraum bestimmt, wie viele Stichproben mit dem Aligner kombiniert werden:

  • Der Mindestwert des Abgleichzeitraums für einen Messwerttyp ist der Stichprobenzeitraum dieses Messwerttyps. Wenn der Messwerttyp beispielsweise alle 300 Sekunden als Stichprobe verwendet wird, sollte der Alignierungszeitraum mindestens 300 Sekunden betragen. Wenn Sie jedoch 5 Stichproben kombinieren möchten, legen Sie den Alignierungszeitraum auf 5 × 300 Sekunden oder 1.500 Sekunden fest.

  • Der maximale Wert des Ausrichtungszeitraums beträgt 24 Stunden abzüglich der Datenaufnahmeverzögerung des Messwerttyps. Wenn die Datenaufnahmeverzögerung für einen Messwert beispielsweise 6 Stunden beträgt, ist der maximale Wert des Ausrichtungszeitraums 18 Stunden.

Mit dem Testfenster können Sie die Reaktionsfähigkeit der Benachrichtigung angeben. Wenn Sie beispielsweise das Fenster für den erneuten Test für eine Bedingung für fehlende Messwerte auf 20 Minuten festlegen, müssen 20 Minuten lang keine Daten vorhanden sein, bevor die Bedingung erfüllt ist. Wenn Sie eine reaktionsschnellere Benachrichtigungsrichtlinie festlegen möchten, legen Sie für das Zeitfenster für den erneuten Test einen kleineren Wert fest. Wenn Sie für Bedingungen mit Messwertgrenzwerten die reaktionsschnellste Benachrichtigungsrichtlinie verwenden möchten, setzen Sie das Fenster für den erneuten Test auf null. Durch einen einzelnen ausgerichteten Wert werden diese Arten von Bedingungen erfüllt.

Die Bedingungen der Benachrichtigungsrichtlinie werden mit einer festen Häufigkeit ausgewertet. Die Auswahl des Ausrichtungszeitraums und des Zeitfensters für die Wiederholung hat keinen Einfluss darauf, 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. So konfigurieren Sie, wie mehrere Bedingungen kombiniert werden:

Google Cloud Console

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

API

Sie konfigurieren die Optionen für den Combiner mit dem Feld combiner der Struktur AlertPolicy.

In dieser Tabelle werden die Einstellungen in der Google Cloud Console, der entsprechende Wert in der Cloud Monitoring API und eine Beschreibung der einzelnen Einstellungen aufgeführt:

Google Cloud Console
Wert für Richtlinientrigger
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 jede Bedingung erfüllt wird, auch wenn eine andere Ressource dazu führt, dass alle Bedingungen erfüllt werden.
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 wird erfüllt, wenn die CPU-Nutzung einer Instanz 1 Minute lang über 100 ms/s liegt.
  • 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. Da die CPU-Auslastung eine Minute lang über dem Grenzwert liegt, ist die Bedingung CPU usage is too high 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, führt dies außerdem dazu, dass ein Vorfall erstellt wird. Es wird ein Vorfall erstellt, weil vm1 und vm2, die die Bedingung CPU usage is too high erfüllen, unterschiedliche Ereignisse sind.

  • 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 mehr eingehen oder es zu Verzögerungen kommt, werden die Daten im Monitoring als fehlend klassifiziert. Fehlende Daten können verhindern, dass Vorfälle geschlossen werden. Die Übermittlung der Daten von Cloud-Drittanbietern kann sich bis zu 30 Minuten verzögern. In der Regel beträgt die Verzögerung 5 bis 15 Minuten. Wenn eine Verzögerung länger als das Fenster für den Wiederholungstest ist, können Bedingungen den Status „Unbekannt“ erhalten. 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. Soll ein Vorfall beispielsweise offen bleiben, wenn eine erwartete Messung nicht eintrifft, oder soll er sofort geschlossen werden? 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:

  • Um zu konfigurieren, wie der Ersatzwert für fehlende Daten ermittelt wird, verwenden Sie das Feld Bewertung fehlender Daten, das Sie im Schritt Bedingungstrigger festlegen. Dieses Feld ist deaktiviert, wenn das Zeitfenster für den Wiederholungstest auf Kein Wiederholungstest festgelegt ist.

    Das Fenster für den Wiederholungstest ist das Feld „Dauer“ in der Cloud Monitoring API.

  • Mit dem Feld Dauer bis zur automatischen Schließung von Vorfällen können Sie konfigurieren, wie lange das Monitoring wartet, bevor ein offener Vorfall geschlossen wird, wenn keine Daten mehr eingehen. Die Dauer für das automatische Schließen legen Sie im Schritt Benachrichtigung fest. Die Standarddauer für die automatische Schließung beträgt sieben Tage.

Im Folgenden werden die verschiedenen Optionen für das Feld „Fehlende Daten“ 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 eine Bedingung erfüllt ist, bleibt sie auch erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er offen. Wenn ein Vorfall geöffnet ist und keine Daten eingehen, startet der Timer für die automatische Schließung nach 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.

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

Wenn eine Bedingung erfüllt ist, bleibt sie auch erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er offen. Wenn ein Vorfall geöffnet ist und während der Dauer der automatischen Schließung plus 24 Stunden keine Daten eingehen, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, führt diese Einstellung dazu, dass sich die Bedingung für Messwertschwellen wie eine metric-absence condition verhält. Wenn keine Daten innerhalb des im Fenster für den erneuten Test angegebenen Zeitraums eintreffen, wird die Bedingung als erfüllt ausgewertet. 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.

Bei erfüllten Bedingungen ist das nicht mehr der Fall, wenn keine Daten mehr eingehen. Wenn ein Vorfall aufgrund dieser Bedingung geöffnet ist, wird er 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 Bedingung für Messwertgrenzwerte bewertet, wenn keine Daten mehr eingehen. Soll ein Vorfall beispielsweise offen bleiben, wenn eine erwartete Messung nicht eintrifft, oder soll er sofort geschlossen werden? 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:

  • Mit dem Feld evaluationMissingData der Struktur MetricThreshold können Sie konfigurieren, wie der Ersatzwert für fehlende Daten ermittelt wird. Dieses Feld wird ignoriert, wenn das Feld duration den Wert 0 hat.

  • Mit dem Feld autoClose in der Struktur AlertStrategy können Sie konfigurieren, wie lange Monitoring wartet, bevor ein offener Vorfall geschlossen wird, nachdem keine Daten mehr eingehen.

Im Folgenden werden die verschiedenen Optionen für das Feld „Fehlende Daten“ beschrieben:

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

Wenn eine Bedingung erfüllt ist, bleibt sie auch erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er offen. Wenn ein Vorfall geöffnet ist und keine Daten eingehen, startet der Timer für die automatische Schließung nach 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 eine Bedingung erfüllt ist, bleibt sie auch erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er offen. Wenn ein Vorfall geöffnet ist und während der Dauer der automatischen Schließung plus 24 Stunden keine Daten eingehen, wird er geschlossen.

Wenn Bedingungen nicht erfüllt sind, führt diese Einstellung dazu, dass sich die Bedingung für Messwertschwellen wie eine metric-absence condition verhält. Wenn Daten nicht innerhalb des im Feld „duration“ angegebenen Zeitraums eintreffen, wird die Bedingung als erfüllt ausgewertet. Bei einer Benachrichtigungsrichtlinie mit einer Bedingung wird ein Vorfall geöffnet, wenn die Bedingung erfüllt ist.

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

Bei erfüllten Bedingungen ist das nicht mehr der Fall, wenn keine Daten mehr eingehen. Wenn ein Vorfall aufgrund dieser Bedingung geöffnet ist, wird er geschlossen.

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

So können Sie Probleme durch fehlende Daten minimieren:

  • Wenden Sie sich an Ihren Cloud-Drittanbieter, um Möglichkeiten zur Verringerung der Latenz bei der Messwerterfassung zu finden.
  • Verwenden Sie in Ihren Bedingungen längere Zeiträume für die Wiederholung von Tests. Ein längeres Wiederholungsfenster hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger schnell reagieren.
  • 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 deren Daten direkt in Monitoring schreiben
    • Logbasierte Messwerte, wenn die Erfassung von Logeinträgen nicht verzögert ist

Weitere Informationen finden Sie unter Monitoring-Agent – Übersicht, Benutzerdefinierte Messwerte – Übersicht und Logbasierte Messwerte.

Wann Monitoring Benachrichtigungen sendet und Vorfälle erstellt

Cloud Monitoring sendet eine Benachrichtigung, wenn eine Zeitreihe eine Bedingung erfüllt. Die Benachrichtigung wird an alle Benachrichtigungskanäle gesendet. 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, wird dieselbe Benachrichtigung an bestimmte Benachrichtigungskanäle für Ihre Benachrichtigungsrichtlinie gesendet.

Sie erhalten möglicherweise mehrere eindeutige Benachrichtigungen im Zusammenhang mit einer Benachrichtigungsrichtlinie, wenn einer der folgenden Punkte zutrifft:

  • Eine Bedingung überwacht mehrere Zeitreihen.

  • Eine Richtlinie enthält mehrere Bedingungen. In diesem Fall hängen die Benachrichtigungen, die Sie erhalten, vom Wert des Trigger mit mehreren Bedingungen der Benachrichtigungsrichtlinie ab:

    • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, sendet die Benachrichtigungsrichtlinie für jede Zeitachse, die zu einer Bedingung führt, eine Benachrichtigung und erstellt einen Vorfall.

      Sie können Cloud Monitoring nicht so konfigurieren, dass in diesem Fall nur ein einzelner Vorfall erstellt und eine einzelne Benachrichtigung gesendet wird, wenn die Benachrichtigungsrichtlinie mehrere Bedingungen enthält.

    • 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.

Bei Benachrichtigungsrichtlinien, die mithilfe der Cloud Monitoring API erstellt wurden, werden Sie auch benachrichtigt, wenn die Bedingung erfüllt ist und wenn sie nicht mehr erfüllt wird. Bei Benachrichtigungsrichtlinien, die mit der Google Cloud Console erstellt wurden, wird keine Benachrichtigung gesendet, wenn die Bedingung nicht mehr erfüllt ist, es sei denn, Sie haben dieses Verhalten aktiviert.

Wenn Monitoring keine Benachrichtigungen sendet oder keine Vorfälle erstellt

In den folgenden Fällen werden in Monitoring keine Vorfälle erstellt und keine Benachrichtigungen gesendet, wenn die Bedingungen einer Benachrichtigungsrichtlinie erfüllt sind:

  • Die Benachrichtigungsrichtlinie ist deaktiviert.
  • Die Benachrichtigungsrichtlinie ist im Schlummermodus.
  • Die maximale Anzahl offener Vorfälle wurde erreicht.

Deaktivierte Benachrichtigungsrichtlinien

Monitoring sendet keine Vorfälle und keine Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie werden jedoch weiterhin von Monitoring ausgewertet.

Wenn Sie eine deaktivierte Richtlinie aktivieren, werden die Werte aller Bedingungen über das letzte Wiedertestfenster ausgewertet. Das letzte Testfenster kann Daten enthalten, die vor, während und nach der Aktivierung der Richtlinie erfasst wurden. Die Bedingungen einer deaktivierten Richtlinie können auch bei großen Zeiträumen für Wiederholungstests sofort nach der Reaktivierung erfüllt werden.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie, die einen bestimmten Prozess überwacht, und Sie deaktivieren diese Richtlinie. In der folgenden Woche bricht der Prozess ab. Da die Benachrichtigungsrichtlinie deaktiviert ist, werden Sie nicht benachrichtigt. Wenn Sie den Prozess neu starten und die Benachrichtigungsrichtlinie sofort aktivieren, erkennt Monitoring, dass der Prozess in den letzten fünf Minuten nicht ausgeführt wurde, und öffnet einen Vorfall.

Vorfälle im Zusammenhang mit einer deaktivierten Benachrichtigungsrichtlinie bleiben offen, bis die automatische Schließungsdauer der Richtlinie abgelaufen ist.

Pausierte Benachrichtigungsrichtlinien

Für eine ausgeblendete Benachrichtigungsrichtlinie werden keine Benachrichtigungen gesendet und es werden keine Vorfälle erstellt. Wir empfehlen, Benachrichtigungsrichtlinien zu pausieren, wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie nur in kurzen Intervallen Benachrichtigungen sendet. Beispiel: Bevor Sie Wartungsarbeiten an einer virtuellen Maschine (VM) durchführen, können Sie eine Schlummerfunktion erstellen und den Schlummerkriterien die Benachrichtigungsrichtlinien hinzufügen, die die Instanz überwachen.

Wenn Sie eine Benachrichtigungsrichtlinie pausieren, schließt Monitoring alle offenen Vorfälle im Zusammenhang mit der Richtlinie. Monitoring kann nach Ablauf der Schlummerzeit neue Vorfälle öffnen. Weitere Informationen finden Sie unter Benachrichtigungen und Warnungen aufschieben.

Einschränkungen bei Benachrichtigungen und offenen Vorfällen

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

Damit das System nicht überlastet wird, ist die Anzahl der Vorfälle, die eine einzelne Richtlinie gleichzeitig öffnen kann, auf 1.000 begrenzt.

Angenommen, eine Richtlinie gilt für 2.000 Compute Engine-Instanzen und bei jeder Instanz werden die Benachrichtigungsbedingungen erfüllt. Bei der Überwachung ist die Anzahl der offenen Vorfälle auf 1.000 begrenzt. Alle verbleibenden erfüllten Bedingungen werden ignoriert, bis einige der offenen Vorfälle für diese Richtlinie behoben wurden.

Aufgrund dieses Limits kann ein einzelner Benachrichtigungskanal bis zu 1.000 Benachrichtigungen gleichzeitig erhalten. Wenn Ihre Benachrichtigungsrichtlinie mehrere Benachrichtigungskanäle hat, gilt dieses Limit für jeden Benachrichtigungskanal unabhängig voneinander.

Latenz

Die Latenz bezieht sich auf die Verzögerung zwischen dem Zeitpunkt, zu dem ein Messwert in Monitoring erfasst wird, und dem Zeitpunkt, zu dem der Messwertdatenpunkt als Zeitreihendaten sichtbar wird. Die Latenz wirkt sich darauf aus, wann Benachrichtigungen gesendet werden. Wenn ein überwachter Messwert beispielsweise eine Latenz von bis zu 180 Sekunden hat, wird im Monitoring erst nach bis zu 180 Sekunden nach dem Auslösen der Benachrichtigungsrichtlinienbedingung ein Vorfall erstellt. 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 zur Erfassung von Messwerten benötigt. Bei Google Cloud-Werten sind die meisten Messwerte nach der Erfassung 60 Sekunden lang nicht sichtbar. Die Verzögerung hängt jedoch vom Messwert ab. Die Berechnungen der Benachrichtigungsrichtlinien dauern zusätzlich 60 bis 90 Sekunden. Bei AWS CloudWatch-Messwerten kann die Sichtbarkeitsverzögerung mehrere Minuten betragen. Bei Verfügbarkeitsdiagnosen kann diese durchschnittlich zwei Minuten dauern (ab dem Ende des Wiederholungszeitraums).

  • Zeitfenster noch einmal testen: das für die Bedingung konfigurierte Zeitfenster. Bedingungen sind nur dann erfüllt, wenn dies während des gesamten Wiederholungszeitraums der Fall ist. Wenn Sie beispielsweise ein Zeitfenster für den Wiederholungstest von fünf Minuten festlegen, wird die Benachrichtigung mindestens fünf Minuten nach dem ersten Ereignis verzögert.

  • 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