Mit messwertbasierten Benachrichtigungsrichtlinien in Cloud Monitoring können Sie Zeitreihendaten überwachen, Benachrichtigungen erstellen und Benachrichtigungen senden. Sie können festlegen, wann Benachrichtigungsrichtlinien Benachrichtigungen erstellen und senden, indem Sie Abgleichszeiträume, Testwiederholungsfenster und Regeln mit mehreren Bedingungen konfigurieren. Wenn Sie wissen, wie Benachrichtigungsrichtlinien mit fehlenden Daten, Limits für Benachrichtigungen und Benachrichtigungsverzögerungen umgehen, können Sie Fehlalarme minimieren und die Reaktionsfähigkeit von Benachrichtigungen optimieren.
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 und das Fenster für die erneute Prüfung aus, um festzustellen, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt wurde.
Ausrichtungszeitraum
Bevor Zeitreihendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie regularisiert werden, damit die Benachrichtigungsrichtlinie Daten in regelmäßigen Abständen auswerten kann. Der Regularisierungsprozess wird als Abgleich bezeichnet.
Die Ausrichtung umfasst zwei Schritte:
Die Zeitreihe wird in regelmäßige Zeitintervalle unterteilt, was auch als Bucketing der Daten bezeichnet wird. Das Intervall ist der Ausrichtungszeitraum.
Einen einzelnen Wert für die Punkte im Ausrichtungszeitraum berechnen Sie können festlegen, wie dieser einzelne Punkt berechnet wird. Sie können alle Werte addieren, 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 Zeitreihe.
Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten beträgt, enthält der Ausrichtungszeitraum um 13:00 Uhr die zwischen 12:55 Uhr 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.
Im Monitoring wird ein Ausrichtungszeitraum so konfiguriert:
Google Cloud Console
Sie konfigurieren den Ausrichtungszeitraum, indem Sie auf der Seite Benachrichtigungsbedingungen einen Wert für die folgenden Felder auswählen:
- Rollierendes Zeitfenster: Gibt den Zeitraum an, der ausgewertet werden soll.
- Funktion für rollierendes Zeitfenster: Gibt die mathematische Funktion an, die für das Fenster mit Datenpunkten ausgeführt werden soll.
Weitere Informationen zu den verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Einige der Aligner-Funktionen richten die Daten sowohl aus als auch konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine ausführliche Erläuterung finden Sie unter Arten, Typen und Umwandlungen.
API
Sie konfigurieren den Ausrichtungszeitraum, indem Sie die Felder aggregations.alignmentPeriod und aggregations.perSeriesAligner in den Strukturen MetricThreshold und MetricAbsence festlegen.
Weitere Informationen zu den verfügbaren Funktionen finden Sie in der API-Referenz unter Aligner. Einige der Aligner-Funktionen richten die Daten sowohl aus als auch konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine ausführliche Erläuterung finden Sie unter Arten, Typen und Umwandlungen.
Um die Auswirkung des Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie zu veranschaulichen, betrachten wir eine Messwertschwellenwert-Bedingung, die einen Messwert mit einem Stichprobenzeitraum von einer Minute überwacht. Angenommen, der Ausrichtungszeitraum ist auf fünf Minuten und der Aligner auf sum festgelegt. 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 dass die Bedingung jede Minute ausgewertet wird.
In diesem Beispiel beträgt das im nächsten Abschnitt beschriebene Zeitfenster für die erneute Prüfung drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Auswertungen der Bedingung:
Jede Zeile in der Abbildung stellt eine einzelne Bewertung der Bedingung dar. Die Zeitreihendaten werden angezeigt. Die Punkte im Ausrichtungszeitraum werden mit blauen Punkten dargestellt. Ältere Punkte sind schwarz. In jeder Zeile wird der ausgerichtete Wert angezeigt und ob dieser Wert größer als der Schwellenwert von zwei ist. Für die Zeile mit dem Label start wird der ausgerichtete Wert auf eins berechnet, was unter dem Schwellenwert liegt.
Bei der nächsten Auswertung beträgt die Summe der Stichproben im Ausrichtungszeitraum zwei.
Bei der dritten Auswertung ist die Summe drei. Da dieser Wert über dem Schwellenwert liegt, wird ein Timer für das Fenster für die erneute Prüfung gestartet.
Zeitfenster noch einmal testen
Die Bedingung einer Benachrichtigungsrichtlinie hat ein Zeitfenster für die erneute Prüfung, das verhindert, dass die Bedingung aufgrund einer einzelnen Messung oder Prognose erfüllt wird. Angenommen, das Zeitfenster für die erneute Prüfung einer Bedingung ist auf 15 Minuten festgelegt. Im Folgenden wird das Verhalten der Bedingung basierend auf ihrem Typ beschrieben:
- Messwert-Schwellenwertbedingungen sind erfüllt, wenn bei einer einzelnen Zeitreihe jede ausgerichtete Messung in einem 15-minütigen Intervall den Schwellenwert verletzt.
- Bedingungen für fehlende Messwerte sind erfüllt, wenn in einem 15-minütigen Intervall keine Daten für eine Zeitreihe eingehen.
- Prognosebedingungen sind erfüllt, wenn jede Prognose, die während eines 15-minütigen Zeitfensters erstellt wird, vorhersagt, dass die Zeitreihe den Grenzwert innerhalb des Prognosefensters überschreitet.
Bei Richtlinien mit einer Bedingung wird eine Benachrichtigung geöffnet und Benachrichtigungen werden gesendet, wenn die Bedingung erfüllt ist. Diese Benachrichtigungen bleiben offen, solange die Bedingung erfüllt ist.
Google Cloud Console
Sie konfigurieren das Zeitfenster für die erneute Prüfung im Schritt Trigger für Benachrichtigungen konfigurieren im Feld Zeitfenster für erneute Prüfung.
API
Sie konfigurieren das Zeitfenster für die erneute Prüfung, indem Sie das Feld duration in den Strukturen MetricThreshold und MetricAbsence festlegen.
In der vorherigen Abbildung wurden drei Auswertungen einer Messwert-Schwellenwert-Bedingung dargestellt. Zum Zeitpunkt start + 2 minutes ist der ausgerichtete Wert größer als der Schwellenwert. Die Bedingung ist jedoch nicht erfüllt, da das Fenster für die erneute Prüfung auf drei Minuten festgelegt ist. Die folgende Abbildung zeigt die Ergebnisse für die nächsten Auswertungen der Bedingung:
Obwohl der ausgerichtete Wert zum Zeitpunkt start + 2 minutes größer als der Schwellenwert ist, ist die Bedingung erst erfüllt, wenn der ausgerichtete Wert drei Minuten lang größer als der Schwellenwert ist. Dieses Ereignis tritt zum Zeitpunkt start + 5 minutes auf.
Das Zeitfenster für die erneute Prüfung einer Bedingung wird jedes Mal zurückgesetzt, wenn eine Messung oder Prognose die Bedingung nicht erfüllt. Legen Sie das Zeitfenster für die erneute Prüfung daher so fest, dass es lang genug ist, um Fehlalarme zu minimieren, aber kurz genug, um zu prüfen, ob Warnungen rechtzeitig geöffnet werden. Dieses Verhalten wird im folgenden Beispiel veranschaulicht:
Beispiel
Diese Benachrichtigungsrichtlinie enthält eine Messwertschwellenwert-Bedingung, die ein fünfminütiges Fenster für die erneute Prüfung angibt.
Wenn die HTTP-Antwortlatenz größer als zwei Sekunden ist
und wenn die Latenz fünf Minuten lang über dem Schwellenwert liegt,
dann öffnen Sie eine Benachrichtigung und senden Sie eine E-Mail an Ihr Supportteam.
Die folgende Sequenz veranschaulicht, wie sich das Zeitfenster für die erneute Prüfung auf die Auswertung der Bedingung auswirkt:
- Die HTTP-Latenz beträgt weniger als zwei Sekunden.
- In den nächsten drei aufeinanderfolgenden Minuten beträgt die HTTP-Latenz mehr als zwei Sekunden.
- Bei der nächsten Messung beträgt die Latenz weniger als zwei Sekunden, sodass die Bedingung das Fenster für die erneute Prüfung zurücksetzt.
In den nächsten fünf aufeinanderfolgenden Minuten beträgt die HTTP-Latenz mehr als zwei Sekunden, sodass die Bedingung erfüllt ist.
Da die Benachrichtigungsrichtlinie nur eine Bedingung hat, sendet Monitoring Benachrichtigungen, wenn die Bedingung erfüllt ist.
Best Practices zum Festlegen des Abgleichszeitraums und des Zeitfensters für die erneute Prüfung
Wenn Sie eine Benachrichtigungsrichtlinie konfigurieren möchten, die zuverlässig und ohne Fehlalarme ausgewertet wird, konfigurieren Sie den Ausrichtungszeitraum und das Fenster für die erneute Prüfung entsprechend Ihrem Anwendungsfall.
Ausrichtungszeitraum festlegen
Der Ausrichtungszeitraum bestimmt, wie viele Stichproben der Aligner zu einer aggregierten Messung kombiniert. Berücksichtigen Sie beim Festlegen des Ausrichtungszeitraums das Stichprobenintervall und die Aufnahmeverzögerung des Messwerts:
Mindestausrichtungszeitraum: Der Ausrichtungszeitraum muss mindestens 60 Sekunden (1 Minute) betragen und ein ganzzahliges Vielfaches von 60 Sekunden sein. Damit jedes Ausrichtungsfenster repräsentative Daten erfasst, legen Sie den Ausrichtungszeitraum auf mindestens das Stichprobenintervall des Messwerts fest, aufgerundet auf ein Vielfaches von 60 Sekunden. Bei einem Messwert, der alle 30 Sekunden Stichproben erhebt, legen Sie den Ausrichtungszeitraum beispielsweise auf mindestens 60 Sekunden fest.
Aufnahmeverzögerung: Bei Messwertdaten kommt es zu einer Latenz bei der Erfassung und Aufnahme, bevor sie Monitoring erreichen. Bei der Bewertung von Benachrichtigungsrichtlinien verschiebt Monitoring die Bewertungszeiten in die Vergangenheit, um die erwartete Aufnahmeverzögerung der einzelnen Messwerte zu berücksichtigen. Diese beträgt in der Regel mindestens 60 Sekunden, wobei die Verzögerungen bei Messwerten wie Verfügbarkeitsdiagnosen kürzer und bei Messwerten mit höherer Latenz wie benutzerdefinierten logbasierten oder Cloud-Messwerten von Drittanbietern länger sind. Wenn jedoch bei einem externen oder Drittanbieter-Messwert eine variable Aufnahmeverzögerung auftritt, die die integrierte Verzögerung überschreitet, wählen Sie einen Ausrichtungszeitraum, der groß genug ist, um mehrere Stichprobenintervalle zu erfassen, damit verzögerte Stichproben keine leeren Ausrichtungsfenster erzeugen.
Maximaler Ausrichtungszeitraum: Bei Bedingungen für Messwertgrenzwerte kann der Ausrichtungszeitraum maximal 25 Stunden betragen. Bei Bedingungen für das Fehlen von Messwerten darf die Summe aus Anpassungszeitraum und Testwiederholungsfenster 25 Stunden nicht überschreiten. Wenn Sie historische Trends über Lookback-Windows von mehr als 25 Stunden (bis zu 2 Jahre) auswerten müssen, verwenden Sie PromQL. Bei PromQL-Benachrichtigungsregeln, die mehr als 25 Stunden zurückblicken, muss das Testwiederholungsfenster (
duration) null sein. Benutzerdefinierte oder logbasierte Messwerte werden nicht unterstützt und es werden Mindestbewertungsintervalle erzwungen, die mit der Lookback-Dauer zunehmen:- 25 Stunden, 10 Minuten bis 8 Tage: 5 Minuten
- 8 bis 16 Tage: 1 Stunde
- 16 bis 32 Tage: 2 Stunden
- 32 bis 93 Tage: 6 Stunden
- 93 Tage bis 2 Jahre: 12 Stunden
Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien mit PromQL erstellen.
Zeitfenster für erneute Prüfung festlegen
Das Fenster für die erneute Prüfung (duration) gibt an, wie lange eine Zeitreihe den Bedingungsschwellenwert kontinuierlich verletzen muss, bevor Monitoring eine Benachrichtigung öffnet:
Reaktionsfähigkeit: Wenn Sie bei Messwertschwellenwert-Bedingungen das Fenster für die erneute Prüfung auf null setzen (in der Google Cloud Console als Keine erneute Prüfung angezeigt), wird eine Benachrichtigung ausgelöst, wenn eine einzelne ausgerichtete Messung den Schwellenwert verletzt. Bei Bedingungen für das Fehlen von Messwerten müssen die Daten für das gesamte erneute Testfenster fehlen, bevor die Bedingung erfüllt ist.
Falsche Alarme vermeiden: Um falsche Alarme zu vermeiden, die durch vorübergehende Spitzen, Jitter bei der Auswertung oder Abweichungen bei der Messwerterfassung verursacht werden, legen Sie das Fenster zum nochmaligen Testen auf mindestens 180 Sekunden (3 Minuten) fest. Wenn Sie das Fenster für die erneute Prüfung auf null setzen, wird bei einem einzelnen anomalen Punkt eine Benachrichtigung ausgelöst.
Die Bedingungen von Benachrichtigungsrichtlinien werden in einer festen Häufigkeit ausgewertet, außer wenn Sie PromQL verwenden. Bei PromQL kann die Häufigkeit der Auswertung je nach Lookback-Dauer der Abfrage variieren.
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 eine Benachrichtigung ausgelöst wird. So konfigurieren Sie, wie mehrere Bedingungen kombiniert werden:
Google Cloud Console
Sie konfigurieren die Kombinationsoptionen im Schritt Trigger mit mehreren Bedingungen.
API
Sie konfigurieren Kombinatoroptionen mit dem Feld combiner der Struktur AlertPolicy.
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 für Richtlinienauslöser |
Cloud Monitoring API Kombinationswert |
Bedeutung |
|---|---|---|
| Eine beliebige Bedingung wird erfüllt | OR |
Eine Benachrichtigung wird geöffnet, wenn eine Ressource eine der Bedingungen erfüllt. |
| Alle Bedingungen werden erfüllt , auch für verschiedene Ressourcen pro Bedingung. (Standard) |
AND |
Eine Benachrichtigung wird für jede Bedingung geöffnet, die erfüllt ist, wenn alle Bedingungen erfüllt sind, auch wenn eine andere Ressource dazu führt, dass diese Bedingungen erfüllt sind. |
| Alle Bedingungen werden erfüllt | AND_WITH_MATCHING_RESOURCE |
Eine Benachrichtigung wird für jede Bedingung geöffnet, die erfüllt ist, wenn alle Bedingungen erfüllt sind, nur wenn dieselbe Ressource dazu führt, dass jede Bedingung erfüllt wird. Diese Einstellung ist die strengste Kombinationsoption. |
In diesem Kontext bedeutet der Begriff erfüllt, 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 als true ausgewertet wird.
Beispiel
Angenommen, Sie haben 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 1 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 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 Schwellenwert liegt, ist die Bedingung CPU usage is too high erfüllt. Wenn die Bedingungen mit Eine Bedingung ist erfüllt kombiniert werden, wird eine Benachrichtigung erstellt, da eine Bedingung erfüllt ist. Wenn die Bedingungen mit Alle Bedingungen sind erfüllt oder Alle Bedingungen sind erfüllt, auch für unterschiedliche Ressourcen für jede Bedingung kombiniert werden, wird keine Benachrichtigung 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 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:
Eine Bedingung ist erfüllt: Eine Benachrichtigung wird erstellt, wenn eine Ressource dazu führt, dass eine Bedingung erfüllt wird. In diesem Beispiel führt vm2 die Bedingung
Excessive utilizationaus.Wenn vm2 die Bedingung
CPU usage is too higherfüllt, wird ebenfalls eine Benachrichtigung erstellt. Es wird eine Benachrichtigung erstellt, da vm1 und vm2, die die BedingungCPU usage is too higherfüllen, unterschiedliche Ereignisse sind.Alle Bedingungen sind erfüllt, auch wenn sie sich auf unterschiedliche Ressourcen beziehen: Es wird eine Benachrichtigung erstellt, da beide Bedingungen erfüllt sind.
Alle Bedingungen sind erfüllt: Es wird keine Benachrichtigung erstellt, da dieser Kombinator erfordert, dass dieselbe Ressource alle Bedingungen erfüllt. In diesem Beispiel wird keine Benachrichtigung erstellt, da vm1 dazu führt, dass
CPU usage is too higherfüllt wird, während vm2 dazu führt, dassExcessive utilizationerfüllt wird.
Unvollständige Messwertdaten
Wenn keine Zeitreihendaten mehr eingehen oder Daten verzögert sind, werden die Daten von Monitoring als fehlend eingestuft. Fehlende Daten können dazu führen, dass Warnungen nicht geschlossen werden. Die Verzögerungen bei der Datenübertragung von Drittanbieter-Cloud-Anbietern können bis zu 30 Minuten betragen, wobei Verzögerungen von 5–15 Minuten am häufigsten sind. Eine lange Verzögerung, die länger als das Fenster 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. Eine spätere Prüfung der Zeitreihendaten zeigt dieses Problem möglicherweise nicht, da es nach dem Eintreffen der Daten keine Hinweise auf Verzögerungen gibt.
Google Cloud Console
Sie können konfigurieren, wie Monitoring eine Messwertschwellenwert-Bedingung auswertet, wenn keine Daten mehr eingehen. Wenn beispielsweise eine Benachrichtigung offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring die Benachrichtigung offen lassen oder sofort schließen? Soll eine Benachrichtigung ausgelöst werden, wenn keine Daten mehr eingehen und keine Benachrichtigung offen ist? Wie lange soll eine Benachrichtigung offen bleiben, nachdem keine Daten mehr eingehen?
Es gibt zwei konfigurierbare Felder, die angeben, wie Monitoring Bedingungen für Messwertschwellenwerte auswertet, wenn keine Daten mehr eingehen:
Wenn Sie konfigurieren möchten, wie Monitoring den Ersatzwert für fehlende Daten bestimmt, verwenden Sie das Feld Auswertung fehlender Daten, das Sie im Schritt Bedingungstrigger festlegen. Dieses Feld ist deaktiviert, wenn das Zeitfenster für erneute Tests auf Kein erneuter Test festgelegt ist.
Das Fenster für die erneute Prüfung ist das Feld „duration“ in der Cloud Monitoring API.
Mit dem Feld Dauer für automatisches Schließen von Benachrichtigungen können Sie konfigurieren, wie lange Monitoring wartet, bevor eine offene Benachrichtigung geschlossen wird, nachdem keine Daten mehr eingehen. Die Dauer für das automatische Schließen 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 Feld „Fehlende Daten“ beschrieben:
| Google Cloud Console Feld „Bewertung fehlender Daten“ |
Zusammenfassung | Details |
|---|---|---|
| Fehlende Daten leer | Offene Meldungen bleiben offen. Neue Benachrichtigungen werden nicht geöffnet. |
Bedingungen, die erfüllt sind, bleiben erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, bleibt sie offen. Wenn eine Benachrichtigung offen ist und keine Daten eingehen, wird der Timer für das automatische Schließen nach einer Verzögerung von mindestens 15 Minuten gestartet. Wenn der Timer abläuft, wird die Benachrichtigung geschlossen. Bedingungen, die nicht erfüllt sind, bleiben unerfüllt, wenn keine Daten mehr eingehen. |
| Fehlende Datenpunkte werden als Werte behandelt, die gegen die Richtlinienbedingung verstoßen | Offene Meldungen bleiben offen. Neue Benachrichtigungen können geöffnet werden. |
Bedingungen, die erfüllt sind, bleiben erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, bleibt sie offen. Wenn eine Benachrichtigung offen ist und für die Dauer des automatischen Schließens plus 24 Stunden keine Daten eingehen, wird die Benachrichtigung geschlossen. Bei Bedingungen, die nicht erfüllt sind, führt diese Einstellung dazu, dass sich die Messwertschwellenwert-Bedingung wie ein |
| Fehlende Datenpunkte werden als Werte behandelt, die nicht gegen die Richtlinienbedingung verstoßen | Offene Benachrichtigungen werden geschlossen. Neue Benachrichtigungen werden nicht geöffnet. |
Wenn die Bedingungen erfüllt sind, werden sie nicht mehr erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, wird sie geschlossen. Bedingungen, die nicht erfüllt sind, bleiben unerfüllt, wenn keine Daten mehr eingehen. |
API
Sie können konfigurieren, wie Monitoring eine Messwertschwellenwert-Bedingung auswertet, wenn keine Daten mehr eingehen. Wenn beispielsweise eine Benachrichtigung offen ist und eine erwartete Messung nicht eintrifft, soll Monitoring die Benachrichtigung offen lassen oder sofort schließen? Soll eine Benachrichtigung ausgelöst werden, wenn keine Daten mehr eingehen und keine Benachrichtigung offen ist? Wie lange soll eine Benachrichtigung offen bleiben, nachdem keine Daten mehr eingehen?
Es gibt zwei konfigurierbare Felder, die angeben, wie Monitoring Bedingungen für Messwertschwellenwerte auswertet, wenn keine Daten mehr eingehen:
Wenn Sie konfigurieren möchten, wie Monitoring den Ersatzwert für fehlende Daten bestimmt, verwenden Sie das Feld
evaluationMissingDatader StrukturMetricThreshold. Dieses Feld wird ignoriert, wenn das Felddurationnull ist.Wenn Sie konfigurieren möchten, wie lange Monitoring wartet, bevor eine offene Benachrichtigung geschlossen wird, nachdem keine Daten mehr eingehen, verwenden Sie das Feld
autoClosein der StrukturAlertStrategy.
Im Folgenden werden die verschiedenen Optionen für das Feld „Fehlende Daten“ beschrieben:
API-Feld evaluationMissingData |
Zusammenfassung | Details |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Offene Meldungen bleiben offen. Es werden keine neuen Benachrichtigungen geöffnet. |
Bedingungen, die erfüllt sind, bleiben erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, bleibt sie offen. Wenn eine Benachrichtigung offen ist und 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 die Benachrichtigung geschlossen. Bedingungen, die nicht erfüllt sind, bleiben unerfüllt, wenn keine Daten mehr eingehen. |
EVALUATION_MISSING_DATA_ACTIVE |
Offene Meldungen bleiben offen. Neue Benachrichtigungen können geöffnet werden. |
Bedingungen, die erfüllt sind, bleiben erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, bleibt sie offen. Wenn eine Benachrichtigung offen ist und für die Dauer des automatischen Schließens plus 24 Stunden keine Daten eingehen, wird die Benachrichtigung geschlossen. Bei Bedingungen, die nicht erfüllt sind, verhält sich die Messwertschwellenwert-Bedingung wie eine |
EVALUATION_MISSING_DATA_INACTIVE |
Offene Benachrichtigungen werden geschlossen. Es werden keine neuen Benachrichtigungen geöffnet. |
Wenn die Bedingungen erfüllt sind, werden sie nicht mehr erfüllt, wenn keine Daten mehr eingehen. Wenn für diese Bedingung eine Benachrichtigung offen ist, wird sie geschlossen. Bedingungen, die nicht erfüllt sind, bleiben unerfüllt, wenn keine Daten mehr eingehen. |
Bewertung fehlender Daten über den gesamten Lebenszyklus von Arbeitslasten hinweg
In Bedingungen für Messwertschwellenwerte und Monitoring Query Language können Sie konfigurieren, wie Monitoring fehlende Daten auswertet, wenn Zeitreihen keine Berichte mehr erstellen. Wenn Sie die Auswertung fehlender Daten konfigurieren möchten, muss die Bedingung ein Prüfzeitfenster (duration) haben, das nicht null ist. PromQL-Bedingungen unterstützen keine Einstellungen für die Auswertung fehlender Daten. Stattdessen schließt Monitoring eine offene PromQL-Benachrichtigung, wenn Daten für zwei Auswertungsintervalle plus einen Kulanzzeitraum fehlen.
Wenn eine Bedingung fehlende Daten mit der Standardeinstellung Fehlende Daten leer (EVALUATION_MISSING_DATA_NO_OP oder EVALUATION_MISSING_DATA_UNSPECIFIED) auswertet, bleibt eine bereits geöffnete Benachrichtigung geöffnet, wenn keine Messwertdaten mehr eingehen. Wenn beispielsweise ein sitzungsspezifischer Job oder Container einen anhaltenden Anstieg verzeichnet, der eine Benachrichtigung auslöst, und die Arbeitslast dann beendet wird, bleibt die Benachrichtigung so lange offen, bis die Dauer für das automatische Schließen (standardmäßig 7 Tage) abgelaufen ist, da keine nachfolgenden Datenpunkte eingehen, die zeigen, dass sich der Messwert unter den Schwellenwert erholt hat.
Wenn Sie das Verhalten der Benachrichtigungsrichtlinie an den Lebenszyklus Ihrer Anwendung anpassen möchten, wählen Sie eine Einstellung für die Bewertung fehlender Daten und eine Dauer für das automatische Schließen basierend auf den folgenden Arbeitslasttypen aus:
| Arbeitslasttyp | Empfohlene Einstellung für fehlende Daten | Empfohlene Dauer bis zum automatischen Schließen | Lebenszyklusverhalten und Begründung |
|---|---|---|---|
| Kontinuierliche Daemons und Infrastruktur (Compute Engine-VMs, Cloud SQL-Instanzen, GKE-Knoten) |
Fehlende Daten leer (EVALUATION_MISSING_DATA_NO_OP) oder Werte, die gegen die Bedingung verstoßen (EVALUATION_MISSING_DATA_ACTIVE) |
Standard (7 Tage) oder 24 Stunden | Kontinuierliche Infrastruktur sollte Messwerttelemetrie ohne Unterbrechung ausgeben. Wenn die Telemetrie beendet wird, während eine Benachrichtigung offen ist, sorgt das Beibehalten der offenen Benachrichtigung dafür, dass Netzwerkpartitionen, VM-Abstürze oder Daemon-Fehler die Aufmerksamkeit des Operators erhalten, anstatt automatisch geschlossen zu werden. |
| Sitzungsspezifische Arbeitslasten und Autoscaling-Dienste (GKE-Pods, Cloud Run-Jobs und -Überarbeitungen, Cloud Tasks, Batch-Worker) |
Werte, die nicht gegen die Bedingung verstoßen
(EVALUATION_MISSING_DATA_INACTIVE) |
30 Minuten bis 2 Stunden | Sitzungsspezifische Pods und serverlose Container werden nach Abschluss der Arbeit beendet oder auf null skaliert. Wenn Sie fehlende Daten auf „Inaktiv“ setzen, wird die Bedingung nicht mehr als Verstoß gewertet und die Benachrichtigung wird geschlossen, wenn ein sitzungsspezifischer Container verschwindet. Wenn Sie die Dauer bis zum automatischen Schließen verkürzen, bleiben vorübergehende Vorfälle nicht tagelang bestehen. |
| Regelmäßige und geplante Arbeitslasten (Tägliche Batchabfragen, stündliche Cronjobs, Analysen für Kalendertage) |
Werte, die nicht gegen die Bedingung verstoßen
(EVALUATION_MISSING_DATA_INACTIVE) |
30 Minuten bis 2 Stunden | Periodische Batch-Arbeitslasten melden Messwerte nur während aktiver Ausführungen. Da die Dauer bis zum automatischen Schließen ab dem Zeitpunkt gemessen wird, an dem keine Telemetriedaten mehr eingehen, wird durch die Verwendung von EVALUATION_MISSING_DATA_INACTIVE und einer verkürzten Dauer bis zum automatischen Schließen (mindestens 30 Minuten) verhindert, dass Benachrichtigungen für eine einzelne Ausführung über mehrere Kalendertage hinweg bestehen bleiben. |
So können Sie Probleme aufgrund fehlender Daten minimieren:
- Wenden Sie sich an Ihren Drittanbieter für die Cloud, um Möglichkeiten zur Reduzierung der Latenz bei der Messwerterfassung zu finden.
- Verwenden Sie in Ihren Bedingungen längere Zeiträume für erneute Tests. Ein längeres Zeitfenster für die erneute Prüfung hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger reaktionsschnell sind.
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 Ops-Agent – Übersicht, Benutzerdefinierte Messwerte – Übersicht und Logbasierte Messwerte.
Wann Monitoring Benachrichtigungen sendet und Warnungen erstellt
Cloud Monitoring sendet eine Benachrichtigung, wenn eine Zeitreihe dazu führt, dass eine Bedingung erfüllt wird. Die Benachrichtigung wird an alle Benachrichtigungskanäle gesendet. Sie können eine Benachrichtigung nicht auf einen bestimmten Kanal oder eine Teilmenge der Kanäle Ihrer Richtlinie beschränken.
Wenn Sie wiederholte Benachrichtigungen konfigurieren, wird dieselbe Benachrichtigung noch einmal an bestimmte Benachrichtigungskanäle für Ihre Benachrichtigungsrichtlinie gesendet.
In den folgenden Fällen erhalten Sie möglicherweise mehrere eindeutige Benachrichtigungen zu einer Benachrichtigungsrichtlinie:
Eine Bedingung überwacht mehrere Zeitreihen.
Eine Richtlinie enthält mehrere Bedingungen. In diesem Fall hängen die Benachrichtigungen, die Sie erhalten, vom Wert des Triggers mit mehreren Bedingungen der Benachrichtigungsrichtlinie ab:
Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, sendet die Benachrichtigungsrichtlinie für jede Zeitreihe, die dazu führt, dass eine Bedingung erfüllt wird, eine Benachrichtigung und erstellt eine Benachrichtigung.
Sie können Cloud Monitoring nicht so konfigurieren, dass nur eine Benachrichtigung erstellt und nur eine Benachrichtigung gesendet wird, wenn die Benachrichtigungsrichtlinie mehrere Bedingungen enthält.
Eine Bedingung ist erfüllt: Die Benachrichtigungsrichtlinie sendet eine Benachrichtigung, wenn eine Zeitreihe dazu führt, dass die Bedingung erfüllt ist.
Weitere Informationen finden Sie unter Richtlinien mit mehreren Bedingungen.
Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt wurden, benachrichtigen Sie auch, wenn die Bedingung erfüllt ist und wenn die Bedingung nicht mehr erfüllt ist. 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 Verhalten aktiviert.
Wenn Monitoring keine Benachrichtigungen sendet oder Benachrichtigungen erstellt
In den folgenden Situationen erstellt Monitoring keine Benachrichtigungen und sendet keine Benachrichtigungen, wenn die Bedingungen einer Benachrichtigungsrichtlinie erfüllt sind:
- Die Benachrichtigungsrichtlinie ist deaktiviert.
- Die Benachrichtigungsrichtlinie ist pausiert.
- Monitoring hat die maximale Anzahl offener Benachrichtigungen erreicht.
Deaktivierte Benachrichtigungsrichtlinien
Monitoring erstellt keine Benachrichtigungen und sendet keine Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Monitoring wertet jedoch weiterhin die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie aus.
Wenn Sie eine deaktivierte Richtlinie aktivieren, wertet Monitoring die Werte aller Bedingungen im letzten Wiederholungsfenster aus. Das letzte Fenster für die erneute Prüfung kann Daten enthalten, die vor, während und nach der Aktivierung der Richtlinie erfasst wurden. Die Bedingungen einer deaktivierten Richtlinie können sofort nach der Wiederaufnahme der Richtlinie erfüllt werden, auch bei großen Zeitfenstern für die erneute Prüfung.
Angenommen, Sie haben eine Benachrichtigungsrichtlinie, die einen bestimmten Prozess überwacht, und Sie deaktivieren diese Richtlinie. In der folgenden Woche fällt der Prozess aus und Sie werden nicht benachrichtigt, da die Benachrichtigungsrichtlinie deaktiviert ist. Wenn Sie den Prozess neu starten und die Benachrichtigungsrichtlinie sofort aktivieren, erkennt Monitoring, dass der Prozess in den letzten fünf Minuten nicht aktiv war, und löst eine Benachrichtigung aus.
Die Benachrichtigungen, die sich auf eine deaktivierte Benachrichtigungsrichtlinie beziehen, bleiben so lange offen, bis die Dauer bis zur automatischen Schließung der Richtlinie abgelaufen ist.
Pausierte Benachrichtigungsrichtlinien
Monitoring sendet keine Benachrichtigungen und erstellt keine Warnungen für eine Benachrichtigungsrichtlinie, die auf „Schlummern“ gesetzt ist. Wir empfehlen, Benachrichtigungsrichtlinien in den Schlummermodus zu versetzen, wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie nur für kurze Intervalle Benachrichtigungen sendet. Bevor Sie beispielsweise Wartungsarbeiten an einer virtuellen Maschine (VM) durchführen, können Sie eine Schlummerfunktion erstellen und die Benachrichtigungsrichtlinien, die die Instanz überwachen, zu den Schlummerfunktionskriterien hinzufügen.
Wenn Sie eine Benachrichtigungsrichtlinie in den Schlummermodus versetzen, schließt Monitoring alle offenen Benachrichtigungen, die mit der Richtlinie verknüpft sind. Monitoring kann neue Benachrichtigungen öffnen, nachdem die Schlummerfunktion abgelaufen ist. Weitere Informationen findest du unter Benachrichtigungen und Warnungen für einen bestimmten Zeitraum deaktivieren.
Limits für Benachrichtigungen und offene Warnungen
Eine Benachrichtigungsrichtlinie kann auf viele Ressourcen angewendet werden. Ein Problem, das alle Ressourcen betrifft, kann dazu führen, dass die Benachrichtigungsrichtlinie Benachrichtigungen für jede Ressource öffnet. Für jede Zeitreihe, die dazu führt, dass eine Bedingung erfüllt wird, wird eine Benachrichtigung geöffnet.
Um eine Überlastung des Systems zu vermeiden, ist die Anzahl der Benachrichtigungen, die eine einzelne Richtlinie gleichzeitig öffnen kann, auf 1.000 begrenzt.
Angenommen, eine Richtlinie gilt für 2.000 Compute Engine-Instanzen und jede Instanz führt dazu, dass die Benachrichtigungsbedingungen erfüllt werden. Monitoring begrenzt die Anzahl der offenen Benachrichtigungen auf 1.000. Alle verbleibenden Bedingungen, die erfüllt sind, werden ignoriert, bis einige der offenen Benachrichtigungen 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 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, erstellt Monitoring bis zu 180 Sekunden lang keine Benachrichtigung, 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 bei 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 dauert zusätzlich bis zu 5 Minuten und 30 Sekunden. Bei AWS CloudWatch-Messwerten kann die Verzögerung bis zur Sichtbarkeit mehrere Minuten betragen. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten dauern (ab dem Ende des Zeitfensters für die erneute Prüfung).
Zeitfenster für erneute Prüfung: Das für die Bedingung konfigurierte Zeitfenster. Bedingungen sind nur erfüllt, wenn eine Bedingung während des gesamten Zeitfensters für die erneute Prüfung erfüllt ist. Wenn Sie beispielsweise ein Zeitfenster für die erneute Prüfung von fünf Minuten festlegen, wird die Benachrichtigung um mindestens fünf Minuten verzögert, nachdem das Ereignis zum ersten Mal aufgetreten ist.
Zeit bis zum Eintreffen der Benachrichtigung: Bei Benachrichtigungskanälen wie E-Mail und SMS kann es zu Netzwerk- oder anderen Latenzen kommen, die nichts mit dem Inhalt der Benachrichtigung zu tun haben. Diese können manchmal mehrere Minuten betragen. 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:
Eine Auswahl an Benachrichtigungsrichtlinien finden Sie unter Beispielrichtlinien.