Funktionsweise messwertbasierter Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie die Einstellungen für den Ausrichtungszeitraum und die Dauer bestimmen, wann eine Bedingung ausgelöst wird, wie Benachrichtigungsrichtlinien mehrere Bedingungen kombinieren 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 Gründe für Benachrichtigungsverzögerungen beschrieben.

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

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

Der Ausrichtungszeitraum wirft einen Rückblick ab einem bestimmten Zeitpunkt. Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten um 13:00 Uhr beträgt, werden im Abgleichszeitraum die Stichproben zwischen 12:55 Uhr und 13:00 Uhr angezeigt. Um 13:01 Uhr geht der Ausrichtungszeitraum eine Minute weiter und enthält die zwischen 12:56 Uhr und 13:01 Uhr eingegangenen Stichproben.

Zur Veranschaulichung der Auswirkungen eines Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie: Stellen Sie sich eine Bedingung vor, die einen Messwert mit einem Stichprobenzeitraum von einer Minute überwacht. Angenommen, der Ausrichtungszeitraum ist auf 5 Minuten und der Aligner auf sum eingestellt. Wenn der ausgerichtete Wert der Zeitachse mindestens drei Minuten lang größer als zwei ist, wird die Bedingung als met oder active beschrieben. In diesem Beispiel wird davon ausgegangen, dass die Bedingung jede Minute ausgewertet wird.

Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

Abbildung zur Auswirkung des Ausrichtungszeitraums

Jede Zeile in der Abbildung stellt eine einzelne Bewertung der Bedingung dar. Die Zeitachsendaten werden angezeigt. Die Punkte im Ausrichtungszeitraum werden mit blauen Punkten, alle älteren Punkte schwarz dargestellt. Jede Zeile zeigt den ausgerichteten Wert an und ob der Wert größer als der Grenzwert von zwei ist. In der Zeile start wird der ausgerichtete Wert auf 1 berechnet, was unter dem Grenzwert liegt. Bei der nächsten Auswertung beträgt die Summe der Stichproben im Ausrichtungszeitraum zwei. Bei der dritten Auswertung liegt die Summe bei drei und ist größer als der Grenzwert. Der Bedingungsevaluator startet auch die Dauer des Zeitfensters.

Dauerfenster

Mit dem Dauerzeitraum oder Dauerfenster verhindern Sie, dass eine Bedingung aufgrund einer einzelnen Messung erfüllt wird. Verwenden Sie in der Google Cloud Console die folgenden Felder, um die Dauer zu konfigurieren:

Legacy-Oberfläche

Das Dauerfenster konfigurieren Sie mit dem Feld Für im Bereich Konfiguration der Benachrichtigungsrichtlinie.

Vorschau-Oberfläche

Das Dauerfenster konfigurieren Sie mit dem Feld Fenster erneut testen im Schritt Trigger konfigurieren.

API

Konfigurieren Sie das Dauerfenster, indem Sie in den Strukturen MetricThreshold und MetricAbsence das Feld duration festlegen.

Die vorherige Abbildung zeigt drei Auswertungen der Bedingung. Zum Zeitpunkt start + 2 minutes ist der ausgerichtete Wert größer als der Grenzwert. Unabhängig davon, ob die Bedingung erfüllt ist, da das Dauerfenster auf drei Minuten festgelegt ist. Die folgende Abbildung zeigt die Ergebnisse für die nächste Auswertung der Bedingung:

Abbildung zur Auswirkung des Dauerfensters

Obwohl der angepasste Wert größer als der Grenzwert zum Zeitpunkt start + 2 minutes ist, wird die Bedingung erst dann erfüllt, wenn der ausgerichtete Wert für drei Minuten größer als der Grenzwert ist. Dies geschieht zum Zeitpunkt start + 5 minutes.

Der Übersichtlichkeit halber wurde im vorherigen Beispiel die Möglichkeit ausgelassen, die ausgerichteten Datenpunkte aus mehreren Zeitachsen zu einer einzigen Messung zu kombinieren. Diese Messung wird mit dem Grenzwert verglichen, um festzustellen, ob die Bedingung erfüllt ist.

Das Dauerfenster einer Bedingung wird jedes Mal zurückgesetzt, wenn eine Messung die Bedingung nicht erfüllt. Dieses Verhalten wird im folgenden Beispiel veranschaulicht:

