Verhalten von messwertbasierten Benachrichtigungsrichtlinien

In diesem Dokument wird beschrieben, wie anhand von Ausrichtungszeiträumen und Testwiederholungszeiträumen bestimmt wird, wann eine Bedingung erfüllt ist, wie in Benachrichtigungsrichtlinien mehrere Bedingungen kombiniert werden und wie in Benachrichtigungsrichtlinien fehlende Datenpunkte 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.

Ausrichtungszeiträume und Testzeiträume

Cloud Monitoring wertet den Ausrichtungszeitraum und das Testzeitfenster aus, um festzustellen, ob die Bedingung einer Benachrichtigungsrichtlinie erfüllt wurde.

Ausrichtungszeitraum

Bevor Zeitachsendaten von einer Benachrichtigungsrichtlinie überwacht werden, müssen sie regularisiert werden, damit die Benachrichtigungsrichtlinie regelmäßig verteilte Daten zur Auswertung hat. Der Regularisierungsprozess wird als Abgleich bezeichnet.

Die Ausrichtung umfasst zwei Schritte:

• Unterteilen der Zeitachsen in regelmäßige Zeitintervalle, auch Daten-Bucketing genannt. Das Intervall ist der Ausrichtungszeitraum.

• Einen einzelnen Wert für die Punkte im Ausrichtungszeitraum berechnen Sie können wählen, wie dieser einzelne Punkt berechnet werden soll. Sie können alle Werte summieren, ihren Durchschnitt berechnen oder das Maximum verwenden. Die Funktion, mit der die Datenpunkte kombiniert werden, wird als Aligner bezeichnet. Das Ergebnis der Kombination wird als abgestimmter Wert bezeichnet.

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

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

Mit „Monitoring“ wird ein Abgleichszeitraum so konfiguriert:

Zur Veranschaulichung der Auswirkungen eines Ausrichtungszeitraums auf eine Bedingung in einer Benachrichtigungsrichtlinie: Stellen Sie sich eine Messwertschwellenwertbedingung vor, die einen Messwert mit einem Stichprobenzeitraum von einer Minute überwacht. Angenommen, der Ausrichtungszeitraum ist auf 5 Minuten und der Aligner auf sum eingestellt. Nehmen wir außerdem an, dass die Bedingung erfüllt ist, wenn der ausgerichtete Wert der Zeitachse für mindestens drei Minuten größer als zwei ist und die Bedingung jede Minute ausgewertet wird. In diesem Beispiel beträgt das im nächsten Abschnitt beschriebene Zeitfenster für den erneuten Test drei Minuten. Die folgende Abbildung zeigt mehrere sequenzielle Bewertungen der Bedingung:

Jede Zeile in der Abbildung stellt eine einzelne Bewertung der Bedingung dar. Die Zeitachsendaten werden angezeigt. Die Punkte im Ausrichtungszeitraum werden mit blauen Punkten dargestellt, ältere Punkte sind schwarz. Jede Zeile zeigt den ausgerichteten Wert und gibt an, ob der Wert über dem Schwellenwert von zwei liegt. Für die Zeile mit dem Label start muss der ausgerichtete Wert 1 ergeben, also unter dem Schwellenwert liegen. Bei der nächsten Auswertung ergibt die Summe der Stichproben im Ausrichtungszeitraum 2. Bei der dritten Auswertung beträgt die Summe 3. Da dieser Wert größer als der Schwellenwert ist, wird ein Zeitgeber für das erneute Testen gestartet.

Zeitfenster noch einmal testen

Die Bedingung einer Benachrichtigungsrichtlinie hat ein Wiederholungsfenster, das verhindert, dass die Bedingung aufgrund einer einzelnen Messung oder Prognose erfüllt wird. Angenommen, das Testwiederholungsfenster einer Bedingung ist auf 15 Minuten festgelegt. Im Folgenden wird das Verhalten der Bedingung basierend auf ihrem Typ beschrieben:

