Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie Ausrichtungszeiträume und Zeitfenster für erneute Tests beschrieben werden bestimmen, wann eine Bedingung erfüllt ist, wie Benachrichtigungsrichtlinien mehrere und wie Benachrichtigungsrichtlinien fehlende Datenpunkte ersetzen. Außerdem wird die maximale Anzahl offener Vorfälle für eine Richtlinie beschrieben. die Anzahl der Benachrichtigungen pro Vorfall, und warum es zu Verzögerungen bei Benachrichtigungen kommt.

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 Zeitfenster für den erneuten Test aus wenn ermittelt wird, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt ist.

Ausrichtungszeitraum

Bevor Zeitreihendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie Regularisiert sind, sodass die Benachrichtigungsrichtlinie regelmäßig Daten zum Auswerten enthält. Der Regularisierungsprozess wird als Ausrichtung bezeichnet.

Die Ausrichtung umfasst zwei Schritte:

  • Das Unterteilen der Zeitreihen in regelmäßige Zeitintervalle, auch Bucketing genannt mit den Daten. Das Intervall ist der Ausrichtungszeitraum.

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

    Weitere Informationen zur Abstimmung finden Sie unter Ausrichtung: Regularisierung innerhalb der Reihe:

Wenn der Ausrichtungszeitraum beispielsweise fünf Minuten beträgt, wird um 13:00 Uhr Ausrichtungszeitraum enthält die Stichproben, die zwischen 12:55 Uhr und 13:00 Uhr empfangen wurden. Um 13:01 Uhr geht der Ausrichtungszeitraum eine Minute weiter und enthält die zwischen 12:56 Uhr und 13:01 Uhr eingegangenen Stichproben.

In Monitoring wird ein Ausrichtungszeitraum so konfiguriert:

Google Cloud Console

Sie konfigurieren den Ausrichtungszeitraum, indem Sie Wählen Sie auf der Seite Benachrichtigungsbedingungen einen Wert für die folgenden Felder aus:

  • Rollierendes Fenster: Gibt den auszuwertenden Zeitraum an.
  • Funktion für rollierendes Fenster: Gibt die mathematische Funktion für auf das Fenster der Datenpunkte.

Weitere Informationen zu verfügbaren Funktionen Siehe Aligner in der API-Referenz. Ein Teil des Aligners können die Daten mithilfe von Funktionen und konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine detaillierte Weitere Informationen zu Arten, Typen und Conversions

API

Sie konfigurieren den Ausrichtungszeitraum, indem Sie die Felder „aggregations.alignmentPeriod“ und „aggregations.perSeriesAligner“ in der MetricThreshold und MetricAbsence-Strukturen.

Weitere Informationen zu verfügbaren Funktionen Siehe Aligner in der API-Referenz. Ein Teil des Aligners können die Daten mithilfe von Funktionen und konvertieren sie von einer Messwertart oder einem Messwerttyp in eine andere. Eine detaillierte Weitere Informationen zu Arten, Typen und Conversions

Um die Auswirkungen des Ausrichtungszeitraums auf einen Zustand in einer Benachrichtigung zu veranschaulichen Bedingung für Messwertschwellen, Überwachen eines Messwerts mit einem Stichprobenzeitraum von einer Minute. Angenommen, der Ausrichtungszeitraum ist auf fünf Minuten festgelegt und ist der Aligner auf sum gesetzt. Außerdem wird davon ausgegangen, dass die Bedingung erfüllt ist. wenn der ausgerichtete Wert der Zeitreihe bei und dass die Bedingung jede Minute ausgewertet wird. In diesem Beispiel beträgt der Ausrichtungszeitraum zwei Minuten und das Fenster für die erneute Prüfung der im nächsten Abschnitt beschrieben wird, beträgt drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

Abbildung zur Veranschaulichung der Auswirkungen des Ausrichtungszeitraums auf das Fenster bzw. die Dauer der erneuten Prüfung.

