Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie mit den Einstellungen für Ausrichtungszeitraum und Dauer bestimmt wird, wann eine Bedingung erfüllt ist, wie in Benachrichtigungsrichtlinien mehrere Bedingungen kombiniert werden und wie fehlende Datenpunkte durch Benachrichtigungsrichtlinien 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.

Einstellungen für Ausrichtungszeitraum und Dauer

Der Ausrichtungszeitraum und das Dauerfenster sind zwei Felder, die Sie beim Angeben einer Bedingung für eine Benachrichtigungsrichtlinie festlegen. Dieser Abschnitt enthält eine kurze Darstellung der Bedeutung dieser Felder.

Ausrichtungszeitraum

Hinweis: Cloud Monitoring verwendet für Bedingungen für fehlende Messwerte immer einen Ausrichtungszeitraum von 24 Stunden.

Der Ausrichtungszeitraum wirft einen Rückblick ab einem bestimmten Zeitpunkt. Der Aligner ist die Funktion, die die Punkte im Lookback-Intervall zu einem ausgerichteten Wert kombiniert. Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten um 13:00 Uhr beträgt, enthält er die zwischen 12:55 und 13:00 Uhr empfangenen Stichproben. Um 13:01 Uhr geht der Ausrichtungszeitraum eine Minute weiter und enthält die zwischen 12:56 Uhr und 13:01 Uhr eingegangenen Stichproben.

Google Cloud Console

Sie konfigurieren die Ausrichtungsfelder mit den Menüs Rollierendes Fenster und Funktion für rollierendes Fenster, die Teil des Dialogfelds Neue Bedingung sind.

Weitere Informationen zu verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Einige der Aligner-Funktionen richten die Daten aus und konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine ausführliche Erläuterung finden Sie unter Arten, Typen und Konvertierungen.

API

Zum Konfigurieren der Ausrichtungsfelder 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. Einige der Aligner-Funktionen richten die Daten aus und konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine ausführliche Erläuterung finden Sie unter Arten, Typen und Konvertierungen.

Die Auswirkungen des Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie werden veranschaulicht, wenn Sie eine Bedingung für Messwertschwellen verwenden, um einen Messwert mit einem Stichprobenzeitraum von einer Minute zu überwachen. Angenommen, der Ausrichtungszeitraum ist auf fünf Minuten und der Aligner auf sum gesetzt. Nehmen wir außerdem an, 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. 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. In jeder Zeile wird der ausgerichtete Wert angezeigt und es wird angegeben, ob dieser Wert größer als der Grenzwert von zwei ist. In der Zeile start wird der ausgerichtete Wert auf eins berechnet, was unter dem Grenzwert liegt. Bei der nächsten Auswertung beträgt die Summe der Stichproben im Ausrichtungszeitraum zwei. In der dritten Auswertung beträgt die Summe drei. Da dieser Wert größer als der Grenzwert ist, wird ein Timer für die Dauer gestartet.

Dauerfenster

Mit Dauer oder Dauerfenster wird verhindert, dass eine Bedingung aufgrund einer einzelnen Messung oder Prognose erfüllt wird. Angenommen, das Dauerfeld für eine Bedingung ist auf 15 Minuten festgelegt. Im Folgenden wird das Verhalten der Bedingung basierend auf ihrem Typ beschrieben:

• Bedingungen für Messwertschwellen sind erfüllt, wenn bei einer einzelnen Zeitachse jede ausgerichtete Messung in einem 15-Minuten-Intervall den Grenzwert verletzt.
• Bedingungen für fehlende Messwerte sind erfüllt, wenn in einem 15-Minuten-Intervall für eine Zeitachse keine Daten eingehen.
• Prognosebedingungen sind erfüllt, wenn jede Prognose innerhalb eines 15-Minuten-Zeitfensters prognostiziert wird, dass die Zeitachse innerhalb des Prognosefensters den Grenzwert überschreitet.