• Bedingungen für Messwertschwellenwerte sind erfüllt, wenn für eine einzelne Zeitreihe jede ausgerichtete Messung in einem 15-Minuten-Intervall den Schwellenwert überschreitet.
• Bedingungen für fehlende Messwerte werden erfüllt, wenn innerhalb eines 15-Minuten-Intervalls keine Daten für eine Zeitachse eingehen.
• Die Prognosebedingungen sind erfüllt, wenn in jeder Prognose, die in einem 15‑Minuten-Zeitraum erstellt wird, vorhergesagt wird, dass die Zeitreihe den Grenzwert innerhalb des Prognosezeitraums überschreiten wird.

Bei Richtlinien mit einer Bedingung wird ein Vorfall erstellt und Benachrichtigungen werden gesendet, wenn die Bedingung erfüllt ist. Diese Vorfälle bleiben offen, solange die Bedingung weiterhin erfüllt ist.

Die vorherige Abbildung zeigt drei Auswertungen einer Bedingung mit Messwertschwellenwert. Zum Zeitpunkt start + 2 minutes liegt der ausgerichtete Wert über dem Schwellenwert. Diese Bedingung wird jedoch nicht erfüllt, da das Testwiederholungsfenster auf drei Minuten festgelegt ist. Die folgende Abbildung veranschaulicht die Ergebnisse für die nächsten Auswertungen der Bedingung:

Obwohl der ausgerichtete Wert zum Zeitpunkt start + 2 minutes über dem Schwellenwert liegt, wird die Bedingung erst erfüllt, wenn der ausgerichtete Wert drei Minuten lang über dem Schwellenwert liegt. Dieses Ereignis findet um start + 5 minutes statt.

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

Beispiel: Diese Benachrichtigungsrichtlinie enthält eine Bedingung für den Messwertschwellenwert, die ein erneutes Testfenster von fünf Minuten angibt.

Wenn die HTTP-Antwortlatenz länger als zwei Sekunden ist,
und wenn die Latenz fünf Minuten lang über diesem Grenzwert liegt,
sollten ein Vorfall erstellt und eine E-Mail an das Supportteam gesendet werden.

Die folgende Abfolge zeigt, wie sich das Retest-Fenster auf die Bewertung der Bedingung auswirkt:

1. Die HTTP-Latenz liegt unter zwei Sekunden.
2. In den nächsten drei Minuten liegt die HTTP-Latenz über zwei Sekunden.
3. Bei der nächsten Messung liegt die Latenz unter zwei Sekunden. Also setzt die Bedingung das Wiederholungsfenster zurück.

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 Testwiederholungsfenster 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 für die Festlegung des Abgleichszeitraums und des Testzeitraums

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

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

• Der maximale Wert des Ausrichtungszeitraums beträgt 24 Stunden abzüglich der Erfassungsverzögerung des Messwerttyps. Wenn die Erfassungsverzögerung für einen Messwert beispielsweise 6 Stunden beträgt, ist der Höchstwert des Ausrichtungszeitraums 18 Stunden.

Mit dem Testzeitraum können Sie die Reaktionsfähigkeit der Benachrichtigung festlegen. Wenn Sie beispielsweise das Testwiederholungsfenster 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 ist. Wenn Sie möchten, dass die Benachrichtigungsrichtlinie schneller reagiert, legen Sie für das Testwiederholungsfenster einen kleineren Wert fest. Damit die Benachrichtigungsrichtlinie für Messwertschwellenbedingungen möglichst schnell reagiert, setzen Sie das Testwiederholungsfenster auf null. Ein einzelner ausgerichteter Wert führt dazu, dass diese Arten von Bedingungen erfüllt werden.

Die Bedingungen für Benachrichtigungsrichtlinien werden in einem festen Intervall ausgewertet. Die Auswahl, die Sie für den Ausrichtungszeitraum und das Testwiederholungsfenster treffen, bestimmt nicht, 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. So konfigurieren Sie, wie mehrere Bedingungen kombiniert werden:

In dieser Tabelle werden die Einstellungen in der Google Cloud -Konsole, der entsprechende Wert in der Cloud Monitoring API und eine Beschreibung der einzelnen Einstellungen aufgeführt:

Google Cloud console Wert für Richtlinientrigger	Cloud Monitoring API Kombinationswert	Bedeutung
Eine beliebige Bedingung wird erfüllt	OR	Ein Vorfall wird geöffnet, wenn eine Ressource dazu führt, dass eine der Bedingungen erfüllt wird.
Alle Bedingungen werden erfüllt , auch für verschiedene Ressourcen pro Bedingung. (Standard)	AND	Ein Vorfall wird für jede Bedingung geöffnet, die erfüllt wird, wenn alle Bedingungen erfüllt sind, auch wenn eine andere Ressource dazu führt, dass diese Bedingungen erfüllt werden.
Alle Bedingungen werden erfüllt	AND_WITH_MATCHING_RESOURCE	Ein Vorfall wird für jede Bedingung geöffnet, die erfüllt wird, wenn alle Bedingungen erfüllt sind, aber 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 wahr ausgewertet wird. Beispiel: Wenn die Konfiguration Any time series is greater than 10 for 5 minutes lautet und die Anweisung wahr ergibt, wird die Bedingung erfüllt.

Beispiel

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

• Die Bedingung mit dem Namen CPU usage is too high überwacht die CPU-Nutzung der Instanzen. Diese Bedingung wird erfüllt, wenn die CPU-Nutzung einer Instanz 1 Minute lang über 100 ms/s liegt.
• Die Bedingung namens Excessive utilization überwacht die CPU-Auslastung der Instanzen. Diese Bedingung wird erfüllt, wenn die CPU-Auslastung einer Instanz 1 Minute lang über 60% liegt.

Gehen Sie erst einmal davon aus, dass beide Bedingungen falsch ergeben.

Nehmen wir als Nächstes an, dass die CPU-Auslastung von vm1 1 Minute lang 100 ms/s überschreitet. Da die CPU-Nutzung eine Minute lang über dem Schwellenwert liegt, wird 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 nun 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:

• 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, führt dies außerdem dazu, dass ein Vorfall erstellt wird. Ein Vorfall wird erstellt, weil die Erfüllung der Bedingung CPU usage is too high durch vm1 und die Erfüllung der Bedingung CPU usage is too high durch vm2 verschiedene 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 erstellt, da 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 Zeitreihendaten nicht mehr eingehen oder sich verzögern, werden sie von Monitoring als fehlend klassifiziert. Fehlende Daten können verhindern, dass Vorfälle geschlossen werden. Die Übermittlung der Daten von Cloud-Drittanbietern kann sich bis zu 30 Minuten verzögern. In der Regel beträgt die Verzögerung 5 bis 15 Minuten. Wenn eine Verzögerung länger als das Testfenster ist, können Bedingungen den Status „Unbekannt“ erhalten. Wenn die Daten schließlich eintreffen, kann Monitoring den jüngsten Verlauf der Bedingungen bereits verloren haben. Bei einer späteren Prüfung der Zeitachsendaten ist dieses Problem möglicherweise nicht erkennbar, weil es keinen Beleg für die Verzögerungen mehr gibt, sobald die Daten eingetroffen sind.

So können Sie Probleme aufgrund fehlender Daten minimieren:

• Wenden Sie sich an Ihren Clouddrittanbieter, um herauszufinden, wie sich die Latenz bei der Messwerterfassung verringern lässt.
• Verwenden Sie in Ihren Bedingungen längere Testzeiträume. Die Verwendung eines längeren Testzeitraums 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 Monitoring schreiben
  • Logbasierte Messwerte, wenn die Erfassung von Logeinträgen nicht verzögert ist

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

Wann Monitoring Benachrichtigungen sendet und Vorfälle erstellt

Cloud Monitoring sendet eine Benachrichtigung, wenn eine Zeitachse eine Bedingung erfüllt. Die Benachrichtigung wird an alle Benachrichtigungskanäle gesendet. Sie können eine Benachrichtigung nicht auf einen bestimmten Channel oder eine Teilmenge der Channels Ihrer Richtlinie beschränken.