Beispiel: Diese Richtlinie gibt ein Zeitfenster von fünf Minuten an.

Wenn die Latenz der HTTP-Antwort größer als 2 Sekunden ist und
die Latenz fünf Minuten länger ist als der Grenzwert,
öffnen Sie einen Vorfall und senden Sie 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 aufeinanderfolgenden Minuten ist die HTTP-Latenz größer als 2 Sekunden.
  3. Bei der nächsten Messung beträgt die Latenz weniger als zwei Sekunden, sodass das Dauerfenster zurückgesetzt wird.
  4. Während der nächsten fünf aufeinanderfolgenden Minuten ist die HTTP-Latenz länger als zwei Sekunden, sodass die Bedingung erfüllt und die Richtlinie ausgelöst wird.

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.

Zeitraum für den Ausrichtungszeitraum und Dauer auswählen

Die Bedingungen der Benachrichtigungsrichtlinien werden mit einer festen Häufigkeit ausgewertet. Die Auswahl, die Sie für den Ausrichtungszeitraum und das Dauerfenster treffen, bestimmt nicht, wie oft die Bedingung ausgewertet wird.

Die Abbildung zeigt, dass der Ausrichtungszeitraum bestimmt, wie viele Stichproben mit dem Aligner kombiniert werden. Wähle einen langen Zeitraum aus, um viele Stichproben zu kombinieren. Wenn das Intervall auf nur eine Stichprobe begrenzt werden soll, wählen Sie einen kurzen Zeitraum aus. Im Gegensatz dazu gibt das Zeitfenster an, wie lange die angepassten Werte größer als der Grenzwert sein müssen, bevor die Bedingung erfüllt ist. Wenn die Bedingung erfüllt sein soll, wenn ein einzelner ausgerichteter Wert größer als der Grenzwert ist, legen Sie das Dauerfenster auf null fest.

Richtlinien mit mehreren Bedingungen

Eine Benachrichtigungsrichtlinie kann bis zu sechs Bedingungen enthalten.

Wenn Sie die Cloud Monitoring API verwenden oder Ihre Benachrichtigungsrichtlinie mehrere Bedingungen hat, 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:

Legacy-Oberfläche

Sie können Kombiniereroptionen im Feld Richtlinientrigger konfigurieren.

Vorschau-Oberfläche

Sie können Kombiniereroptionen im Schritt Trigger für mehrere Bedingungen konfigurieren.

API

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

Diese Tabelle enthält die Einstellungen in der Cloud Console, den entsprechenden Wert in der Cloud Monitoring API und eine Beschreibung der einzelnen Einstellungen:

Cloud Console
Wert der Trigger-Richtlinie
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 diese Bedingungen erfüllt.
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 Zusammenhang bedeutet der Begriff erfüllt, dass die Konfiguration der Bedingung als wahr ausgewertet wird. Lautet die Konfiguration beispielsweise Any time series is greater than 10 for 5 minutes, wird die Bedingung erfüllt, wenn die 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-Nutzung einer Instanz 1 Minute lang größer als 100 ms/s ist.
  • 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 größer als 60% ist.

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-Nutzung 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 weiter an, dass die CPU-Auslastung von VM1 größer als 100 ms/s bleibt 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 bewirkt, dass die Bedingung CPU usage is too high erfüllt ist, führt dies auch dazu, dass ein Vorfall erstellt wird. Ein Vorfall wird erstellt, weil „vm1“ und „vm2“, die dazu führen, dass die Bedingung CPU usage is too high erfüllt ist, 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 Zeitachsendaten nicht mehr ankommen oder wenn Daten verzögert sind, werden die Daten in Monitoring als fehlend klassifiziert. Fehlende Daten können dazu führen, dass Richtlinien keine Benachrichtigungen erhalten und Vorfälle nicht geschlossen werden. Verzögerungen von Daten, die von Cloud-Drittanbietern eingehen, können bis zu 30 Minuten betragen. Häufig sind Verzögerungen von fünf bis 15 Minuten am häufigsten. Wenn eine Verzögerung länger als das Dauerfenster ist, können Bedingungen den Status "Unbekannt" erhalten. Wenn die Daten schließlich eingehen, wurde in Monitoring möglicherweise ein neuer Verlauf der Bedingungen gespeichert. 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.

