Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie Ausrichtungszeiträume und Zeitfenster für erneute Tests bestimmen, wann eine Bedingung erfüllt ist, wie Benachrichtigungsrichtlinien mehrere Bedingungen kombinieren und wie Benachrichtigungsrichtlinien fehlende Datenpunkte ersetzen. Außerdem werden die maximale Anzahl offener Vorfälle für eine Richtlinie, die Anzahl der Benachrichtigungen pro Vorfall und die Ursachen von 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 erneute Tests

Cloud Monitoring wertet den Ausrichtungszeitraum aus und testet das Fenster noch einmal, um festzustellen, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt wurde.

Ausrichtungszeitraum

Bevor Zeitreihendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie reguliert werden, damit die Benachrichtigungsrichtlinie regelmäßig Daten zur Auswertung in regelmäßigen Abständen enthält. Der Regularisierungsprozess wird als alignment bezeichnet.

Die Ausrichtung umfasst zwei Schritte:

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

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

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

Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten beträgt, um 13:00 Uhr, enthält der Ausrichtungszeitraum 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

Zum Konfigurieren des Ausrichtungszeitraums wählen Sie auf der Seite Benachrichtigungsbedingungen einen Wert für die folgenden Felder aus:

  • Rollierendes Fenster: Gibt den auszuwertenden Zeitraum an.
  • Funktion für rollierendes Fenster: Gibt die mathematische Funktion an, die für das Fenster von Datenpunkten ausgeführt werden soll.

Weitere Informationen zu verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Mit einigen der Aligner-Funktionen werden die Daten ausgerichtet und 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

Zum Konfigurieren des Ausrichtungszeitraums legen Sie die Felder aggregations.alignmentPeriod und aggregations.perSeriesAligner in den Strukturen MetricThreshold und MetricAbsence fest.

Weitere Informationen zu verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Mit einigen der Aligner-Funktionen werden die Daten ausgerichtet und 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 des Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie wird eine Messwertschwellenbedingung betrachtet, mit der ein Messwert mit einem Stichprobenzeitraum von einer Minute überwacht wird. Es wird angenommen, dass der Ausrichtungszeitraum auf fünf Minuten und der Aligner auf sum festgelegt ist. Außerdem wird angenommen, dass die Bedingung erfüllt ist, wenn der ausgerichtete Wert der Zeitachse mindestens drei Minuten lang größer als zwei ist, 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, das im nächsten Abschnitt beschrieben wird, 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. In jeder Zeile wird der ausgerichtete Wert angezeigt und es wird angegeben, ob dieser Wert größer als der Grenzwert von zwei ist. Für die Zeile start berechnet der ausgerichtete Wert einen Wert, der kleiner als der Grenzwert ist. Bei der nächsten Bewertung beträgt die Summe der Stichproben im Ausrichtungszeitraum zwei. Bei der dritten Auswertung beträgt die Summe drei. Da dieser Wert größer als der Grenzwert ist, wird ein Timer für das Fenster der erneuten Prüfung gestartet.

Fenster noch einmal testen

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

  • Bedingungen für Messwertschwellen sind erfüllt, wenn für eine einzelne Zeitachse jede ausgerichtete Messung in einem 15-Minuten-Intervall gegen den Grenzwert verstößt.
  • Bedingungen für fehlende Messwerte sind erfüllt, wenn für eine Zeitachse in einem 15-Minuten-Intervall keine Daten eintreffen.
  • Die Prognosebedingungen sind erfüllt, wenn jede Prognose, die während eines 15-Minuten-Zeitfensters erstellt wird, vorhersagt, dass die Zeitreihe gegen den Grenzwert innerhalb des Prognosefensters verstößt.

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

Google Cloud Console

Sie konfigurieren das Fenster für die erneute Prüfung mithilfe des Felds Fenster noch einmal prüfen im Schritt Benachrichtigungstrigger konfigurieren.

API

Zum Konfigurieren des Fensters für die erneute Prüfung legen Sie das Feld duration in den Strukturen MetricThreshold und MetricAbsence fest.

In der vorherigen Abbildung sind drei Auswertungen einer Bedingung für Messwertschwellen dargestellt. Zum Zeitpunkt start + 2 minutes ist der ausgerichtete Wert größer als der Grenzwert. Die Bedingung ist jedoch nicht erfüllt, da das Fenster für den erneuten Test auf drei Minuten gesetzt ist. Die folgende Abbildung zeigt die Ergebnisse für die nächsten Bewertungen der Bedingung:

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

Auch wenn der ausgerichtete Wert zum Zeitpunkt start + 2 minutes größer als der Grenzwert ist, ist die Bedingung erst erfüllt, wenn der ausgerichtete Wert drei Minuten lang größer als der Grenzwert ist. Dieses Ereignis tritt um start + 5 minutes ein.