Jede Zeile in der Abbildung stellt eine einzelne Bewertung der Bedingung dar. Die Zeitachsendaten werden angezeigt. Die Punkte im Ausrichtungszeitraum werden mit blaue Punkte; ältere Punkte sind schwarz. Jede Zeile enthält den ausgerichteten Wert und Gibt an, ob dieser Wert größer als der Grenzwert von zwei ist. Für die Zeile mit der Bezeichnung start wird als ausgerichteter Wert eins berechnet, was unter dem Grenzwert liegt. Bei der nächsten Bewertung beträgt die Summe der Stichproben im Ausrichtungszeitraum zwei. Bei der dritten Bewertung beträgt die Summe drei, und da dieser Wert größer als der Grenzwert ist, wird ein Timer für das Fenster für die erneute Prüfung gestartet.

Fenster noch einmal testen

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

  • Bedingungen für Messwertschwellen sind erfüllt, wenn für eine einzelner Zeitreihe, bei der jede ausgerichtete Messung in einem 15-Minuten-Intervall gegen um den Grenzwert zu erreichen.
  • Bedingungen für fehlende Messwerte sind erfüllt, wenn für keine Daten eintreffen. eine Zeitachse im 15-Minuten-Intervall.
  • Die Prognosebedingungen sind erfüllt, wenn jede Prognose erzeugt wurde während In einem 15-Minuten-Zeitfenster wird vorhergesagt, dass die Zeitreihe den Grenzwert überschreitet. innerhalb des Prognosefensters.

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

Google Cloud Console

Sie können das Fenster für die erneute Prüfung mithilfe des Felds Fenster für erneute Prüfung in der Schritt Benachrichtigungstrigger konfigurieren:

API

Sie konfigurieren das Fenster für die erneute Prüfung, indem Sie das Feld duration in MetricThreshold und MetricAbsence-Strukturen

In der Abbildung oben sind drei Auswertungen eines Messwertschwellenwerts dargestellt. . Im Zeit start + 2 minutes ist der ausgerichtete Wert größer als der Grenzwert. Die Bedingung ist jedoch nicht erfüllt, da das Fenster für die erneute Prüfung auf drei Minuten. Die folgende Abbildung zeigt die Ergebnisse für die nächste der Bedingung ausgewertet wird:

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

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

Eine Bedingung setzt das Fenster für den erneuten Test jedes Mal zurück, wenn eine Messung oder Prognose erfolgt die Bedingung nicht erfüllt. Dieses Verhalten wird im Folgenden veranschaulicht: Beispiel:

Beispiel: Diese Benachrichtigungsrichtlinie enthält eine Bedingung für einen Messwertschwellenwert, gibt ein fünfminütiges Fenster für den erneuten Test an.

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

Die folgende Reihenfolge zeigt, wie sich das Fenster für den erneuten Test auf den Bewertung der Bedingung:

  1. Die HTTP-Latenz beträgt weniger als zwei Sekunden.
  2. In den nächsten drei Minuten ist die HTTP-Latenz größer als zwei Sekunden.
  3. Bei der nächsten Messung beträgt die Latenz weniger als zwei Sekunden. wird das Fenster für die erneute Prüfung zurückgesetzt.
  4. In den nächsten fünf Minuten ist die HTTP-Latenz größer als zwei Sekunden, sodass die Bedingung erfüllt ist.

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

Das Fenster für den erneuten Test sollte lang genug sein, um falsch-positive Ergebnisse zu minimieren. um sicherzustellen, dass Vorfälle zeitnah geöffnet werden können.

Best Practices zum Festlegen des Ausrichtungszeitraums und des Zeitfensters für erneute Tests

