Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dépannage Metrics Insights

Les résultats incluent « Autre », mais je n'ai pas cela comme dimension

Cela signifie que la requête inclut une clause GROUP BY (REGROUPER PAR) qui spécifie une clé d'étiquette qui n'est pas utilisée dans certaines des métriques qui sont renvoyées par la requête. Dans ce cas, un groupe nul nommé Other est renvoyé. Les métriques qui n'incluent pas cette clé d'étiquette sont probablement des métriques agrégées qui renvoient des valeurs agrégées sur toutes les valeurs de cette clé d'étiquette.

Par exemple, supposons que nous ayons la requête suivante :

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

Si certaines des métriques renvoyées ne comprennent pas ServiceName en tant que dimension, alors ces métriques sont affichées comme ayant Other comme valeur pour ServiceName.

Pour éviter de voir « Autre » dans vos résultats, utilisez SCHEMA (SCHÉMA) dans votre clause FROM (À PARTIR DE), comme dans l'exemple suivant :

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

Cela limite les résultats renvoyés aux métriques qui ont à la fois les dimensions Operation et ServiceName.

L'horodatage le plus ancien de mon graphique a une valeur de métrique inférieure à celle des autres

CloudWatch Metrics Insights prend en charge jusqu'à deux semaines de données historiques. Lorsque vous effectuez un graphique avec une période supérieure à une minute, il peut arriver que le point de données le plus ancien diffère de la valeur attendue. Cela est dû au fait que les requêtes CloudWatch Metrics Insights renvoient uniquement des données pendant la période de conservation de deux semaines. Dans ce cas, le point de données le plus ancien de la requête renvoie uniquement les observations qui ont été mesurées dans la limite des deux semaines, au lieu de renvoyer toutes les observations dans la période de ce point de données.

Valeurs métriques incohérentes sur différentes périodes lors de l'utilisation de requêtes basées sur des balises

Lorsque vous utilisez des GROUP BY clauses WHERE ou comportant des balises dans des requêtes CloudWatch Metrics Insights, vous pouvez voir des valeurs métriques différentes en fonction de la période sélectionnée. Par exemple, une période de 6 heures peut afficher une valeur maximale de 20, tandis qu'une période d'une heure n'en affiche que 2 pour la même fenêtre horaire.

Cela se produit parce que les horodatages des balises sont stockés avec une résolution de second niveau, tandis que les points de données métriques sont alignés sur les limites des périodes (par exemple, le début de chaque minute ou heure). Pour déterminer quels points de données correspondent à une plage temporelle d'étiquette, CloudWatch ajuste le début de la plage en soustrayant un point. Avec des périodes plus longues, cet ajustement crée un écart plus important entre l'horodatage de l'étiquette et le premier point de données inclus, ce qui peut entraîner l'exclusion de points de données situés près du début de la plage.

L'exemple suivant montre comment cela affecte les résultats des requêtes. Une métrique possède deux valeurs de balise : env=beta (de 00:00 à 01:30) et env=gamma (de 01:30 à 03:00). Chaque balise couvre 90 minutes de données avec une somme de 270.

Sur une période d'une minute, le réglage de l'alignement est faible (1 minute), de sorte qu'un seul point de données supplémentaire est inclus par étiquette. Sur une période de 3 heures, l'ajustement couvre l'ensemble de la plage de requêtes :

Avec la période de 3 heures, les deux balises renvoient l'ensemble de données (SUM=540, SAMPLE_COUNT=180) car l'horodatage du point de données agrégé unique se situe dans les deux plages ajustées. La limite du tag est effectivement effacée.

Pour réduire l'impact de ce comportement, essayez les approches suivantes :