Eine Bedingung setzt das Fenster für den erneuten Test jedes Mal zurück, 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 Messwertschwellenwert, die ein fünfminütiges Fenster für einen erneuten Test vorgibt.

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

Die folgende Abfolge veranschaulicht, wie sich das Fenster für den erneuten Test auf die Bewertung der Bedingung auswirkt:

  1. Die HTTP-Latenz beträgt weniger als zwei Sekunden.
  2. In den nächsten drei Minuten ist die HTTP-Latenz größer als zwei Sekunden.
  3. Bei der nächsten Messung beträgt die Latenz weniger als zwei Sekunden, sodass die Bedingung das Fenster für die Wiederholung des Tests zurücksetzt.

  4. In den nächsten fünf Minuten ist die HTTP-Latenz größer als zwei Sekunden, sodass die Bedingung erfüllt ist.

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

Das Zeitfenster für den erneuten Test sollte lang genug sein, um falsch positive Ergebnisse zu minimieren, aber auch kurz genug, um sicherzustellen, dass Vorfälle rechtzeitig geöffnet werden.

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 Stichprobenzeitraum dieses Messwerttyps. Wenn für den Messwerttyp beispielsweise alle 300 Sekunden eine Stichprobe erfasst wird, sollte der Ausrichtungszeitraum mindestens 300 Sekunden betragen. Wenn Sie jedoch 5 Beispiele kombinieren möchten, legen Sie den Ausrichtungszeitraum auf 5 * 300 Sekunden oder 1.500 Sekunden fest.

  • Der maximale Wert des Ausrichtungszeitraums beträgt 24 Stunden weniger als die Aufnahmeverzögerung des Messwerttyps. Wenn die Aufnahmeverzögerung für einen Messwert beispielsweise 6 Stunden beträgt, beträgt der Maximalwert des Ausrichtungszeitraums 18 Stunden.

Legen Sie im Fenster für den erneuten Test fest, wie schnell die Benachrichtigung ausgegeben werden soll. Wenn Sie beispielsweise das Fenster für den erneuten Test für eine Bedingung für fehlende Messwerte auf 20 Minuten festlegen, dürfen 20 Minuten lang keine Daten vorhanden sein, bevor die Bedingung erfüllt ist. Legen Sie für die Benachrichtigungsrichtlinie einen kleineren Wert für das Fenster für den erneuten Test fest. Wenn Sie eine Benachrichtigungsrichtlinie für Messwerte mit Schwellenwerten verwenden möchten, setzen Sie das Fenster für den erneuten Test auf null. Ein einzelner ausgerichteter Wert führt dazu, dass diese Arten von Bedingungen erfüllt sind.

Bedingungen für Benachrichtigungsrichtlinien werden mit einer festen Häufigkeit ausgewertet. Die Auswahl, die Sie für den Ausrichtungszeitraum und das Zeitfenster für die erneute Prüfung treffen, bestimmen nicht, 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. Führen Sie einen der folgenden Schritte aus, um zu konfigurieren, wie mehrere Bedingungen kombiniert werden:

Google Cloud Console

Sie konfigurieren Kombinatoroptionen im Schritt Trigger mit mehreren Bedingungen.

API

Sie konfigurieren Kombinatoroptionen mit dem Feld combiner der Struktur AlertPolicy.

In der folgenden Tabelle sind die Einstellungen in der Google Cloud Console, der entsprechende Wert in der Cloud Monitoring API und eine Beschreibung jeder Einstellung aufgeführt:

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 jede Bedingung erfüllt ist, auch wenn eine andere Ressource dazu führt, 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 true ausgewertet wird. Wenn die Konfiguration beispielsweise Any time series is greater than 10 for 5 minutes lautet und diese Anweisung als true ausgewertet wird, ist 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-Auslastung einer Instanz eine Minute lang mehr als 100 ms/s beträgt.
  • Die Bedingung namens Excessive utilization überwacht die CPU-Auslastung der Instanzen. Diese Bedingung ist erfüllt, wenn die CPU-Auslastung einer Instanz eine Minute lang über 60% liegt.

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

