Problembehebung bei Metrics Insights - Amazon CloudWatch

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehebung bei Metrics Insights

Die Ergebnisse beinhalten „Andere“, aber ich habe das nicht als Dimension

Dies bedeutet, dass die Abfrage eine GROUP BY-Klausel enthält, die einen Bezeichnungsschlüssel angibt, der in einigen der Metriken, die von der Abfrage zurückgegeben werden, nicht verwendet wird. In diesem Fall wird eine Nullgruppe mit dem Namen Other zurückgegeben. Die Metriken, die diesen Bezeichnungsschlüssel nicht enthalten, sind wahrscheinlich aggregierte Metriken, die Werte zurückgeben, die über alle Werte dieses Bezeichnungsschlüssels aggregiert sind.

Angenommen, wir haben die folgende Abfrage:

SELECT AVG(Faults) FROM MyCustomNamespace GROUP BY Operation, ServiceName

Wenn beispielsweise einige der zurückgegebenen Metriken ServiceName nicht als Dimension enthalten, werden diese Metriken so angezeigt, als hätte sie Other als Wert für ServiceName.

Um zu verhindern, dass „Andere“ in Ihren Ergebnissen angezeigt wird, verwenden Sie SCHEMA in Ihrer FROM-Klausel, wie im folgenden Beispiel dargestellt:

SELECT AVG(Faults) FROM SCHEMA(MyCustomNamespace, Operation) GROUP BY Operation, ServiceName

Dies beschränkt die zurückgegebenen Ergebnisse nur auf die Metriken, die über die Dimensionen Operation und ServiceName verfügen.

Der älteste Zeitstempel in meinem Diagramm hat einen niedrigeren Metrikwert als die anderen

CloudWatch Metrics Insights unterstützt historische Daten für bis zu zwei Wochen. Wenn Sie ein Diagramm mit einer Periode von mehr als einer Minute erstellen, kann es Fälle geben, in denen der älteste Datenpunkt vom erwarteten Wert abweicht. Dies liegt daran, dass die CloudWatch Metrics Insights-Abfragen nur Daten innerhalb der zweiwöchigen Aufbewahrungsfrist zurückgeben. In diesem Fall gibt der älteste Datenpunkt in der Abfrage nur die Beobachtungen zurück, die in diesem zweiwöchigen Zeitraum gemessen wurden, anstatt alle Beobachtungen innerhalb des Zeitraums dieses Datenpunkts zurückzugeben.

Inkonsistente Metrikwerte über verschiedene Zeiträume hinweg bei der Verwendung von tagbasierten Abfragen

Wenn Sie WHERE GROUP BY OR-Klauseln mit Tags in CloudWatch Metrics Insights-Abfragen verwenden, werden Ihnen je nach ausgewähltem Zeitraum möglicherweise unterschiedliche Metrikwerte angezeigt. Beispielsweise kann in einem Zeitraum von 6 Stunden ein Spitzenwert von 20 angezeigt werden, während in einem Zeitraum von 1 Stunde nur 2 für dasselbe Zeitfenster angezeigt werden.

Dies liegt daran, dass Tag-Zeitstempel mit einer Auflösung der zweiten Ebene gespeichert werden, während metrische Datenpunkte an Periodengrenzen ausgerichtet sind (z. B. dem Beginn jeder Minute oder Stunde). Um zu ermitteln, welche Datenpunkte einem Tag-Zeitbereich entsprechen, CloudWatch passt der Anfang des Bereichs an, indem eine Periode subtrahiert wird. Bei größeren Zeiträumen entsteht durch diese Anpassung eine größere Lücke zwischen dem Tag-Zeitstempel und dem frühesten eingeschlossenen Datenpunkt, was dazu führen kann, dass Datenpunkte, die sich am Anfang des Bereichs befinden, ausgeschlossen werden.

Das folgende Beispiel zeigt, wie sich dies auf die Abfrageergebnisse auswirkt. Eine Metrik hat zwei Tag-Werte: env=beta (von 00:00 bis 01:30) und env=gamma (von 01:30 bis 03:00). Jedes Tag deckt 90 Minuten an Daten mit einer SUMME von 270 ab.

Zwei CloudWatch Metrikdiagramme, in denen Tag-basierte Abfrageergebnisse mit Zeiträumen von 1 Minute und 3 Stunden verglichen werden.
env=beta mit einem Zeitraum von 1 Minute
Statistik Expected Ist zurückgekehrt Unterschied
SUM270271+1
AVG3.03.00
MIN110
MAX550
ANZAHL DER STICHPROBEN9091+1
env=gamma mit einem Zeitraum von 1 Minute
Statistik Expected Ist zurückgekehrt Unterschied
SUM2702755+
AVG3.03.00
MIN110
MAX550
ANZAHL DER STICHPROBEN9091+1

Bei einem Zeitraum von 1 Minute ist die Anpassung der Ausrichtung gering (1 Minute), sodass nur 1 zusätzlicher Datenpunkt pro Tag enthalten ist. Bei einem Zeitraum von 3 Stunden erstreckt sich die Anpassung über den gesamten Abfragebereich:

env=beta mit einem Zeitraum von 3 Stunden
Statistik Expected Ist zurückgekehrt Unterschied
SUM270540+270
AVG3.03.00
MIN110
MAX550
ANZAHL DER STICHPROBEN90180+90
env=gamma mit einem Zeitraum von 3 Stunden
Statistik Expected Ist zurückgekehrt Unterschied
SUM270540+270
AVG3.03.00
MIN110
MAX550
ANZAHL DER STICHPROBEN90180+90

Bei einem Zeitraum von 3 Stunden geben beide Tags den gesamten Datensatz zurück (SUM=540, SAMPLE_COUNT=180), da der Zeitstempel des einzelnen aggregierten Datenpunkts in beide angepassten Bereiche fällt. Die Tag-Grenze wird effektiv gelöscht.

Um die Auswirkungen dieses Verhaltens zu verringern, probieren Sie die folgenden Ansätze aus:

  • Verwenden Sie kleinere Aggregationsperioden. Kleinere Zeiträume (z. B. 1 Minute oder 5 Minuten) entsprechen eher der Auflösung von Tag-Zeitstempeln auf zweiter Ebene, wodurch die Ausrichtungslücke minimiert und die Wahrscheinlichkeit erhöht wird, dass alle relevanten Datenpunkte enthalten sind.

  • Verwenden Sie dimensionsbasierte Filterung anstelle von Tags. Wenn Ihr Anwendungsfall dies zulässt, filtern Sie nach Dimensionen und nicht nach Tags. Dimensionsbasierte Abfragen sind von diesem Verhalten nicht betroffen. Verwenden Sie z. B. WHERE InstanceId = 'i-1234567890abcdef0' statt WHERE tag."my-tag" = 'my-value'.

  • Abfragen mit einer konsistenten Granularität. Verwenden Sie beim Vergleich von Metrikdaten in verschiedenen Zeitfenstern denselben Zeitraum, um unerwartete Unterschiede zu vermeiden, die durch die Anpassung der Ausrichtung verursacht werden.