Fondamentaux des métriques CloudWatch

Une alerte tombe à 09h14 : l'API de checkout part en timeout. Vous ouvrez la console EC2, vous regardez l'instance, et vous voyez le CPU à 22 %. Rien d'anormal. Rien d'anormal parce que l'instance a saturé sa mémoire, et que CloudWatch n'a aucune métrique de mémoire pour EC2 tant que vous ne l'y mettez pas vous-même.

Chaque leçon de ce cours finit par lire un chiffre dans CloudWatch. Avant de faire confiance à ces chiffres, vous devez savoir comment CloudWatch les range : ce qui distingue une métrique d'une autre, à quelle fréquence les valeurs arrivent, combien de temps elles survivent, et quelle statistique répond à quelle question. Ratez cette couche et tout ce qui repose dessus, alarmes, politiques de scaling, tableaux de bord, vous donnera des réponses très sûres à la mauvaise question.

L'adresse d'une métrique

Une métrique est une suite de points de données ordonnée dans le temps. Chaque point a une valeur, un timestamp et, en option, une unité. Prise isolément, ce n'est qu'une liste de nombres : CloudWatch a donc besoin d'un moyen de distinguer une liste d'une autre.

Trois éléments composent cette adresse :

• Namespace : le conteneur. Les services AWS suivent le motif AWS/service, donc les métriques EC2 vivent dans AWS/EC2, celles de Lambda dans AWS/Lambda. Il n'existe aucun namespace par défaut, et vous devez en nommer un pour chaque point publié.
• Nom de la métrique : CPUUtilization, Invocations, FreeStorageSpace.
• Dimensions : zéro ou plusieurs paires nom/valeur, comme InstanceId=i-0a1b2c3d. Une métrique en accepte jusqu'à 30.

Les namespaces isolent. Des métriques de namespaces différents ne sont jamais agrégées ensemble, et c'est pour cela qu'une métrique applicative nommée Errors ne contaminera pas le Errors de Lambda. Une métrique n'existe aussi que dans la Région où elle a été créée. Un tableau de bord dans eu-west-1 ne trouvera pas une métrique publiée dans us-east-1, sauf si vous construisez délibérément une vue cross-Region.

Les dimensions font partie de l'identité, pas du filtrage

C'est le point qui piège tout le monde, alors travaillons-le avec des valeurs réelles.

Supposons que vous publiez quatre points de données dans un namespace Checkout, tous avec le nom de métrique OrdersProcessed :

Dimensions: Service=api,    Stage=prod  Valeur: 105
Dimensions: Service=api,    Stage=beta  Valeur: 115
Dimensions: Service=worker, Stage=prod  Valeur: 95
Dimensions: Service=worker, Stage=beta  Valeur: 97

Vous pouvez récupérer des statistiques pour exactement ces quatre combinaisons. Vous ne pouvez pas récupérer Service=api seul, ni Stage=prod seul, parce que vous n'avez jamais publié de point avec ces seules dimensions. La requête ne renvoie rien du tout, ce qui se lit sur un tableau de bord comme « la métrique est cassée » alors que cela signifie « cette métrique n'a jamais existé ».

L'idée fausse à nommer tout de suite : les dimensions ressemblent à des filtres sur une grande table, donc les gens attendent que Stage=prod découpe la donnée. Ce ne sont pas des filtres. CloudWatch traite chaque combinaison unique de dimensions comme une métrique à part entière. Ajouter une nouvelle valeur de dimension crée une nouvelle variante de la métrique, pas une ligne de plus dans l'ancienne.

Une exception rend la confusion pire encore. Pour les métriques de certains services AWS, dont EC2, CloudWatch agrège bien entre dimensions : cherchez CPUUtilization dans AWS/EC2 sans préciser de dimension et vous obtenez une moyenne sur vos instances. CloudWatch ne le fait jamais pour les métriques personnalisées. Le comportement que vous apprenez en cliquant dans les graphiques EC2 est donc exactement celui qui ne se produira pas sur les métriques publiées par votre propre code.

Si vous voulez à la fois un total et une vue par instance sur une métrique personnalisée, publiez les deux : un point avec le jeu de dimensions complet, et un autre avec les seules dimensions sur lesquelles vous voulez le cumul.

La résolution : à quelle fréquence un chiffre arrive

Chaque métrique relève de l'une des deux résolutions.

La résolution standard a une granularité d'une minute. Tout ce que publient les services AWS est en résolution standard.