Mit dem Ausrichtungszeitraum legen Sie fest, wie viele Stichproben mit dem Aligner kombiniert werden:

  • Der Mindestwert des Ausrichtungszeitraums für einen Messwerttyp ist der Wert Stichprobenzeitraum dieses Messwerttyps. Lautet der Messwerttyp beispielsweise wird alle 300 Sekunden eine Stichprobe erstellt, dann sollte der Ausrichtungszeitraum mindestens 300 Sekunden Wenn Sie jedoch fünf Stichproben kombinieren möchten, legen Sie den Parameter Ausrichtungszeitraum auf 5 × 300 Sekunden oder 1.500 Sekunden festlegen.

  • Der Maximalwert des Ausrichtungszeitraums beträgt 24 Stunden weniger als die Aufnahme Verzögerung des Messwerttyps. Wenn z. B. die Verzögerung bei der Aufnahme eines Messwerts beträgt 6 Stunden, ist der Maximalwert für den Ausrichtungszeitraum 18 Stunden.

Legen Sie im Fenster für den erneuten Test fest, wie schnell die Benachrichtigung ausgegeben werden soll. Beispiel: wenn Sie das Fenster für die erneute Prüfung auf 20 Minuten Bedingung für fehlende Messwerte darf es 20 Minuten lang keine Daten geben, bis die Bedingung erfüllt ist. Für eine reaktionsschnellere Benachrichtigungsrichtlinie bietet, stellen Sie einen kleineren Wert für das Fenster für den erneuten Test ein. Um die reaktionsschnellste Benachrichtigungsrichtlinie zu erhalten, Fenster für die erneute Prüfung auf null setzen. Ein einzelner ausgerichteter Wert führt zu diesen Arten von erfüllt sein müssen.

Bedingungen für Benachrichtigungsrichtlinien werden mit einer festen Häufigkeit ausgewertet. Die Entscheidungen, die den Sie für den Ausrichtungszeitraum vornehmen und das Fenster für den erneuten Test wie oft die Bedingung ausgewertet wird.

Richtlinien mit mehreren Bedingungen

Eine Benachrichtigungsrichtlinie kann bis zu sechs Bedingungen enthalten.

Wenn Sie die Cloud Monitoring API verwenden oder mehrere Bedingungen enthält, müssen Sie festlegen, wenn ein Vorfall geöffnet wird. Zum Konfigurieren mehrere Bedingungen kombinieren, führen Sie einen der folgenden Schritte aus:

Google Cloud Console

Sie konfigurieren Kombinatoroptionen im Schritt Trigger mit mehreren Bedingungen.

API

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

In dieser Tabelle sind die Einstellungen in der Google Cloud Console in der Cloud Monitoring API und eine Beschreibung jeder Einstellung:

Google Cloud Console
Richtlinie löst Wert aus
Cloud Monitoring API
Kombinationswert
Bedeutung
Eine beliebige Bedingung wird erfüllt OR Ein Vorfall wird geöffnet, wenn eine Ressource dazu führt, dass eine der Bedingungen erfüllt wird.
Alle Bedingungen werden erfüllt
, auch für verschiedene
Ressourcen pro Bedingung.

(Standard)
AND Ein Vorfall wird geöffnet, wenn beide Bedingung erfüllt ist, auch wenn verschiedene Ressource dazu, dass diese Bedingungen erfüllt sind.
Alle Bedingungen werden erfüllt AND_WITH_MATCHING_RESOURCE Ein Vorfall wird geöffnet, wenn nur eine Ressource alle Bedingungen erfüllt. Diese Einstellung ist die strengste Kombinationsoption.

In diesem Kontext bedeutet der Begriff met bedeutet, dass die Konfiguration der Bedingung als true ausgewertet wird. Für Wenn die Konfiguration beispielsweise Any time series is greater than 10 for 5 minutes, Wenn diese Anweisung true ergibt, ist die Bedingung erfüllt.

Beispiel