Legacy-Oberfläche

Sie können konfigurieren, wie lange Monitoring auf offene Vorfälle wartet, wenn Daten nicht mehr eingehen. Sie können jedoch konfigurieren, wie Monitoring Werte für fehlende Daten auswählt.

Verwenden Sie das Feld Dauer des automatischen Schließens von Vorfällen, um zu konfigurieren, wie lange Monitoring wartet, bevor ein offener Vorfall geschlossen wird, nachdem keine Daten mehr eintreffen. Die Dauer des automatischen Schließens legen Sie im Schritt Benachrichtigung fest. Die standardmäßige Dauer für das automatische Schließen beträgt sieben Tage.

Vorschau-Oberfläche

Sie können konfigurieren, wie Monitoring eine Bedingung für den Messwertschwellenwert auswertet, wenn keine Daten mehr eingehen. Wenn beispielsweise ein Vorfall offen ist und eine erwartete Messung nicht eingeht, soll der Vorfall dann von Monitoring geöffnet oder geschlossen werden? Möchtest du einen Vorfall öffnen, wenn keine Daten mehr eingehen und kein Vorfall geöffnet ist? Wie lange sollte ein Vorfall geöffnet bleiben, nachdem keine Daten mehr eintreffen?

Es gibt zwei konfigurierbare Felder, mit denen angegeben wird, wie Monitoring die Bedingungen für Messwertgrenzwerte auswertet, wenn Daten nicht mehr eingehen:

  • Verwenden Sie das Feld Bewertung – fehlende Daten, das Sie im Schritt Bedingung auslösen festlegen, um zu bestimmen, wie Monitoring den Ersatzwert für fehlende Daten ermittelt. Dieses Feld ist deaktiviert, wenn das Fenster für den erneuten Test auf Kein neuer Test eingestellt ist.

  • Verwenden Sie das Feld Dauer des automatischen Schließens von Vorfällen, um zu konfigurieren, wie lange Monitoring wartet, bevor ein offener Vorfall geschlossen wird, nachdem keine Daten mehr eintreffen. Die Dauer des automatischen Schließens legen Sie im Schritt Benachrichtigung fest. Die standardmäßige Dauer für das automatische Schließen beträgt sieben Tage.

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

Cloud Console
Fehlende fehlende Daten – Feld
Fazit Details
Fehlende Daten Offene Vorfälle bleiben offen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, bleibt die Bedingung auch weiterhin erfüllt, wenn keine Daten mehr eingehen. Für diesen Fall ist ein Vorfall geöffnet. Wenn ein Vorfall geöffnet ist und keine Daten eingehen, beginnt der Timer zum automatischen Schließen nach einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, ist der Vorfall geschlossen.

Bei Bedingungen, die nicht erfüllt sind, wird die Bedingung weiterhin nicht erfüllt, wenn keine Daten mehr eintreffen.

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

Wenn Bedingungen erfüllt sind, bleibt die Bedingung auch weiterhin erfüllt, wenn keine Daten mehr eingehen. Für diesen Fall ist ein Vorfall geöffnet. Wenn ein Vorfall geöffnet ist und für die Dauer des automatischen Schließens keine Daten vorliegen, wird der Vorfall geschlossen.

Bei Bedingungen, die nicht erfüllt sind, verhält sich diese Einstellung dazu, dass die Grenzwertbedingung für den Messwert wie eine fehlende Bedingung erfüllt wird. Wenn Daten nicht innerhalb des im neuen Testfenster angegebenen Zeitraums ankommen, wird die Bedingung als erfüllt ausgewertet. Bei einer Benachrichtigungsrichtlinie mit einer Bedingung wird die Bedingung erfüllt, wenn ein Vorfall geöffnet wird.

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

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

Bei Bedingungen, die nicht erfüllt sind, wird die Bedingung weiterhin nicht erfüllt, wenn keine Daten mehr eintreffen.

API

Sie können konfigurieren, wie Monitoring eine Bedingung für den Messwertschwellenwert auswertet, wenn keine Daten mehr eingehen. Wenn beispielsweise ein Vorfall offen ist und eine erwartete Messung nicht eingeht, soll der Vorfall dann von Monitoring geöffnet oder geschlossen werden? Möchtest du einen Vorfall öffnen, wenn keine Daten mehr eingehen und kein Vorfall geöffnet ist? Wie lange sollte ein Vorfall geöffnet bleiben, nachdem keine Daten mehr eintreffen?