La haute résolution stocke la donnée à la seconde et n'existe que pour les métriques personnalisées que vous publiez. Vous pouvez ensuite la relire avec une période de 1, 5, 10 ou 30 secondes, ou n'importe quel multiple de 60.

Une période est la durée couverte par une statistique. Les valeurs valides sont 1, 5, 10, 30, ou tout multiple de 60 secondes, et la valeur par défaut est 60. Une donnée agrégée porte le timestamp du début de sa période : une donnée couvrant 19h00 à 20h00 est estampillée 19h00.

La haute résolution coûte plus cher à deux endroits. Chaque appel PutMetricData est facturé, donc publier toutes les secondes multiplie cette charge, et une alarme haute résolution avec une période de 10 ou 30 secondes est facturée plus cher qu'une alarme normale. Sortez cette option quand vous avez vraiment besoin d'un temps de réaction sous la minute, pas par défaut.

Monitoring basique et détaillé sur EC2

EC2 publie gratuitement un jeu fixe de métriques toutes les 5 minutes : CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes et quelques autres. C'est le monitoring basique, actif par défaut.

Le monitoring détaillé est une option payante par instance qui fait passer l'intervalle à 1 minute. Mêmes métriques, cinq fois plus de résolution.

aws ec2 monitor-instances --instance-ids i-0a1b2c3d4e5f67890

Aucun des deux réglages n'ajoute l'utilisation mémoire ni l'occupation des systèmes de fichiers. Ces chiffres vivent à l'intérieur du système d'exploitation invité, et l'hyperviseur qui publie les métriques EC2 ne peut pas voir dedans. Les collecter demande l'agent CloudWatch, sujet d'une leçon suivante dans ce sujet.

La conséquence testée à l'examen : la période d'une alarme doit être au moins aussi longue que la résolution de la métrique. Posez une période de 60 secondes sur une métrique en monitoring basique et quatre périodes sur cinq ne contiennent aucune donnée, donc l'alarme se gare en INSUFFICIENT_DATA et ne vous dira jamais rien. Passez à 300 secondes ou activez le monitoring détaillé.

La rétention : vos données vieillissent en paliers plus grossiers

CloudWatch ne garde pas vos données à la minute pour toujours, et il ne les jette pas non plus. Il les agrège.

Suivez un point publié aujourd'hui à la résolution d'une minute. Pendant 15 jours, vous le tracez minute par minute. Au 16e jour, le détail à la minute a disparu, mais la donnée existe toujours sous forme d'agrégats à 5 minutes, et le reste jusqu'au 63e jour. Ensuite seul le cumul horaire survit, pour un total de 455 jours.

Deux conséquences qui apparaissent dans de vrais incidents. D'abord, un post-mortem rédigé trois semaines après les faits ne peut pas montrer la minute exacte où un pic a commencé, seulement le seau de 5 minutes dans lequel il tombe. Si le détail à la minute compte pour la conformité ou l'analyse, exportez-le ou envoyez-le vers un stockage durable tant qu'il existe encore. Ensuite, une métrique qui cesse de recevoir des données disparaît de la recherche dans la console au bout de deux semaines, alors que get-metric-data peut toujours la renvoyer. Une métrique que personne ne trouve dans la console n'est pas une métrique supprimée.

Les métriques ne peuvent pas être supprimées du tout. Elles expirent seules après 15 mois sans nouvelle donnée. Une dimension mal choisie, un identifiant d'instance figé dans un nom de métrique ou un namespace parasite sont donc des choses avec lesquelles vous vivez, pas des choses que vous nettoyez.

Les statistiques : mêmes données, récits différents

Une statistique est une agrégation sur une période. Le choix change la réponse.

• Average lisse. Bon pour les tendances de capacité, mauvais pour trouver l'instance en difficulté, parce qu'une moyenne de flotte à 40 % masque l'instance à 99 %.
• Maximum fait l'inverse. Un seul pic anormal fixe le plafond du graphique et fait passer un système sain pour malade.
• Sum convient aux compteurs. Erreurs, invocations, nombre de requêtes : la question est « combien », pas « quelle taille ».
• SampleCount indique combien de points sont entrés dans la période, et c'est ainsi que vous remarquez qu'une métrique a cessé de remonter en silence.
• Les percentiles se situent entre Average et Maximum. p95 est la valeur sous laquelle tombent 95 % de vos données, donc elle montre une charge élevée durable en ignorant l'anomalie occasionnelle. Vous pouvez préciser jusqu'à dix décimales, comme dans p95.0123456789.