Nehmen wir als Nächstes an, dass die CPU-Auslastung von vm1 1 Minute lang 100 ms/s überschreitet. Da die CPU-Nutzung eine Minute lang über dem Schwellenwert 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 als Nächstes an, dass die CPU-Auslastung von vm1 weiterhin über 100 ms/s liegt und dass die CPU-Auslastung von vm2 eine 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 ebenfalls zur Erstellung eines Vorfalls. 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 Zeitachsendaten mehr eingehen oder Daten verspätet sind, klassifiziert Monitoring die Daten als fehlend. Fehlende Daten können verhindern, dass Vorfälle abgeschlossen werden. Die Übertragung der Daten von Clouddrittanbietern kann bis zu 30 Minuten dauern, wobei am häufigsten 5 bis 15 Minuten Verspätungen auftreten. Eine längere Verzögerung – die länger als das Zeitfenster für die erneute Prüfung ist – kann dazu führen, dass Bedingungen in den Status „Unbekannt“ wechseln. Wenn die Daten schließlich eintreffen, hat Monitoring möglicherweise einen Teil des aktuellen Verlaufs der Bedingungen verloren. 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 einen Messwertschwellenwert auswertet, wenn keine Daten eingehen. Wenn beispielsweise ein Vorfall offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring den Vorfall dann geöffnet oder sofort schließen? Soll ein Vorfall geöffnet werden, wenn keine Daten eingehen und kein Vorfall offen ist? Und schließlich: Wie lange sollte ein Vorfall nach dem Eintreffen von Daten geöffnet bleiben?

Es gibt zwei konfigurierbare Felder, die festlegen, wie Monitoring Bedingungen für Messwertschwellen auswertet, wenn keine Daten eingehen:

  • Mit dem Feld Auswertung fehlender Daten, das Sie im Schritt Bedingungstrigger festlegen, können Sie konfigurieren, wie Monitoring den Ersatzwert für fehlende Daten bestimmt. Dieses Feld ist deaktiviert, wenn das Fenster für den erneuten Test auf Keine nochmalige Prüfung eingestellt ist.

    Das Fenster für den erneuten Test ist das Feld mit dem Namen „Dauer“ in der Cloud Monitoring API.

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

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

Google Cloud Console
Feld „Auswertung fehlender Daten“		 Zusammenfassung 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 erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn ein Vorfall offen ist und keine Daten eintreffen, startet der Timer für das automatische Schließen nach einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Nicht erfüllte Bedingungen sind weiterhin nicht erfüllt, wenn keine Daten mehr 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 erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn ein Vorfall offen ist und für die Dauer des automatischen Schließens plus 24 Stunden keine Daten eintreffen, wird er geschlossen.

Bei nicht erfüllten Bedingungen verhält sich diese Einstellung wie eine metric-absence condition-Bedingung. Wenn Daten nicht innerhalb der im Fenster für den erneuten Test festgelegten Zeit eintreffen, wird die Bedingung als erfüllt bewertet. 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 die Bedingung nicht mehr erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, wird er geschlossen.

Nicht erfüllte Bedingungen sind weiterhin nicht erfüllt, wenn keine Daten mehr eingehen.

API

Sie können konfigurieren, wie Monitoring eine Bedingung für einen Messwertschwellenwert auswertet, wenn keine Daten eingehen. Wenn beispielsweise ein Vorfall offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring den Vorfall dann geöffnet oder sofort schließen? Soll ein Vorfall geöffnet werden, wenn keine Daten eingehen und kein Vorfall offen ist? Und schließlich: Wie lange sollte ein Vorfall nach dem Eintreffen von Daten geöffnet bleiben?

Es gibt zwei konfigurierbare Felder, die festlegen, wie Monitoring Bedingungen für Messwertschwellen auswertet, wenn keine Daten eingehen:

  • Mit dem Feld evaluationMissingData der Struktur MetricThreshold können Sie konfigurieren, wie Monitoring den Ersatzwert für fehlende Daten bestimmt. Dieses Feld wird ignoriert, wenn das Feld duration null ist.

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

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

API
evaluationMissingData-Feld		 Zusammenfassung 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 erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn ein Vorfall offen ist und keine Daten eintreffen, startet der Timer für das automatische Schließen nach einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Nicht erfüllte Bedingungen sind weiterhin nicht erfüllt, 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 erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn ein Vorfall offen ist und für die Dauer des automatischen Schließens plus 24 Stunden keine Daten eintreffen, wird er geschlossen.

Bei nicht erfüllten Bedingungen verhält sich diese Einstellung wie eine metric-absence condition-Bedingung. Wenn Daten nicht innerhalb der im Feld „Dauer“ angegebenen Zeit ankommen, 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.

Wenn Bedingungen erfüllt sind, ist die Bedingung nicht mehr erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, wird er geschlossen.

Nicht erfüllte Bedingungen sind weiterhin nicht erfüllt, wenn keine Daten mehr eingehen.

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

  • Wenden Sie sich an Ihren Clouddrittanbieter, um Möglichkeiten zu finden, die Latenz bei der Messwerterfassung zu reduzieren.
  • Verwenden Sie in den Bedingungen längere Zeitfenster für erneute Tests. Ein längeres Fenster für den erneuten Test 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 wird