Bei Richtlinien mit einer Bedingung wird ein Vorfall geöffnet 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 Dauerfenster im Schritt Trigger konfigurieren über das Feld Fenster noch einmal testen.

API

Zum Konfigurieren des Dauerfensters legen Sie das Feld duration in den Strukturen MetricThreshold und MetricAbsence fest.

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

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

Eine Bedingung setzt ihr Dauerfenster 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 Messwertschwellenbedingung, die ein Dauerfenster von fünf Minuten angibt.

Wenn die HTTP-Antwortlatenz länger als zwei Sekunden ist
und die Latenz fünf Minuten lang über dem Grenzwert liegt,
erstellen Sie einen Vorfall und senden eine E-Mail an Ihr Supportteam.

Die folgende Abfolge zeigt, wie sich das Dauerfenster auf die Bewertung der Bedingung auswirkt:

1. Die HTTP-Latenz beträgt weniger als zwei Sekunden.
2. In den nächsten drei Minuten beträgt die HTTP-Latenz mehr als zwei Sekunden.
3. Bei der nächsten Messung beträgt die Latenz weniger als zwei Sekunden, sodass die Bedingung das Dauerfenster zurückgesetzt wird.

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

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

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

• Der Höchstwert des Ausrichtungszeitraums beträgt 24 Stunden abzüglich der 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 Dauerfenster fest, wie schnell die Benachrichtigung reagieren soll. Wenn Sie beispielsweise das Dauerfenster 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 wird. Für eine reaktionsschnellere Benachrichtigungsrichtlinie legen Sie die Dauer auf einen kleineren Wert fest. Legen Sie für Bedingungen für Messwertschwellen, um die reaktionsschnellste Benachrichtigungsrichtlinie zu erhalten, die Dauer auf null fest. 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 Dauerfenster treffen, 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. Führen Sie einen der folgenden Schritte aus, um zu konfigurieren, wie mehrere Bedingungen kombiniert werden:

Google Cloud Console

Die Optionen für die Kombinationsmöglichkeiten werden im Schritt Trigger mit mehreren Bedingungen konfiguriert.

API

Die Kombinationsoptionen werden mit dem Feld combiner der AlertPolicy-Struktur konfiguriert.

In dieser Tabelle sind 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 der Richtlinienauslöser	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 dafür sorgt.
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 true ausgewertet wird. Wenn die Konfiguration beispielsweise Any time series is greater than 10 for 5 minutes lautet, ist die Bedingung erfüllt, wenn diese Anweisung true ergibt.

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 beliebigen 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 beliebigen Instanz 1 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-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 weiterhin über 100 ms/s liegt und dass 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 dazu führt, dass die Bedingung CPU usage is too high erfüllt wird, führt dies ebenfalls zur Erstellung eines Vorfalls. Ein Vorfall wird erstellt, da vm1 und vm2, die zur Erfüllung der Bedingung CPU usage is too high führen, 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 ankommen oder Daten verzögert sind, klassifiziert Monitoring die Daten als fehlend. Fehlende Daten können das Schließen von Vorfällen verhindern. Die Verzögerung für Daten, die von Cloud-Drittanbietern eingeht, können bis zu 30 Minuten betragen, wobei 5 bis 15 Minuten am häufigsten sind. Wenn eine Verzögerung länger als das Dauerfenster ist, können Bedingungen den Status "Unbekannt" erhalten. Wenn die Daten schließlich eintreffen, hat Monitoring möglicherweise einen Teil des jüngsten 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 Messwertgrenzwerte auswertet, wenn keine Daten mehr eingehen. Soll beispielsweise ein Vorfall, der offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring den Vorfall geöffnet lassen oder sofort schließen? Möchten Sie, dass ein Vorfall geöffnet wird, wenn keine Daten mehr ankommen und kein Vorfall offen ist? Und schließlich: Wie lange sollte ein Vorfall offen bleiben, nachdem keine Daten mehr eintreffen?

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