Nehmen wir als Beispiel ein Google Cloud-Projekt mit zwei VM-Instanzen, vm1 und vm2. Angenommen, Sie erstellen eine Benachrichtigungsrichtlinie mit zwei Bedingungen:

  • Die Bedingung mit dem Namen CPU usage is too high überwacht die CPU-Nutzung der Instanzen. Diese Bedingung ist erfüllt, wenn die CPU-Auslastung einer Instanz gleich über 100 ms/s für 1 Minute.
  • Die Bedingung namens Excessive utilization überwacht die CPU-Auslastung der Instanzen. Diese Bedingung ist erfüllt, wenn die CPU-Auslastung einer Instanz ist 1 Minute lang größer als 60 %.

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. Weil die CPU-Auslastung für eine Minute größer als der Grenzwert ist, CPU usage is too high ist erfüllt. Wenn die Bedingungen mit Beliebige Bedingung erfüllt kombiniert wird, wird ein Vorfall erstellt, da eine Bedingung erfüllt ist. Wenn die Bedingungen mit Alle Bedingungen sind erfüllt oder Alle Bedingungen werden auch bei verschiedenen Ressourcen für jede Bedingung erfüllt angezeigt werden, ist ein Vorfall nicht erstellt. Diese Kombinationsauswahl erfordert, dass beide Bedingungen erfüllt sind.

Nehmen wir als Nächstes an, dass die CPU-Auslastung von vm1 größer als 100 ms/s bleibt und dass die CPU-Auslastung von VM2 eine Minute lang 60% überschreitet. Dadurch werden beide Bedingungen erfüllt. Im Folgenden wird beschrieben, was je nach Kombination der Bedingungen geschieht:

  • Jede Bedingung wird erfüllt: Ein Vorfall wird erstellt, wenn eine Ressource dazu führt, dass eine Bedingung erfüllt wird. In diesem Beispiel führt vm2 die Bedingung Excessive utilization aus.

    Wenn vm2 die Bedingung CPU usage is too high erfüllt, dann die auch zu einem Vorfall führt. Ein Vorfall wird aus folgenden Gründen erstellt: vm1 und vm2, die zur Erfüllung der Bedingung CPU usage is too high führen sind unterschiedliche Ereignisse.

  • 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 eingehen oder Daten verspätet sind, Monitoring klassifiziert die Daten als fehlend. Fehlende Daten können verhindern, dass Vorfälle abgeschlossen werden. Verzögerungen bei der Dateneingabe aus Cloud-Drittanbieter bis zu 30 Minuten dauern, wobei am häufigsten Verspätungen von 5 bis 15 Minuten auftreten. Eine lange eine Verzögerung – länger als das Fenster für den erneuten Test – dazu führen kann, dass Bedingungen „Unbekannt“ Bundesstaat. Wenn die Daten schließlich eintreffen, haben möglicherweise einen Teil des Verlaufs der Erkrankungen 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 Messwertschwellenbedingung, wenn keine Daten eingehen. z. B. wenn ein Vorfall offen ist und eine erwartete Messung nicht ankommt, soll Monitoring den Vorfall öffnen oder sofort schließen? Ähnlich verhält es sich, wenn keine Daten eingehen kein Vorfall offen ist, soll ein Vorfall geöffnet werden? Und schließlich: Sollte ein Vorfall geöffnet bleiben, nachdem keine Daten eingehen?

Es gibt zwei konfigurierbare Felder, die festlegen, wertet Bedingungen für Messwertschwellen aus, wenn keine Daten eingehen:

  • So konfigurieren Sie, wie Monitoring den Ersatzwert bestimmt für fehlende Daten verwenden Sie das von Ihnen festgelegte Feld Auswertung fehlender Daten. im Schritt Bedingungstrigger aus. Dieses Feld ist deaktiviert, wenn die Fenster zum erneuten Testen ist auf Keine erneute Prüfung festgelegt.

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

  • So konfigurieren Sie, wie lange Monitoring wartet, bevor es geschlossen wird nach dem Eintreffen der Daten noch offen ist, verwenden Sie Dauer des automatischen Schließens eines Vorfalls. Die Dauer für das automatische Schließen legen Sie in der Benachrichtigung. Die Standarddauer für das automatische Schließen ist für 7 Tage.

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

