Métriques et logs CloudWatch

Chaque autre sujet de ce cours finit par lire un chiffre ou une ligne de log dans CloudWatch. Une politique de scaling a besoin d'une métrique. Un runbook de remédiation a besoin d'un événement. Une optimisation de performance a besoin d'une preuve qu'elle a fonctionné. Ce sujet construit cette fondation : ce qu'AWS mesure pour vous, ce que vous devez instrumenter vous-même, et comment en tirer une réponse rapidement.

Il trace aussi la ligne sur laquelle beaucoup de questions d'examen se jouent. CloudWatch enregistre ce que font vos ressources. CloudTrail enregistre qui leur a demandé de le faire. Les deux sont ici, parce qu'un incident a généralement besoin des deux.

Ce que couvre ce sujet

• L'identité et le stockage d'une métrique : namespaces, dimensions, résolution, statistiques et percentiles, et le rollup de rétention qui décide de ce que vous pourrez encore interroger des mois plus tard
• La structure et la rétention de CloudWatch Logs, plus les trois façons de rendre les logs utiles : metric filters, subscription filters et requêtes Logs Insights
• Le déploiement de l'agent CloudWatch unifié sur une flotte avec Systems Manager et Parameter Store, et la frontière IAM entre la server policy et l'admin policy
• CloudTrail pour les opérations : event history contre trails, les quatre types d'événements, les trails d'organisation, CloudTrail Lake et l'alarme sur l'activité du compte
• La télémétrie de conteneurs avec Container Insights sur ECS et EKS, et les cas où Amazon Managed Service for Prometheus avec Amazon Managed Grafana convient mieux
• La supervision du serverless et de l'IA : métriques Lambda et le piège throttle contre erreur, Lambda Insights, X-Ray, la décomposition de la latence API Gateway et le suivi de l'usage d'Amazon Bedrock

Pourquoi c'est important

Les questions de cette partie de l'examen sont diagnostiques plutôt que définitionnelles. On vous donne un symptôme (une alarme bloquée en INSUFFICIENT_DATA, une instance EC2 sans métrique de mémoire, une fonction Lambda dont les logs n'apparaissent jamais, un taux d'erreur qui semble sain pendant que les utilisateurs signalent des échecs) et on vous demande quoi vérifier. Reconnaître des noms de services ne vous mènera pas là.

Ce qui vous y mène, c'est de savoir quelles métriques AWS publie par défaut, lesquelles exigent un agent, quelles fonctionnalités restent éteintes tant que personne ne les allume, et combien de temps chaque type de donnée survit. Cette connaissance est aussi le cœur du quotidien d'un ingénieur CloudOps, et elle se prolonge directement dans les alarmes, l'auto scaling et la remédiation automatique des sujets suivants.