• Verwenden Sie das Feld Auswertung fehlender Daten, das Sie im Schritt Bedingungstrigger festgelegt haben, um zu konfigurieren, wie Monitoring den Ersatzwert für fehlende Daten ermittelt. Dieses Feld ist deaktiviert, wenn das Fenster für den erneuten Test auf Kein erneuter Test festgelegt ist.

• Mit dem Feld Dauer der automatischen Schließung von Vorfällen können Sie konfigurieren, wie lange Monitoring wartet, bevor ein offener Vorfall geschlossen wird, nachdem keine Daten mehr eingehen. Die Dauer des automatischen Schließens legen Sie 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	Offene Vorfälle bleiben offen. Neue Vorfälle werden nicht geöffnet.	Sind Bedingungen erfüllt, ist sie auch dann weiterhin erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn bei einem Vorfall keine Daten eingehen, 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. Sind Bedingungen nicht erfüllt, ist sie auch nach dem Eintreffen von Daten weiterhin nicht erfüllt.
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.	Sind Bedingungen erfüllt, ist sie auch dann 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 während der automatischen Schließdauer plus 24 Stunden keine Daten eintreffen, wird der Vorfall geschlossen. Bei Bedingungen, die nicht erfüllt sind, verhält sich diese Einstellung wie ein metric-absence condition. Wenn Daten nicht innerhalb der im Fenster für den erneuten Test angegebenen Zeit eingehen, 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.	Sind Bedingungen erfüllt, ist sie nicht mehr erfüllt, sobald keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, wird er geschlossen. Sind Bedingungen nicht erfüllt, ist sie auch nach dem Eintreffen von Daten weiterhin nicht erfüllt.

API

Sie können konfigurieren, wie Monitoring eine Bedingung für Messwertgrenzwerte auswertet, wenn keine Daten mehr eingehen. Soll beispielsweise ein Vorfall, der offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring den Vorfall geöffnet lassen oder sofort schließen? Möchten Sie, dass ein Vorfall geöffnet wird, wenn keine Daten mehr ankommen und kein Vorfall offen ist? Und schließlich: Wie lange sollte ein Vorfall offen bleiben, nachdem keine Daten mehr eintreffen?

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

• Mit dem Feld evaluationMissingData der Struktur MetricThreshold können Sie konfigurieren, wie Monitoring den Ersatzwert für fehlende Daten ermittelt. 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 mehr 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.	Sind Bedingungen erfüllt, ist sie auch dann weiterhin erfüllt, wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt er offen. Wenn bei einem Vorfall keine Daten eingehen, 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. Sind Bedingungen nicht erfüllt, ist sie auch nach dem Eintreffen von Daten weiterhin nicht erfüllt.
EVALUATION_MISSING_DATA_ACTIVE	Offene Vorfälle bleiben offen. Neue Vorfälle können geöffnet werden.	Sind Bedingungen erfüllt, ist sie auch dann 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 während des automatischen Schließens plus 24 Stunden keine Daten eintreffen, wird der Vorfall geschlossen. Bei Bedingungen, die nicht erfüllt sind, verhält sich diese Einstellung wie ein metric-absence condition. Wenn Daten nicht innerhalb der im Feld „duration“ angegebenen Zeit ankommen, wird die Bedingung als erfüllt bewertet. 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.	Sind Bedingungen erfüllt, ist sie nicht mehr erfüllt, sobald keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, wird er geschlossen. Sind Bedingungen nicht erfüllt, ist sie auch nach dem Eintreffen von Daten weiterhin nicht erfüllt.

So können Sie Probleme aufgrund fehlender Daten minimieren:

• Wenden Sie sich an den Cloud-Drittanbieter, um die Latenz bei der Messwerterfassung zu verringern.
• Verwenden Sie in Ihren Bedingungen längere Dauerfenster. Die Verwendung eines längeren Dauerfensters hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger 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 unter Übersicht über den Monitoring-Agent, Benutzerdefinierte Messwerte – Übersicht und Logbasierte Messwerte.