Google Cloud Console
„Auswertung fehlender Daten“ Feld
Fazit Details
Fehlende Daten leer Offene Vorfälle bleiben offen.
Neue Vorfälle werden nicht geöffnet.

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen erreicht, startet der Timer für das automatische Schließen mit einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

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

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten eintreffen für die Dauer des automatischen Schließens plus 24 Stunden wenn der Vorfall geschlossen ist.

Unter Bedingungen, die nicht erfüllt sind, führt diese Einstellung dazu, dass Bedingung für Messwertschwelle so, dass sie sich wie ein metric-absence condition verhält. Wenn Daten nicht innerhalb der im Fenster für die erneute Prüfung festgelegten Zeit eintreffen, gilt die Bedingung als erfüllt. Für eine Benachrichtigungsrichtlinie mit eine Bedingung erfüllt, führt dazu, dass ein Vorfall geöffnet wird.

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

Wenn Bedingungen erfüllt sind, ist sie nicht mehr erfüllt, wenn Daten nicht mehr ankommen. Wenn ein Vorfall für diese Bedingung offen ist, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

API

Sie können konfigurieren, wie Monitoring eine Messwertschwellenbedingung, wenn keine Daten eingehen. z. B. wenn ein Vorfall offen ist und eine erwartete Messung nicht ankommt, soll Monitoring den Vorfall öffnen oder sofort schließen? Ähnlich verhält es sich, wenn keine Daten eingehen kein Vorfall offen ist, soll ein Vorfall geöffnet werden? Und schließlich: Sollte ein Vorfall geöffnet bleiben, nachdem keine Daten eingehen?

Es gibt zwei konfigurierbare Felder, die festlegen, wertet Bedingungen für Messwertschwellen aus, wenn keine Daten eingehen:

  • So konfigurieren Sie, wie Monitoring den Ersatzwert bestimmt für fehlende Daten: evaluationMissingData verwenden der MetricThreshold-Struktur fest. Dieses Feld wird ignoriert, wenn das Feld duration null ist.

  • So konfigurieren Sie, wie lange Monitoring wartet, bevor es geschlossen wird Für einen offenen Vorfall, nachdem keine Daten eingehen, verwenden Sie das Feld autoClose. in der AlertStrategy-Struktur.

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

API
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, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen erreicht, startet der Timer für das automatische Schließen mit einer Verzögerung von mindestens 15 Minuten. Wenn der Timer abläuft, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

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

Wenn Bedingungen erfüllt sind, ist die Bedingung weiterhin wenn keine Daten mehr eingehen. Wenn ein Vorfall für diese Bedingung offen ist, bleibt der Vorfall offen. Wenn ein Vorfall offen ist und keine Daten vorliegen für die Dauer der automatischen Schließen-Funktion plus 24 Stunden wenn der Vorfall geschlossen ist.

Unter Bedingungen, die nicht erfüllt sind, führt diese Einstellung dazu, dass Bedingung für Messwertschwelle so, dass sie sich wie ein metric-absence condition verhält. Wenn Daten nicht innerhalb der im Feld „Dauer“ angegebenen Zeit ankommen, gilt die Bedingung als erfüllt. Für eine Benachrichtigungsrichtlinie mit eine Bedingung erfüllt, führt dazu, dass ein Vorfall geöffnet wird.

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

Wenn Bedingungen erfüllt sind, ist sie nicht mehr erfüllt, wenn Daten nicht mehr ankommen. Wenn ein Vorfall für diese Bedingung offen ist, wird der Vorfall geschlossen.

Wenn Bedingungen nicht erfüllt sind, gilt dies weiterhin nicht wenn keine Daten eingehen.

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

  • Wenden Sie sich an Ihren Cloud-Drittanbieter, um Möglichkeiten zur Reduzierung Latenz bei der Messwerterfassung.
  • Verwenden Sie in den Bedingungen längere Zeitfenster für erneute Tests. Längeres Zeitfenster für erneute Tests verwenden hat den Nachteil, dass Ihre Benachrichtigungsrichtlinien weniger reaktionsschnell ist.
  • 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 ihre Daten direkt in Monitoring
    • Logbasierte Messwerte, wenn die Erfassung von Logeinträgen nicht verzögert wird

