Best Practices für MQL-Benachrichtigungsrichtlinien

Diese Seite enthält einen Index mit Best Practices für Benachrichtigungsrichtlinien mit einer MQL-basierten Bedingung (Monitoring Query Language). Sie können die hier erfassten Informationen als Kurzreferenz dafür verwenden, was beim Konfigurieren einer Benachrichtigungsrichtlinie mit einer MQL-basierten Bedingung zu beachten ist.

Auf dieser Seite werden die Grundlagen der Verwendung von MQL-Abfragen in Ihren Benachrichtigungsrichtlinien nicht beschrieben. Wenn Sie ein neuer Nutzer sind, lesen Sie den Abschnitt Benachrichtigungsrichtlinien mit MQL.

Die Auswertung der Benachrichtigungsrichtlinie umfasst mehrere interne Dienste. Aufgrund der Art und Weise, wie diese Dienste mit MQL interagieren, empfehlen wir dringend, bestimmte MQL-Vorgänge statt anderer zu verwenden. Wenn Sie beispielsweise delta anstelle von delta_gauge verwenden, werden Benachrichtigungen möglicherweise zu falschen Zeiten ausgelöst.

Die folgende Tabelle enthält eine Liste der Vorgänge, die Sie vermeiden sollten, und die empfohlenen Vorgänge, die stattdessen verwendet werden sollten.

Das sollten Sie vermeiden: Empfohlen
adjacent_rate rate
adjacent_delta delta_gauge
delta delta_gauge
window sliding

Anweisung every 30s mit Benachrichtigungsrichtlinien verwenden

Benachrichtigungsrichtlinien werten ihre Bedingung alle 30 Sekunden aus. Dieser Zeitraum wird als Ausgabefenster bezeichnet. Wir empfehlen, in den Bedingungen einen expliziten every 30s-Vorgang zu enthalten, um diesen Zeitraum visuell zu verdeutlichen.

Die folgende MQL-Abfrage der Benachrichtigungsrichtlinie enthält beispielsweise eine explizite every 30s-Anweisung:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

Wenn Sie eine Benachrichtigungsrichtlinie mit einer MQL-Abfrage speichern, die für den every-Vorgang einen anderen Wert verwendet, verwendet Cloud Monitoring auch bei aktiver Benachrichtigungsrichtlinie einen Wert von 30 Sekunden. Beispielsweise hat eine Benachrichtigungsrichtlinie mit der folgenden Abfrage immer noch ein Ausgabefenster von 30 Sekunden:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

Abfrageeffizienz verbessern

Abfragen werden bei der Verarbeitung großer Datenmengen langsam ausgeführt. Um die Effizienz von Abfragen zu verbessern, können Sie versuchen, die Datenmenge zu reduzieren, die durch die Abfrage verarbeitet wird. In den folgenden Abschnitten finden Sie verschiedene Optionen zum Reduzieren des durch die Abfrage ausgewerteten Datenvolumens.

Filter früher in der Abfrage platzieren

Wenn Sie Filter zu einem früheren Zeitpunkt in Ihrer Abfrage platzieren, können diese unnötigen Daten herausfiltern, bevor die Abfrage Vorgänge für Ihre Daten ausführt. Betrachten Sie beispielsweise die folgende Abfrage:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

Die Abfrage wird möglicherweise schneller ausgeführt, wenn Sie den filter-Vorgang vor dem group_by-Vorgang verschieben:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

Fenster für die Abfrageausrichtung verkleinern

Wenn eine Abfrage den Vorgang align verwendet, stellt ein kleineres Ausrichtungsfenster einen kürzeren Zeitraum dar, den Cloud Monitoring für jeden Punkt in der Zeitachse auswertet. Daher können Sie versuchen, die Abfrageeffizienz zu verbessern, indem Sie den Wert des align-Vorgangs reduzieren. Die folgende Abfrage hat beispielsweise ein zweistündiges Ausrichtungsfenster:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

Wenn Sie jedoch nur die Daten für ein einstündiges Fenster sehen müssen, können Sie das Ausrichtungsfenster auf eine Stunde verkürzen:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

Weitere Informationen finden Sie unter Ausrichtung.

Zeitfenster für die Dauer der Benachrichtigungsrichtlinie verkürzen

Das Fenster für die Dauer der Benachrichtigungsrichtlinie ist der Zeitraum, in dem jede Messung gegen die Bedingung verstoßen muss, bevor eine Benachrichtigung gesendet wird. Wenn Sie das Dauerfenster Ihrer Benachrichtigungsrichtlinie verkürzen, ohne das Fenster für die Abfrageausrichtung zu vergrößern, hat Cloud Monitoring weniger Punkte, die für die Bedingung der Benachrichtigungsrichtlinie ausgewertet werden müssen.

Weitere Informationen finden Sie unter Dauerfenster.

Null-Metadaten Standardwerte zuweisen

Wenn ein Metadatenwert null ist, können Ihre Abfragen zu unerwarteten Ergebnissen führen. Unerwartete Ergebnisse können Sie vermeiden, indem Sie Metadaten mit der Funktion or_else einen Standardwert zuweisen, der sonst einen Nullwert hätte.

Sie führen beispielsweise eine Abfrage aus, die alle Ihre Daten zusammenfasst:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Die Abfrage liefert ein Ergebnis von 10 MBy. Als Nächstes führen Sie eine Abfrage aus, um zu überprüfen, wie die 10 MBy auf Knotenzonen verteilt sind:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Die Verteilungsabfrage gibt die folgenden Ergebnisse zurück:

node_zone egress_byte_count
us-central1-f 7,3 MB
us-west1-b 2,5 MB

Diese Ergebnisse zeigen insgesamt 9,8 MBy und nicht die erwarteten 10 MBy. Diese Abweichung kann auftreten, wenn eines der aggregierten Metadatenlabels einen Nullwert hat, z. B. im folgenden Dataset:

Wert Metadatenwert
7,3 MB us-central1-f
2,5 MB us-west1-b
0,2 MB

Um Probleme durch Metadaten mit Null-Objekten zu vermeiden, können Sie Ihre Metadatenreferenz in einem or_else-Vorgang zusammenfassen. Dadurch können Sie einen Standardwert für den Fall angeben, dass eine Metadatenspalte keinen Wert hat. Die folgende Abfrage verwendet beispielsweise or_else, um für alle Metadatenspalten ohne Wert den Metadatenwert no zone festzulegen:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Diese neue Abfrage liefert die folgenden Ergebnisse, die summiert 10 MBy:

node_zone egress_byte_count
us-central1-f 7,3 MB
us-west1-b 2,5 MB
keine Zone 0,2 MB