Benachrichtigungen und Vorfälle gemäß Richtlinie

Wenn Sie verhindern möchten, dass Monitoring Vorfälle erstellt und Benachrichtigungen für eine Benachrichtigungsrichtlinie sendet, erstellen Sie eine Schlummerfunktion und nehmen die Benachrichtigungsrichtlinie in die Kriterien für die Schlummerfunktion auf. Wenn die Schlummerfunktion aktiv ist, erstellt die Benachrichtigungsrichtlinie keine Vorfälle und sendet keine Benachrichtigungen.

Wenn Richtlinien aktiviert sind und nicht den Kriterien einer aktiven Schlummerfunktion entsprechen, können Vorfälle erstellt und Benachrichtigungen gesendet werden. In diesem Abschnitt werden die Limits für die Anzahl offener Vorfälle pro Richtlinie beschrieben und beschrieben, wann mehrere Benachrichtigungen für denselben Vorfall angezeigt werden können.

Anzahl der offenen Vorfälle pro Richtlinie

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 Zeitreihe, die zum Erfüllen einer Bedingung führt, 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, wobei jede Instanz dazu führt, dass die Benachrichtigungsbedingungen erfüllt sind. Monitoring begrenzt die Anzahl der offenen Vorfälle auf 1.000. Alle verbleibenden Bedingungen, die erfüllt sind, werden ignoriert, bis einige der offenen Vorfälle für diese Richtlinie geschlossen sind.

Hinweis: Wenn Sie einen Vorfall für eine Benachrichtigungsrichtlinie geöffnet haben und die Zeitachse, die den Vorfall verursacht hat, den Bedingungsschwellenwert noch einmal überschreitet, während der Vorfall noch offen ist, wird kein anderer Vorfall geöffnet. Monitoring unterhält für jede Zeitachse in einer Benachrichtigungsrichtlinie nur einen offenen Vorfall.

Anzahl der Benachrichtigungen pro Richtlinie

Standardmäßig wird eine Benachrichtigung gesendet, wenn eine Zeitachse dazu führt, dass eine Bedingung erfüllt ist. In folgenden Fällen erhalten Sie möglicherweise mehrere Benachrichtigungen:

• Eine Bedingung überwacht mehrere Zeitreihen.

• Eine Richtlinie enthält mehrere Bedingungen:

  • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, sendet Monitoring für jede Zeitachse, die dazu führt, dass eine Bedingung erfüllt wird, eine Benachrichtigung und erstellt einen Vorfall. Angenommen, Sie haben eine Richtlinie mit zwei Bedingungen und jede Bedingung überwacht eine Zeitachse. Wenn alle Bedingungen erfüllt sind, erhalten Sie zwei Benachrichtigungen und sehen zwei Vorfälle.

  • Jede Bedingung ist erfüllt: Die Benachrichtigungsrichtlinie sendet jedes Mal eine Benachrichtigung, wenn eine Bedingung erfüllt ist. Angenommen, Sie haben eine Richtlinie mit zwei Bedingungen und jede Bedingung überwacht eine Zeitachse. Angenommen, die erste Bedingung ist erfüllt. Dadurch wird ein Vorfall geöffnet und eine Benachrichtigung gesendet. Wenn der Vorfall noch offen ist, wenn eine nachfolgende Messung dazu führt, dass die zweite Bedingung erfüllt ist, wird eine weitere Benachrichtigung gesendet.

Hinweis: Wenn eine Benachrichtigungsrichtlinie mehrere Bedingungen hat, kann sie nicht so konfiguriert werden, dass eine einzelne Benachrichtigung gesendet und ein einzelner Vorfall erstellt wird.

Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt werden, benachrichtigen Sie, wenn die Bedingung erfüllt oder nicht mehr erfüllt ist. Standardmäßig werden Sie durch Benachrichtigungsrichtlinien, die mit der Google Cloud Console erstellt werden, benachrichtigt, wenn ein Vorfall geöffnet wird. Sie erhalten keine Benachrichtigung, wenn ein Vorfall geschlossen wird. Sie können Benachrichtigungen zum Schließen von Vorfällen aktivieren.