Weitere Informationen finden Sie in der Übersicht zum Monitoring-Agent, in der Übersicht zu benutzerdefinierten Messwerten und unter logbasierten Messwerten.

Wann sendet Monitoring Benachrichtigungen und erstellt Vorfälle?

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

Wenn Sie wiederholte Benachrichtigungen konfigurieren, wird die gleiche Benachrichtigung an die für die Benachrichtigungsrichtlinie festgelegten Benachrichtigungskanäle gesendet.

Sie erhalten möglicherweise mehrere einzelne Benachrichtigungen im Zusammenhang mit einer Benachrichtigungsrichtlinie, wenn eine der folgenden Bedingungen 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 Mehrfachbedingungs-Triggers der Benachrichtigungsrichtlinie ab:

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

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

    • Beliebige Bedingung wird erfüllt: Die Benachrichtigungsrichtlinie sendet eine Benachrichtigung, wenn die Bedingung aufgrund einer Zeitachse erfüllt ist.

    Weitere Informationen finden Sie unter Richtlinien mit mehreren Bedingungen.

In Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt werden, werden Sie auch darüber informiert, wenn die Bedingung erfüllt bzw. nicht mehr erfüllt wird. Benachrichtigungsrichtlinien, die über die Google Cloud Console erstellt wurden, senden nur dann eine Benachrichtigung, 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 Situationen erstellt Monitoring keine Vorfälle und sendet keine Benachrichtigungen, 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 offener Vorfälle erreicht.

Deaktivierte Benachrichtigungsrichtlinien

Monitoring sendet keine Erstellungsvorfälle oder Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Monitoring prüft jedoch weiterhin die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie.

Wenn Sie eine deaktivierte Richtlinie aktivieren, wertet Monitoring die Werte aller Bedingungen im letzten Testfenster aus. Das letzte Fenster der erneuten Prüfung kann Daten enthalten, die vor, während und nach der Aktivierung der Richtlinie aufgenommen wurden. Die Bedingungen einer deaktivierten Richtlinie können sofort nach dem Fortsetzen der Richtlinie erfüllt werden, selbst bei großen Testfenstern.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie, die einen bestimmten Prozess überwacht, und deaktivieren diese Richtlinie. In der folgenden Woche wird der Prozess unterbrochen. 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 erstellt einen Vorfall.

Die Vorfälle im Zusammenhang mit einer deaktivierten Benachrichtigungsrichtlinie bleiben offen, bis der Zeitraum für das automatische Schließen der Richtlinie abgelaufen ist.

Zurückgestellte Benachrichtigungsrichtlinien

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

Wenn Sie eine Benachrichtigungsrichtlinie zurückstellen, schließt Monitoring alle offenen Vorfälle im Zusammenhang mit der Richtlinie. Nach Ablauf der Schlummerfunktion können in Monitoring neue Vorfälle geöffnet werden. 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, das alle Ressourcen betrifft, kann dazu führen, dass die Benachrichtigungsrichtlinie Vorfälle für jede Ressource öffnet. Für jede Zeitachse, bei der eine Bedingung erfüllt ist, wird ein Vorfall geöffnet.

Um eine Überlastung des Systems zu vermeiden, 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, bei denen jede Instanz die Benachrichtigungsbedingungen erfüllt. Monitoring begrenzt die Anzahl der offenen Vorfälle auf 1.000. Alle verbleibenden erfüllten Bedingungen werden ignoriert, bis einige der offenen Vorfälle für diese Richtlinie geschlossen werden.

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

Latenz

Latenz bezieht sich auf die Verzögerung zwischen dem Zeitpunkt, zu dem Monitoring einen Messwert erfasst, und dem Zeitpunkt, zu dem der Messwertdatenpunkt als Zeitachsendaten 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, erstellt Monitoring bis zu 180 Sekunden lang keinen Vorfall, nachdem die Bedingung der Benachrichtigungsrichtlinie als wahr ausgewertet wurde. 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 zu erfassen. 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 Berechnung von Benachrichtigungsrichtlinien nimmt eine zusätzliche Verzögerung von 60 bis 90 Sekunden in Anspruch. Bei AWS CloudWatch-Messwerten kann die Sichtbarkeitsverzögerung mehrere Minuten betragen. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten (ab dem Ende des Zeitfensters für die erneute Prüfung) betragen.

  • Testfenster: Das für die Bedingung konfigurierte Fenster. Bedingungen sind nur dann erfüllt, wenn eine Bedingung während des gesamten Fensters für den erneuten Test erfüllt ist. Beispielsweise führt eine Einstellung von fünf Minuten für das Fenster für die erneute Prüfung zu einer Verzögerung in der Benachrichtigung von mindestens fünf Minuten nach dem ersten Ereignis.

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

Nächste Schritte