Es gibt zwei konfigurierbare Felder, mit denen angegeben wird, wie Monitoring die Bedingungen für Messwertgrenzwerte auswertet, wenn Daten nicht mehr eingehen:

  • Verwenden Sie das Feld evaluationMissingData der Struktur MetricThreshold, um zu konfigurieren, wie Monitoring den Ersatzwert für fehlende Daten ermittelt. Dieses Feld wird ignoriert, wenn das Feld für die Dauer null ist.

  • Konfigurieren Sie mit dem Feld autoClose in der AlertStrategy-Struktur, 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:

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

Wenn Bedingungen erfüllt sind, bleibt die Bedingung auch weiterhin erfüllt, wenn keine Daten mehr eingehen. Für diesen Fall ist ein Vorfall geöffnet. Wenn ein Vorfall geöffnet ist und keine Daten eingehen, beginnt der Timer zum automatischen Schließen nach einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, ist der Vorfall geschlossen.

Bei Bedingungen, die nicht erfüllt sind, wird die Bedingung weiterhin nicht erfüllt, wenn keine Daten mehr eintreffen.

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

Wenn Bedingungen erfüllt sind, bleibt die Bedingung auch weiterhin erfüllt, wenn keine Daten mehr eingehen. Für diesen Fall ist ein Vorfall geöffnet. Wenn ein Vorfall geöffnet ist und keine Daten für die Dauer des automatischen Schließens plus 24 Stunden eintreffen, wird der Vorfall geschlossen.

Bei Bedingungen, die nicht erfüllt sind, verhält sich diese Einstellung dazu, dass die Grenzwertbedingung für den Messwert wie eine fehlende Bedingung erfüllt wird. Wenn Daten nicht innerhalb des im neuen Testfenster angegebenen Zeitraums ankommen, wird die Bedingung als erfüllt ausgewertet. Bei einer Benachrichtigungsrichtlinie mit einer Bedingung wird die Bedingung erfüllt, wenn ein Vorfall geöffnet wird.

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

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

Bei Bedingungen, die nicht erfüllt sind, wird die Bedingung weiterhin nicht erfüllt, wenn keine Daten mehr eintreffen.

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

  • Wenden Sie sich an Ihren Cloud-Drittanbieter, um Möglichkeiten zur Reduzierung der Messwerterfassung zu ermitteln.
  • Verwenden Sie in Ihren Bedingungen längere Dauerfenster. Die Verwendung eines längeren Zeitraums 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 Cloud Monitoring schreiben
    • Logbasierte Messwerte, wenn die Logerfassung nicht verzögert ist

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

Benachrichtigungen und Vorfälle pro Richtlinie

Wenn eine Benachrichtigungsrichtlinie deaktiviert ist, werden keine Vorfälle für die Richtlinie erstellt und keine Benachrichtigungen gesendet.

Wenn eine Benachrichtigungsrichtlinie aktiviert ist, können Vorfälle erstellt und Benachrichtigungen gesendet werden. In diesem Abschnitt wird beschrieben, wie viele offene Vorfälle pro Richtlinie möglich sind und wann Sie mehrere Benachrichtigungen für denselben Vorfall sehen.

Anzahl der offenen Vorfälle pro Richtlinie

Eine Benachrichtigungsrichtlinie kann für viele Ressourcen gelten und ein Problem, das alle Ressourcen betrifft, kann die Richtlinie auslösen sowie Vorfälle für jede Ressource öffnen. Für jede Zeitachse, die eine Bedingung erfüllt, wird ein Vorfall geöffnet.

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

Nehmen wir als Beispiel eine Richtlinie für 2.000 (oder 20.000) Compute Engine-Instanzen. Jede Instanz führt dazu, dass die Benachrichtigungsbedingungen erfüllt werden. Durch Monitoring wird die Anzahl der offenen Vorfälle auf 5.000 begrenzt. Alle verbleibenden Bedingungen, die erfüllt sind, werden ignoriert, bis einige der offenen Vorfälle für diese Richtlinie geschlossen werden.

Anzahl der Benachrichtigungen pro Vorfall

