Auf dieser Seite wird erläutert, warum sich einige Benachrichtigungsrichtlinien mit MQL-basierten Bedingungen (Monitoring Query Language) möglicherweise anders als beabsichtigt verhalten, und es werden mögliche Lösungen für diese Situationen angeboten.
Datenlücken
Sie haben eine Benachrichtigungsrichtlinie mit einer MQL-basierten Bedingung erstellt und die Ergebnisse der MQL-Abfrage weisen eine unerwartete Lücke in den gemeldeten Daten auf.
In ausgerichteten Daten treten Lücken auf, wenn eine Berechnung bei einem bestimmten Zeitstempel zu einem Nullwert führt. Beispielsweise bezieht sich die folgende Datentabelle auf eine Abfrage mit einem 30-Sekunden-Zeitraum:
Tabelle A1
Zeitstempel | Wert |
---|---|
00:00:00 | 1 |
00:00:30 | 2 |
00:01:30 | 3 |
00:02:00 | 4 |
Da Sie einen 30-Sekunden-Zeitraum haben, würden Sie erwarten, einen Zeitstempel bei 00:01:00 zu sehen. Für solche Lücken kann es viele Gründe geben.
Lücken aufgrund von Ausrichtungen
Zu schmale Aligner-Fenster können Datenlücken verursachen. Die folgende Tabelle mit nicht ausgerichteten Messwert-Rohdaten wird beispielsweise etwa alle 30 Sekunden geschrieben.
Tabelle B1
Zeitstempel | Wert |
---|---|
00:00:01 | 1 |
00:00:28 | 2 |
00:01:01 | 3 |
00:01:32 | 4 |
Wenn Sie um 00:02:00 eine Abfrage ausführen, die Ihre Daten mit einem next_older(30s)
-Vorgang ausrichtet, erhalten Sie die folgende Ausgabe, die eine Datenlücke bei 00:01:00 hat:
Tabelle B2
Zeitstempel | Wert |
---|---|
00:00:30 | 2 |
00:00:28 | 3 |
00:01:01 | 4 |
Diese Datenlücke tritt auf, weil kein Punkt in den Rohdaten in das 30-Sekunden-Fenster fällt, das um 00:01:00 endet. Um solche Lücken zu vermeiden, sollten Sie ein größeres Fenster verwenden.
Ein next_older(1m)
-Vorgang erzeugt beispielsweise eine Tabelle ohne Datenlücken:
Tabelle B3
Zeitstempel | Wert |
---|---|
00:00:01 | 1 |
00:00:28 | 2 |
00:01:01 | 3 |
00:01:32 | 4 |
Im Allgemeinen sollten Sie ein Ausrichtungsfenster verwenden, das größer als S ist, wenn Ihre Daten alle S Sekunden geschrieben werden. So können Sie eine ungleichmäßige Verteilung von Datenpunkten im Zeitverlauf berücksichtigen.
Lücken durch Tabellenvorgänge
Einige Tabellenvorgänge können zu unerwarteten Lücken führen. Beispielsweise erzeugt der join
-Vorgang nur bei Zeitstempeln eine Ausgabe, die in allen Eingabetabellen einen Wert haben.
Tabellenvorgänge wie join
können Lücken verursachen. Sie verknüpfen beispielsweise die folgenden beiden ausgerichteten Tabellen:
Tabelle C1
Zeitstempel | Wert |
---|---|
00:00:30 | 2 |
00:01:30 | 3 |
00:02:00 | 4 |
Tabelle C2
Zeitstempel | Wert |
---|---|
00:00:30 | 4 |
00:01:00 | 3 |
00:01:30 | 2 |
00:02:00 | 1 |
Sie erhalten dann die folgende Ausgabe:
Tabelle C3
Zeitstempel | Wert A | Wert B |
---|---|---|
00:00:30 | 1 | 4 |
00:01:30 | 2 | 2 |
00:02:00 | 3 | 1 |
Diese Tabelle hat für 00:01:00
keinen Wert, da in Tabelle C1 bei 00:01:00
kein Wert vorhanden ist.
Lücken aufgrund fehlender Werte
Einige Funktionen erzeugen Lücken, wenn ihre Ausgabe nicht konvertiert werden kann oder nicht definiert ist. Beispiel: Sie wenden value.string_to_int64
auf die folgende Tabelle mit Stringwerten an:
Tabelle D1
Zeitstempel | Wert |
---|---|
00:00:30 | „4“ |
00:01:00 | „3“ |
00:01:30 | „init“ |
00:02:00 | „1“ |
Die resultierende Tabelle enthält bei 00:01:30 eine Lücke, da MQL 'init'
nicht in eine Ganzzahl umwandeln kann:
Tabelle D2
Zeitstempel | Wert |
---|---|
00:00:30 | 4 |
00:01:00 | 3 |
00:01:30 | null |
00:02:00 | 1 |
Um Datenlücken aufgrund fehlerhafter oder fehlender Werte zu vermeiden, verwenden Sie die Funktionen has_value
oder or_else
, um diese Werte zu verarbeiten.
has_value
gibt false
zurück, wenn sein Argument null ergibt. Andernfalls wird true
zurückgegeben. Wenn Sie beispielsweise value has_value(1 / val())
auf Tabelle D2 anwenden, enthalten die Ergebnisse keine Lücken:
Tabelle D3
Zeitstempel | Wert |
---|---|
00:00:30 | wahr |
00:01:00 | wahr |
00:01:30 | false |
00:02:00 | wahr |
Schwellenwertbenachrichtigung wird ausgelöst, wenn im MQL-Diagramm angezeigt wird, dass der Grenzwert nicht überschritten wurde
Sie möchten benachrichtigt werden, wenn die CPU-Auslastung einer virtuellen Maschine (VM) stark schwankt. Daher erstellen Sie eine Benachrichtigungsrichtlinie, die den Messwert compute.googleapis.com/instance/cpu/utilization
überwacht. Sie erstellen und konfigurieren die Bedingung so, dass ein Vorfall generiert wird, wenn die CPU-Auslastung alle sechs Stunden über einem Grenzwert von 50 % liegt. Für die Bedingung wird die folgende Abfrage verwendet:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) | condition val() > 0.5
Sie erhalten nach 30 Sekunden eine Benachrichtigung. Ihr MQL-Diagramm zeigt jedoch, dass das Nutzungsdelta den Grenzwert nicht überschreitet.
Benachrichtigungsrichtlinien haben ein Ausgabefenster von 30 Sekunden. Dieser Zeitraum kann nicht überschrieben werden, indem Sie ihn undefiniert lassen oder in der Abfrage einen anderen Zeitraum definieren. Die folgenden Abfragen verwenden beispielsweise immer noch ein 30-sekündiges Ausgabefenster:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) # period not 30 seconds | condition val() > 0.5
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() # undefined period | condition val() > 0.5
Der Messwertschwellenwert wurde in den ersten 30 Sekunden der Auswertung überschritten. Daher hat Cloud Monitoring eine Benachrichtigung gesendet. Um dieses Problem zu vermeiden, fügen Sie | every 30s
am Ende der Abfrage ein, um zu prüfen, ob das Ausgabefenster die gewünschten Ergebnisse liefert. Beispiel:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() | every 30s # explicit 30 second output window | condition val() > 0.5
Fehler: Benachrichtigungsrichtlinie konnte nicht gespeichert werden. Die Anfrage enthält ein ungültiges Argument.
Sie haben eine Benachrichtigungsrichtlinie mit einer MQL-basierten Bedingung erstellt. Wenn Sie die Benachrichtigungsrichtlinie speichern, wird die folgende Fehlermeldung angezeigt:
Error: Unable to save alerting policy. Request contains an invalid argument.
Bei einigen MQL-Tabellenvorgängen wie group_by
müssen die Eingaben ausgerichtet werden. Wenn die Eingaben in der Abfrage nicht ausgerichtet werden, richtet MQL die Daten automatisch aus. Diese automatische Ausrichtung führt jedoch manchmal zu ungültigen Argumenten.
Wenn Ihre Abfrage einen Tabellenvorgang verwendet, muss die Abfrage eine Datenausrichtung enthalten, um dieses Problem zu vermeiden. Eine Liste der Datenausrichtungsfunktionen finden Sie in der MQL-Referenzdokumentation im Abschnitt Ausrichtung.
Die Grenzwertlinie wird im MQL-Diagramm nicht angezeigt
Sie haben eine Benachrichtigungsrichtlinie für Messwertschwellen mit einer MQL-basierten Bedingung erstellt. Die Linie für den Grenzwert wird jedoch nicht im MQL-Diagramm angezeigt.
Cloud Monitoring zeichnet die Schwellenwertlinie nur dann, wenn Ihre Abfrage einen booleschen Ausdruck enthält, der zwei Werte vergleicht, wobei ein Wert eine Spalte und ein Wert ein Literal ist. Der folgende Ausdruck stellt beispielsweise eine Schwellenwertlinie dar:
val() > 5'GBy'
Die folgenden Ausdrücke stellen jedoch keine Schwellenwertlinie dar:
val(0) > val(1) #one of the values must be a literal
5 > 4 #one of the values must be a column
val() #the expression must be a comparison