Weitere Informationen finden Sie unter Übersicht zum Monitoring-Agent Übersicht über benutzerdefinierte Messwerte und logbasierte Messwerte:

Wann sendet Monitoring Benachrichtigungen und erstellt Vorfälle?

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

Wenn Sie wiederholte Benachrichtigungen konfigurieren, gilt Folgendes: die gleiche Benachrichtigung an eine bestimmte für Ihre Benachrichtigungsrichtlinie.

Sie erhalten möglicherweise mehrere einzelne Benachrichtigungen zu eine Benachrichtigungsrichtlinie zu erhalten, Folgendes zutrifft:

  • Eine Bedingung überwacht mehrere Zeitreihen.

  • Eine Richtlinie enthält mehrere Bedingungen. In diesem Fall werden die Benachrichtigungen, empfangen, abhängig vom Wert der Mehrfachbedingung der Benachrichtigungsrichtlinie Trigger:

    • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, für jede Zeitreihe, bei der eine Bedingung erfüllt ist, sendet die Benachrichtigungsrichtlinie eine Benachrichtigung und erstellt einen Vorfall.

      Sie können Cloud Monitoring nicht so konfigurieren, dass nur ein Vorfall erstellt und nur eine Benachrichtigung senden, wenn die Benachrichtigungsrichtlinie mehrere conditions.

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

Sie werden auch bei Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt wurden, benachrichtigt wann die Bedingung erfüllt ist und wenn sie nicht mehr erfüllt wird. Benachrichtigungsrichtlinien, die mit der Google Cloud Console erstellt wurden, senden keine Benachrichtigung, wenn die Bedingung nicht mehr erfüllt ist, es sei denn, Sie haben dieses Verhaltens.

Wenn Monitoring keine Benachrichtigungen sendet oder keine Vorfälle erstellt

In den folgenden Situationen werden von Monitoring keine Vorfälle erstellt. oder Benachrichtigungen senden, wenn die Bedingungen einer Benachrichtigungsrichtlinie erfüllt sind:

  • Die Benachrichtigungsrichtlinie ist deaktiviert.
  • Die Benachrichtigungsrichtlinie ist zurückgestellt.
  • Monitoring hat das Limit für die maximale Anzahl von offenen Vorfälle.

Deaktivierte Benachrichtigungsrichtlinien

Beim Monitoring werden keine Erstellungs- oder Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Das Monitoring die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie weiter.

Wenn Sie eine deaktivierte Richtlinie aktivieren, wertet Monitoring die Werte aller Bedingungen im letzten Zeitraum für den erneuten Test. Das letzte Zeitfenster für die erneute Prüfung kann Daten enthalten, die vor, während und nach der Prüfung erfasst wurden. die Richtlinie aktiviert wurde. Die Bedingungen einer deaktivierten Richtlinie können sofort erfüllt werden wieder aktivieren, selbst bei großen Testfenstern.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie, die eine bestimmte und dass Sie diese Richtlinie deaktivieren. In der folgenden Woche wird der Prozess fällt aus. Da die Benachrichtigungsrichtlinie deaktiviert ist, werden Sie nicht benachrichtigt. Wenn Sie den Prozess neu starten und die Benachrichtigungsrichtlinie sofort aktivieren, Das Monitoring erkennt, dass der Prozess und erstellt einen Vorfall.

Die Vorfälle im Zusammenhang mit einer deaktivierten Benachrichtigungsrichtlinie bleiben so lange offen, bis der Richtlinie für das automatische Schließen abläuft.

Zurückgestellte Benachrichtigungsrichtlinien