Wenn Sie wiederholte Benachrichtigungen konfigurieren, wird dieselbe Benachrichtigung noch einmal an bestimmte Benachrichtigungskanäle für Ihre Benachrichtigungsrichtlinie gesendet.

Sie erhalten möglicherweise mehrere eindeutige Benachrichtigungen zu einer Benachrichtigungsrichtlinie, wenn eine der folgenden Bedingungen zutrifft:

• Eine Bedingung überwacht mehrere Zeitreihen.

• Eine Richtlinie enthält mehrere Bedingungen. In diesem Fall hängen die Benachrichtigungen, die Sie erhalten, vom Wert des Triggers mit mehreren Bedingungen der Benachrichtigungsrichtlinie ab:

  • Alle Bedingungen sind erfüllt: Wenn alle Bedingungen erfüllt sind, sendet die Benachrichtigungsrichtlinie für jede Zeitachse, die zu einer erfüllten Bedingung führt, eine Benachrichtigung und erstellt einen Vorfall.

    Sie können Cloud Monitoring nicht so konfigurieren, dass nur ein Vorfall erstellt und nur eine Benachrichtigung gesendet wird, wenn die Benachrichtigungsrichtlinie mehrere Bedingungen enthält.

  • Jede Bedingung wird erfüllt: Die Benachrichtigungsrichtlinie sendet eine Benachrichtigung, wenn eine Zeitachse dazu führt, dass die Bedingung erfüllt wird.

  Weitere Informationen finden Sie unter Richtlinien mit mehreren Bedingungen.

Bei Benachrichtigungsrichtlinien, die mit der Cloud Monitoring API erstellt wurden, werden Sie auch benachrichtigt, wenn die Bedingung erfüllt ist und wenn die Bedingung nicht mehr erfüllt wird. Bei Benachrichtigungsrichtlinien, die mit der Google Cloud Console erstellt wurden, wird keine Benachrichtigung gesendet, wenn die Bedingung nicht mehr erfüllt ist, es sei denn, Sie haben dieses Verhalten aktiviert.

Wenn Monitoring keine Benachrichtigungen sendet oder keine Vorfälle erstellt

In den folgenden Situationen werden in Monitoring keine Vorfälle erstellt und keine Benachrichtigungen gesendet, wenn die Bedingungen einer Benachrichtigungsrichtlinie erfüllt sind:

• Die Benachrichtigungsrichtlinie ist deaktiviert.
• Die Benachrichtigungsrichtlinie ist pausiert.
• Die Überwachung hat das Limit für die maximale Anzahl offener Vorfälle erreicht.

Deaktivierte Benachrichtigungsrichtlinien

Monitoring erstellt keine Vorfälle und sendet keine Benachrichtigungen für deaktivierte Benachrichtigungsrichtlinien. Monitoring wertet die Bedingungen einer deaktivierten Benachrichtigungsrichtlinie jedoch weiterhin aus.

Wenn Sie eine deaktivierte Richtlinie aktivieren, wertet Monitoring die Werte aller Bedingungen im letzten Retest-Zeitraum aus. Das letzte Fenster für den erneuten Test 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 Testzeiträumen.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie, mit der ein bestimmter Prozess überwacht wird, und Sie deaktivieren diese Richtlinie. In der folgenden Woche wird der Prozess beendet. 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 öffnet einen Vorfall.

Die Vorfälle, die sich auf eine deaktivierte Benachrichtigungsrichtlinie beziehen, bleiben offen, bis die automatische Schließungsdauer der Richtlinie abläuft.

Benachrichtigungsrichtlinien mit Schlummerfunktion