Standardmäßig wird eine Benachrichtigung gesendet, wenn eine Zeitachse dazu führt, dass eine Bedingung erfüllt wird. Sie erhalten möglicherweise mehrere Benachrichtigungen, wenn einer der folgenden Punkte zutrifft:

  • Eine Bedingung überwacht mehrere Zeitachsen.

  • Eine Richtlinie enthält mehrere Bedingungen:

    • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, wird eine Benachrichtigung gesendet und ein Vorfall erstellt. Dies gilt für jede Zeitachse, die dazu führt, dass eine Bedingung erfüllt ist. Angenommen, Sie haben eine Richtlinie mit zwei Bedingungen und jede Bedingung überwacht eine Zeitachse. Wenn diese Richtlinie ausgelöst wird, erhalten Sie zwei Benachrichtigungen und zwei Vorfälle.

    • Beliebige Bedingung erfüllt: Die Richtlinie sendet eine Benachrichtigung, wenn eine neue Kombination von Bedingungen erfüllt wird. Nehmen wir beispielsweise an, dass Bedingung A erfüllt ist, ein Vorfall geöffnet wird und eine Benachrichtigung gesendet wird. Wenn der Vorfall weiterhin geöffnet ist, während eine nachfolgende Messung sowohl Bedingung A als auch Bedingung B erfüllt, wird eine weitere Benachrichtigung gesendet.

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

Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien

Sie können Benachrichtigungsrichtlinien vorübergehend anhalten und neu starten, indem Sie die Richtlinie deaktivieren und wieder aktivieren. Bevor Sie beispielsweise eine Wartung auf einer virtuellen Maschine (VM) ausführen, können Sie die Benachrichtigungsrichtlinien deaktivieren, die diese Instanz überwachen.

Das Deaktivieren einer Benachrichtigungsrichtlinie verhindert, dass die Richtlinie Vorfälle auslöst oder schließt, aber es hindert Cloud Monitoring nicht daran, die Bedingungen der Richtlinie zu bewerten und die Ergebnisse aufzuzeichnen. Schließt nach dem Deaktivieren einer Benachrichtigungsrichtlinie offene Probleme, schalte die entsprechenden Vorfälle stumm. Weitere Informationen zu diesem Vorgang finden Sie unter Vorfälle stummschalten.

Wenn eine deaktivierte Richtlinie wieder aktiviert wird, überprüft Monitoring die Werte aller Bedingungen über das letzte Dauerfenster, das Daten enthalten kann, die vor, während und nach dem pausierten Intervall aufgenommen wurden. Richtlinien können selbst bei sehr langen Dauerfenstern direkt nach ihrer Wiederaufnahme sofort ausgelöst werden.

Beispiel: Ein überwachter Prozess ist zur Wartung 20 Minuten lang inaktiv. Wenn Sie den Prozess neu starten und die Benachrichtigungsrichtlinie sofort wieder aktivieren, erkennt Monitoring, dass der Prozess in den letzten fünf Minuten nicht aktiv ist, und aktiviert einen Vorfall.

Benachrichtigungslatenz

Die Benachrichtigungslatenz ist die Verzögerung zwischen dem ersten Auftreten eines Problems und dem Auslösen der entsprechenden Richtlinie.

Die folgenden Ereignisse und Einstellungen tragen zur Gesamtlatenz von Benachrichtigungen bei:

  • Verzögerung der Messwerterfassung: Die Zeit, die Cloud Monitoring zur Erfassung von Messwerten benötigt. Bei Google Cloud-Werten sind die meisten Messwerte nach der Erfassung 60 Sekunden lang sichtbar. Die Verzögerung ist jedoch vom Messwert abhängig. Die Berechnung der Richtlinie für Benachrichtigungen dauert zusätzlich 60 bis 90 Sekunden. Bei AWS CloudWatch-Messwerten kann die Sichtbarkeit mehrere Minuten dauern. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten ab dem Ende des Dauerzeitraums sein.

  • Dauerfenster: das für die Bedingung konfigurierte Zeitfenster. Bedingungen werden nur erfüllt, wenn eine Bedingung während des gesamten Dauerzeitraums erfüllt ist. Eine Dauer von fünf Minuten bewirkt beispielsweise eine Verzögerung von mindestens fünf Minuten ab dem ersten Ereignis.

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

Weitere Informationen