Monitoring sendet keine Benachrichtigungen und erstellt keine Vorfälle für eine Benachrichtigungsrichtlinie, die zurückgestellt ist. Wir empfehlen die Schlummerfunktion. wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie nur kurze Benachrichtigungen erhalten. Bevor Sie beispielsweise Wartung einer virtuellen Maschine (VM) ausgeführt haben, können Sie eine Schlummerfunktion erstellen und die Schlummerkriterien für die Benachrichtigungsrichtlinien, die die Instanz überwachen.

Wenn Sie eine Benachrichtigungsrichtlinie zurückstellen, wird Monitoring geschlossen alle offenen Vorfälle im Zusammenhang mit der Richtlinie. Überwachung können nach Ablauf der Schlummerfunktion neue Vorfälle öffnen. Weitere Informationen finden Sie unter Benachrichtigungen deaktivieren

Einschränkungen bei Benachrichtigungen und offenen Vorfällen

Eine Benachrichtigungsrichtlinie kann für viele Ressourcen gelten und ein Problem alle Ressourcen dazu führen können, dass die Benachrichtigungsrichtlinie Vorfälle für jede . Für jede Zeitreihe, die zu einer Bedingung führt, wird ein Vorfall geöffnet erfüllt werden.

Um eine Überlastung des Systems zu vermeiden, gleichzeitig geöffnet werden kann,ist auf 1.000 begrenzt.

Stellen Sie sich beispielsweise eine Richtlinie vor, die für 2000 Compute Engine und jede Instanz führt dazu, dass die Bedingungen für Benachrichtigungen erfüllt sind. Monitoring begrenzt die Anzahl der offenen Vorfälle auf 1.000. Alle verbleibenden Bedingungen, die erfüllt sind, bis einige der offenen Vorfälle für diese Richtlinie geschlossen werden.

Aufgrund dieser Beschränkung kann ein einzelner Benachrichtigungskanal bis zu 1.000 Benachrichtigungen gleichzeitig. Wenn Ihre Benachrichtigungen hat die Richtlinie mehrere Benachrichtigungskanäle, dann gilt diese Beschränkung für jeden unabhängig vom Benachrichtigungskanal.

Latenz

Latenz bezieht sich auf die Verzögerung zwischen den Stichproben einer und wann der Messwertdatenpunkt als Zeitreihendaten sichtbar wird. Die Latenz wirkt sich darauf aus, wann Benachrichtigungen gesendet werden. Wenn z. B. eine überwachte eine Latenz von bis zu 180 Sekunden hat, Das Monitoring erstellt bis zu 180 Sekunden lang keinen Vorfall. wird die Bedingung der Benachrichtigungsrichtlinie als "true" ausgewertet. 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 erfassen können. Für Google Cloud-Werte sind die meisten Messwerte nicht nach der Erfassung 60 Sekunden lang sichtbar; Die Verzögerung hängt jedoch davon ab, auf den Messwert. Berechnung von Benachrichtigungsrichtlinien dauert eine zusätzliche Verzögerung zwischen 60 und 90 Sekunden. Bei AWS CloudWatch-Messwerten ist die Sichtbarkeitsverzögerung mehrere Minuten dauern. Bei Verfügbarkeitsdiagnosen kann dies durchschnittlich zwei Minuten (ab dem Ende des Zeitfensters für den erneuten Test).

  • Testfenster: Das für die Bedingung konfigurierte Fenster. Bedingungen sind nur dann erfüllt, wenn während des gesamten erneuten Tests eine Bedingung erfüllt ist . Eine von fünf Minuten festgelegte Zeit für die erneute Prüfung führt beispielsweise dazu, eine Verzögerung von mindestens fünf Minuten nach der Ereignis zuerst ein.

  • Zeit bis zum Eintreffen der Benachrichtigung: Benachrichtigungskanäle, z. B. E-Mail und SMS, können Netzwerk- oder andere Latenzen auftreten (unabhängig von geliefert wird). Manchmal dauert es nur wenige Minuten. Auf einigen Kanälen wie SMS und Slack kann nicht garantiert werden, dass die Nachrichten zugestellt werden.

Nächste Schritte