Monitoring sendet keine Benachrichtigungen und erstellt keine Vorfälle für eine Benachrichtigungsrichtlinie, die pausiert ist. Wir empfehlen, Benachrichtigungsrichtlinien zu pausieren, wenn Sie verhindern möchten, dass eine Benachrichtigungsrichtlinie nur für kurze Zeitintervalle Benachrichtigungen sendet. Bevor Sie beispielsweise Wartungsarbeiten an einer VM durchführen, können Sie einen Schlummerzeitraum erstellen und den Schlummerzeitraumkriterien die Benachrichtigungsrichtlinien hinzufügen, mit denen die Instanz überwacht wird.

Wenn Sie eine Benachrichtigungsrichtlinie in den Schlummermodus versetzen, schließt Monitoring alle offenen Vorfälle, die mit der Richtlinie zusammenhängen. Monitoring kann nach Ablauf der Pausierung neue Vorfälle erstellen. Weitere Informationen finden Sie unter Benachrichtigungen und Vorfälle stummschalten.

Einschränkungen bei Benachrichtigungen und offenen Vorfällen

Eine Benachrichtigungsrichtlinie kann für viele Ressourcen gelten. Ein Problem, das alle Ressourcen betrifft, kann dazu führen, dass die Benachrichtigungsrichtlinie Vorfälle für jede Ressource öffnet. Für jede Zeitachse, die eine Bedingung erfüllt, wird ein Vorfall geöffnet.

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

Beispiel: Eine Richtlinie wird auf 2.000 Compute Engine-Instanzen angewendet und jede Instanz führt dazu, dass die Benachrichtigungsbedingungen erfüllt werden. Durch die Überwachung wird die Anzahl der offenen Vorfälle auf 1.000 begrenzt. Alle verbleibenden erfüllten Bedingungen werden ignoriert, bis einige der offenen Vorfälle für diese Richtlinie behoben wurden.

Aufgrund dieses Limits kann ein einzelner Benachrichtigungskanal bis zu 1.000 Benachrichtigungen gleichzeitig empfangen. Wenn Ihre Benachrichtigungsrichtlinie mehrere Benachrichtigungskanäle hat, gilt dieses Limit unabhängig für jeden Benachrichtigungskanal.

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 Zeitachsendaten sichtbar wird. Die Latenz wirkt sich darauf aus, wann Benachrichtigungen gesendet werden. Wenn ein überwachter Messwert beispielsweise eine Latenz von bis zu 180 Sekunden hat, wird durch Monitoring erst nach bis zu 180 Sekunden ein Vorfall erstellt, nachdem die Bedingung der Benachrichtigungsrichtlinie als „wahr“ 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 zur Erfassung von Messwerten benötigt. Bei Google Cloud Werten sind die meisten Messwerte 60 Sekunden nach der Erfassung nicht sichtbar. Die Verzögerung hängt jedoch vom jeweiligen Messwert ab. Die Berechnung von Benachrichtigungsrichtlinien kann bis zu 5 Minuten und 30 Sekunden dauern. Bei AWS CloudWatch-Messwerten kann die Verzögerung aber mehrere Minuten betragen. Bei Verfügbarkeitsdiagnosen kann es im Durchschnitt zwei Minuten (ab dem Ende des Testzeitraums) dauern.

• Zeitfenster noch einmal testen: das für die Bedingung konfigurierte Zeitfenster. Bedingungen sind nur dann erfüllt, wenn dies während des gesamten Testzeitraums der Fall ist. Wenn Sie beispielsweise ein Zeitfenster für erneute Tests von fünf Minuten festlegen, wird die Benachrichtigung mindestens fünf Minuten nach dem ersten Ereignis verzögert.

• Zeit bis zum Eintreffen der Benachrichtigung: Auch innerhalb von Benachrichtigungskanälen wie E-Mail und SMS können unabhängig vom übermittelten Inhalt Netzwerk- oder sonstige Latenzen auftreten – manchmal in der Größenordnung von mehreren Minuten. Auf einigen Kanälen wie SMS und Slack kann nicht garantiert werden, dass die Nachrichten zugestellt werden.

Nächste Schritte

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

  • Benachrichtigungsrichtlinien mit Messwertschwellen 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.