Hinweis: Sie können die Zustellung von Benachrichtigungen über die Schließung von Vorfällen nicht über die Monitoring API ändern.

Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien

Wenn Sie eine Benachrichtigungsrichtlinie deaktivieren, wertet die Benachrichtigungsrichtlinie weiterhin ihre Bedingungen aus. Es werden jedoch keine Vorfälle erstellt und keine Benachrichtigungen gesendet.

Wenn Sie eine deaktivierte Richtlinie aktivieren, prüft Monitoring die Werte aller Bedingungen im letzten Dauerfenster. Die jüngste Dauer kann Daten umfassen, die vor, während oder nach der Aktivierung der Richtlinie aufgenommen wurden. Die Bedingungen einer deaktivierten Richtlinie können sofort nach Wiederaufnahme der Richtlinie erfüllt werden, auch bei großen Dauerfenstern.

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

Wenn Sie eine Benachrichtigungsrichtlinie deaktivieren, bleiben offene Vorfälle so lange offen, bis der Zeitraum für das automatische Schließen abgelaufen ist. Wenn Sie eine Benachrichtigungsrichtlinie pausieren, werden alle offenen Vorfälle im Zusammenhang mit dieser Richtlinie geschlossen. Wenn die Schlummerfunktion jedoch endet, können neue Vorfälle geöffnet werden. Weitere Informationen finden Sie unter Benachrichtigungen deaktivieren.

Benachrichtigungen für Richtlinien, die die Kriterien einer aktiven Schlummerfunktion erfüllen

Wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie in kurzen Abständen Benachrichtigungen sendet, empfehlen wir Ihnen, eine Schlummerfunktion zu erstellen, anstatt die Benachrichtigungsrichtlinie zu deaktivieren. Bevor Sie beispielsweise eine Wartung auf einer virtuellen Maschine (VM) ausführen, können Sie eine Schlummerfunktion erstellen und den Schlummerkriterien die Benachrichtigungsrichtlinien hinzufügen, die die Instanz überwachen.

Wenn eine Bedingung einer Benachrichtigungsrichtlinie erfüllt ist und diese Richtlinie die Kriterien einer aktiven Schlummerfunktion erfüllt, wird kein Vorfall erstellt und keine Benachrichtigung gesendet. Wenn die Schlummerfunktion abläuft, kann die Benachrichtigungsrichtlinie Vorfälle erstellen und Benachrichtigungen senden.

Wiederholte Benachrichtigungen senden

Richten Sie wiederholte Benachrichtigungen ein, um Benachrichtigungsempfänger an ihre offenen und bestätigten Vorfälle zu erinnern. Diese Funktion ist nützlich für Benachrichtigungsrichtlinien, die kritische Ressourcen überwachen und deren Erschöpfung zum Ausfall eines Dienstes führen kann. Sie können beispielsweise wiederholte Benachrichtigungen für eine Benachrichtigungsrichtlinie einrichten, die den freien Speicherplatz überwacht.

Standardmäßig sendet eine Benachrichtigungsrichtlinie eine Benachrichtigung an jeden Benachrichtigungskanal, wenn ein Vorfall geöffnet wird. Sie können jedoch das Standardverhalten ändern und eine Benachrichtigungsrichtlinie so konfigurieren, dass Benachrichtigungen noch einmal an alle oder einige Benachrichtigungskanäle für Benachrichtigungsrichtlinien gesendet werden. Diese wiederholten Benachrichtigungen werden bei Vorfällen mit dem Status „Offen“ oder „Bestätigt“ gesendet. Das Intervall dieser Benachrichtigungen muss mindestens 30 Minuten und darf nicht mehr als 24 Stunden in Sekunden betragen.

Hinweis :Für logbasierte Benachrichtigungen können Sie keine wiederholten Benachrichtigungen einrichten.