Les percentiles ont leurs conditions. CloudWatch a besoin des points de données bruts, non résumés, pour les calculer : si vous avez publié un statistic set pré-agrégé, les percentiles sont en général indisponibles. Ils ne fonctionnent pas non plus sur des métriques à valeurs négatives. Parmi les services qui gèrent les statistiques de percentile : API Gateway, Application Load Balancer, EC2, ELB, Kinesis, Lambda et RDS.

Un choix concret : pour « ma latence est-elle acceptable pour la plupart des utilisateurs », prenez p95 sur Duration. Pour « est-ce que quelque chose a cassé », prenez Sum sur Errors. Pour « suis-je proche d'une limite de concurrence », prenez Maximum sur ConcurrentExecutions.

Publier vos propres métriques

Tout ce que CloudWatch ne mesure pas pour vous, vous pouvez le publier vous-même avec PutMetricData.

aws cloudwatch put-metric-data \
  --namespace Checkout \
  --metric-name QueueDepth \
  --dimensions Service=worker,Stage=prod \
  --value 47 \
  --unit Count

Trois détails décident si cela fonctionne en production.

Les timestamps. Un point de données peut être daté jusqu'à deux semaines dans le passé et jusqu'à deux heures dans le futur. Sans timestamp, CloudWatch l'estampille à l'arrivée. Les alarmes évaluent par rapport à l'heure UTC courante, donc une métrique qui arrive avec une horloge décalée atterrit dans des périodes que l'alarme a déjà évaluées. Le symptôme est une alarme bloquée en INSUFFICIENT_DATA ou qui se déclenche longtemps après l'événement, pas une erreur d'API, ce qui rend le décalage d'horloge vraiment difficile à repérer.

Le volume. Chaque appel PutMetricData est facturé. S'il vous faut beaucoup d'échantillons par minute, publiez plutôt un statistic set : vous donnez à CloudWatch le Min, le Max, la Sum et le SampleCount d'un lot d'observations en un seul appel. Le compromis, c'est la perte des statistiques de percentile, puisque les points bruts ont disparu.

Même identité, plusieurs sources. CloudWatch ne se soucie pas de savoir quel hôte a envoyé un point. Vingt serveurs web publiant vers les mêmes namespace, nom de métrique et dimensions produisent une seule métrique qui les décrit tous. C'est souvent exactement ce que vous voulez pour une latence au niveau de la flotte.

Pour les applications qui écrivent déjà des logs structurés, l'embedded metric format (EMF) mérite d'être connu : vous écrivez un événement de log JSON à la structure particulière dans CloudWatch Logs, et CloudWatch en extrait des métriques automatiquement. Container Insights et Lambda Insights fonctionnent tous les deux ainsi, comme vous le verrez plus loin dans ce sujet.

Conseils pour l'examen

• « Utilisation mémoire » et « espace disque occupé sur le système de fichiers » pointent toujours vers l'agent CloudWatch, jamais vers le monitoring basique ou détaillé. Le monitoring détaillé change la fréquence, pas la couverture.
• Le monitoring basique, c'est 5 minutes, le détaillé 1 minute. Une alarme en INSUFFICIENT_DATA avec une période de 60 secondes sur une métrique EC2 est le piège classique du monitoring basique.
• Une requête qui ne renvoie rien pour un jeu partiel de dimensions n'est pas un bug. Vérifiez si cette combinaison exacte a déjà été publiée, et souvenez-vous que les métriques personnalisées n'agrègent jamais entre dimensions.
• Haute résolution veut dire 1 seconde, et cela ne concerne que les métriques personnalisées. Les alarmes haute résolution acceptent des périodes de 10 ou 30 secondes et coûtent plus cher.
• Retenez l'échelle de rétention : 3 heures, 15 jours, 63 jours, 455 jours. Les questions la formulent comme « peut-on encore voir le détail à la minute d'il y a trois mois », et la réponse est non, seulement le cumul horaire.
• Si une question oppose masquer les valeurs extrêmes et se faire dominer par elles, la réponse attendue est un percentile.

La règle à emporter : une métrique se définit par son namespace, son nom et son jeu exact de dimensions, et tout le reste, résolution, rétention, statistiques, découle de la façon dont elle a été publiée. Vous allez maintenant passer des chiffres au texte, là où se trouve la preuve brute : CloudWatch Logs, et le langage de requête qui transforme un million de lignes en une réponse.