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, 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 die Wiederholung von 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:

• 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 Abstimmung 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 Ausrichtungszeitraum, indem Sie 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 für auf das Fenster der Datenpunkte.

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

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 fünf Minuten festgelegt und ist der Aligner auf sum gesetzt. 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 die erneute Prüfung der im nächsten Abschnitt beschrieben wird, beträgt drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

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 Bezeichnung start wird als ausgerichteter Wert eins berechnet, was unter dem Grenzwert liegt. 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 über dem Schwellenwert liegt, wird ein Timer für das Zeitfenster für den Wiederholungstest 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 gesetzt. 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, bei der jede ausgerichtete Messung in einem 15-Minuten-Intervall gegen um den Grenzwert zu erreichen.
• Bedingungen für fehlende Messwerte sind erfüllt, wenn für keine Daten eintreffen. eine Zeitachse im 15-Minuten-Intervall.
• 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 geöffnet und Benachrichtigungen wird 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 veranschaulicht die Ergebnisse für die nächsten Auswertungen der Bedingung:

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 start + 5 minutes

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 Messwertschwellenwert, gibt ein fünfminütiges Fenster für den erneuten Test an.

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 Reihenfolge zeigt, wie sich das Fenster für den erneuten Test auf den Bewertung der Bedingung:

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 beträgt die Latenz weniger als zwei Sekunden. wird das Fenster für die erneute Prüfung zurückgesetzt.

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 zum Festlegen des Ausrichtungszeitraums und des Zeitfensters für erneute Tests

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 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. 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. Für eine reaktionsschnellere Benachrichtigungsrichtlinie bietet, stellen Sie einen kleineren Wert für das Fenster für den erneuten Test ein. 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.

Bedingungen für Benachrichtigungsrichtlinien werden mit einer festen Häufigkeit ausgewertet. Die Auswahl des Ausrichtungszeitraums und des Zeitfensters für den Wiederholungstest 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 mehrere Bedingungen enthält, müssen Sie festlegen, wenn ein Vorfall geöffnet wird. Zum Konfigurieren mehrere Bedingungen kombinieren, führen Sie einen der folgenden Schritte aus:

Google Cloud Console

Sie konfigurieren Kombinatoroptionen 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.
Hinweis: In der Benachrichtigungsrichtlinie werden die Labelwerte verwendet, um die Ressource zu identifizieren, die eine Bedingung erfüllt hat. Für eine Benachrichtigungsrichtlinie mit diesem Combiner müssen Sie Folgendes tun, um Vorfälle zu erstellen oder Benachrichtigungen zu generieren: Jede Bedingung muss dieselbe Ressource beobachten. Zum Beispiel ist für alle Bedingungen der Ressourcentyp auf gce_instance festgelegt. Die Labels für überwachte Ressourcen, die nach der Aggregation verfügbar sind, müssen für alle Bedingungen identisch sein. Für die Ressource gce_instance sind die Labels beispielsweise project_id, instance_id und zone. Ist eine Bedingung nach zone gruppiert, müssen alle Bedingungen nach zone gruppiert werden. Eine Liste der überwachten Ressourcen und ihrer Labels finden Sie unter Überwachte Ressourcentypen.

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-Auslastung einer Instanz gleich ü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. 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 als Nächstes an, dass die CPU-Auslastung von vm1 größer als 100 ms/s bleibt 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, dann das auch zu einem Vorfall führt. 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. 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:

• 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 erneuten Test ist das Feld mit dem Namen „Dauer“ in der Cloud Monitoring API.

• So konfigurieren Sie, wie lange Monitoring wartet, bevor es geschlossen wird nach dem Eintreffen der Daten noch offene, 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 „Auswertung fehlender Daten“ Feld	Fazit	Details
Fehlende Daten (leer)	Offene Vorfälle bleiben offen. Neue Vorfälle werden nicht geöffnet.	Wenn eine Bedingung erfüllt ist, gilt das auch dann, 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 wird 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 werden als Werte behandelt, 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 für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er 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 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.	Wenn Bedingungen erfüllt sind, ist sie nicht mehr erfüllt, wenn Daten nicht mehr ankommen. 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. 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, 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 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, gilt das auch dann, wenn keine Daten mehr eingehen. Wenn für diese Bedingung bereits ein Vorfall geöffnet ist, bleibt er 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.
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 des Zeitraums für die automatische Schließung und der folgenden 24 Stunden keine Daten eingehen, wird der Vorfall geschlossen. 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 des im Feld „duration“ angegebenen Zeitraums eintreffen, wird die Bedingung als erfüllt ausgewertet. Für eine Benachrichtigungsrichtlinie mit eine Bedingung erfüllt, 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 aufgrund dieser Bedingung geöffnet ist, wird er geschlossen. Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

So können Sie Probleme aufgrund fehlender Daten minimieren:

• Wenden Sie sich an Ihren Cloud-Drittanbieter, um Möglichkeiten zur Verringerung der Latenz bei der Messwerterfassung zu finden.
• Verwenden Sie in den Bedingungen längere Zeiträume für erneute Tests. Längeres Zeitfenster für erneute Tests verwenden hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger responsiv.

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

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

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. 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 Fällen werden von 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.
• 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 bricht der Prozess ab. 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.

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

Zurückgestellte 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. 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, 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 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.

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

Hinweis: Wenn Sie einen Vorfall für eine Benachrichtigungsrichtlinie geöffnet haben und die Zeitreihe, die den Vorfall ausgelöst hat, den Grenzwert der Bedingung noch einmal überschreitet, während der Vorfall noch offen ist, wird kein weiterer Vorfall geöffnet. In Cloud Monitoring wird für jede Zeitreihe in einer Benachrichtigungsrichtlinie nur ein offener Vorfall verwaltet.

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. 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. Die Berechnungen der Benachrichtigungsrichtlinien dauern zusätzlich 60 bis 90 Sekunden. Bei AWS CloudWatch-Messwerten ist die Sichtbarkeitsverzögerung mehrere Minuten dauern. 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

• Informationen zum Erstellen einer Benachrichtigungsrichtlinie finden Sie in den folgenden Dokumente:

  • Benachrichtigungsrichtlinien für Messwertschwellen erstellen
  • Benachrichtigungsrichtlinien für fehlende Messwerte erstellen
  • Benachrichtigungsrichtlinien für prognostizierte Messwertwerte erstellen
  • Benachrichtigungsrichtlinien mit der Monitoring API erstellen

• Eine Auswahl an Benachrichtigungsrichtlinien finden Sie unter Beispielrichtlinien.