Google Cloud Console

Sie können in der Google Cloud Console keine wiederholten Benachrichtigungen konfigurieren. Verwenden Sie stattdessen die Google Cloud CLI oder API.

API

Fügen Sie Ihrem AlertStrategy-Objekt mindestens ein NotificationChannelStrategy-Objekt hinzu. Ein NotificationChannelStrategy-Objekt hat zwei Felder:

• renotifyInterval: Die Zeitspanne in Sekunden zwischen wiederholten Benachrichtigungen.

  Sie können den Wert des Felds renotifyInterval jederzeit ändern. Wenn beim Ändern des Intervalls ein Vorfall im Zusammenhang mit der Benachrichtigungsrichtlinie offen ist, sendet die Benachrichtigungsrichtlinie eine weitere Benachrichtigung für den Vorfall und startet dann den Intervallzeitraum neu.

• notificationChannelNames: Ein Array von Ressourcennamen für Benachrichtigungskanäle, bei denen es sich um Strings im Format projects/PROJECT_ID/notificationChannels/CHANNEL_ID handelt. Diese Benachrichtigungskanäle erhalten die wiederholten Benachrichtigungen in den durch den Wert renotifyInterval definierten Intervallen.

  Die Kanal-ID des Ressourcennamens ist ein numerischer Wert. Informationen zum Abrufen der Kanal-ID finden Sie unter Benachrichtigungskanäle in einem Projekt auflisten.

Das folgende JSON-Beispiel zeigt beispielsweise eine Benachrichtigungsstrategie, die so konfiguriert ist, dass alle 1.800 Sekunden (30 Minuten) wiederholte Benachrichtigungen an den aufgeführten Benachrichtigungskanal gesendet werden:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Weitere Informationen zum Erstellen von Benachrichtigungsrichtlinien mit der API finden Sie unter Benachrichtigungsrichtlinien über die API erstellen.

Wenn Sie wiederholte Benachrichtigungen für einen bestimmten Zeitraum stoppen möchten, deaktivieren oder erstellen Sie eine Schlummerfunktion für die Benachrichtigungsrichtlinie. Wenn Sie wiederholte Benachrichtigungen vollständig deaktivieren möchten, bearbeiten Sie die Benachrichtigungsrichtlinie mithilfe der API und entfernen Sie das Objekt NotificationChannelStrategy.

Latenz

Die Latenz bezieht sich auf die Verzögerung zwischen der Erfassung eines Messwerts durch Monitoring und dem Zeitpunkt, zu dem der Messwertdatenpunkt als Zeitreihendaten sichtbar wird. Die Latenz beeinflusst, 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 „true“ 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 60 Sekunden nach der Erfassung nicht sichtbar. Die Verzögerung hängt jedoch vom Messwert ab. Die Berechnung der Benachrichtigungsrichtlinie dauert eine zusätzliche Verzögerung von 60 bis 90 Sekunden. Bei AWS CloudWatch-Messwerten kann die Verzögerung bei der Sichtbarkeit mehrere Minuten betragen. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten (ab dem Ende des Dauerfensters) betragen.

• Dauerfenster: das für die Bedingung konfigurierte Zeitfenster. Bedingungen sind nur dann erfüllt, wenn eine Bedingung im gesamten Dauerfenster erfüllt ist. Beispielsweise führt eine Einstellung des Dauerfensters von fünf Minuten zu Verzögerungen in der Benachrichtigung von mindestens fünf Minuten nach dem ersten Ereignis.

• Zeit bis zum Eintreffen der Benachrichtigung: In Benachrichtigungskanälen wie E-Mail und SMS können unabhängig vom übermittelten Inhalt Netzwerk- oder andere Latenzen auftreten. Diese können manchmal in der Größenordnung von mehreren Minuten auftreten. 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 Dokumenten:

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

• Eine Auswahl an Benachrichtigungsrichtlinien finden Sie unter Beispielrichtlinien.