Tableaux de bord CloudWatch et Container Insights

Les tableaux de bord CloudWatch sont des vues personnalisables composées de plusieurs widgets de votre infrastructure AWS, qui fournissent une vision opérationnelle unifiée. Un tableau de bord peut afficher, sur un seul écran, des métriques provenant de plusieurs services et comptes AWS au moyen de graphiques linéaires, de widgets numériques, de jauges, d’alarmes et de résultats de requêtes de journaux. Les tableaux de bord sont des ressources globales : un même tableau de bord peut afficher les métriques de n’importe quelle Région. Vous pouvez partager les tableaux de bord publiquement ou en restreindre l’accès au moyen de politiques IAM.

Les tableaux de bord CloudWatch prennent en charge plusieurs types de widgets : des graphiques linéaires et en aires empilées pour les métriques de séries temporelles, des widgets numériques pour la dernière valeur d’une métrique (idéal pour les KPI), des graphiques à barres pour les comparaisons, des jauges pour les indicateurs de capacité, l’état des alarmes pour afficher un résumé de leurs états, des tableaux de journaux pour les résultats de Live Tail ou de requêtes Insights, ainsi que du texte pour les libellés et la documentation. La combinaison de plusieurs types de widgets dans un même tableau de bord aide les équipes à évaluer l’état du système en un coup d’œil.

CloudWatch prend en charge l’observabilité entre comptes au moyen de comptes de surveillance et de comptes sources. Vous pouvez désigner un compte de surveillance central, y associer des comptes sources et créer des tableaux de bord qui récupèrent les métriques et les journaux de tous les comptes associés. Il n’est ainsi plus nécessaire de changer de compte dans la console pour surveiller un environnement comprenant plusieurs comptes. Les widgets entre Régions au sein d’un même compte sont pris en charge nativement : il suffit de spécifier la Région dans la définition JSON du tableau de bord.

CloudWatch Live Tail (lancé en 2023) vous permet de diffuser les événements de journaux d’un ou plusieurs groupes de journaux presque en temps réel, directement dans la console CloudWatch ou la CLI — comme si vous exécutiez tail -f sur un fichier de journaux. Vous pouvez appliquer un modèle de filtre pour n’afficher que les événements correspondants. Live Tail est particulièrement utile pendant les déploiements ou les investigations d’incidents, lorsque vous devez observer immédiatement le comportement d’une application sans exécuter de requêtes Insights complètes.

CloudWatch Container Insights est une fonctionnalité de CloudWatch qui collecte, agrège et résume les métriques et les journaux des charges de travail conteneurisées exécutées sur Amazon ECS (EC2 et Fargate) et Amazon EKS (EC2 et Fargate). Elle fournit des tableaux de bord prédéfinis pour les performances au niveau du cluster, du service, du nœud et du pod, sans vous obliger à instrumenter manuellement chaque application. Container Insights utilise l’agent CloudWatch ou le routeur de journaux EKS Fargate pour collecter les données.

Container Insights collecte les métriques dans les espaces de noms ECS/ContainerInsights et ContainerInsights. Pour EKS, elles comprennent : au niveau du pod — pod_cpu_utilization, pod_memory_utilization, pod_network_rx_bytes ; au niveau du nœud — node_cpu_utilization, node_memory_utilization, node_filesystem_utilization ; au niveau du cluster — cluster_failed_node_count, cluster_node_count. Toutes les métriques sont étiquetées avec les dimensions du cluster, de l’espace de noms, du service et du pod afin de permettre un filtrage précis.

Lorsque Container Insights est activé, la console CloudWatch fournit automatiquement les vues prédéfinies Container Map et Performance Monitoring. Container Map affiche vos tâches ECS ou vos pods EKS sous la forme d’une topologie visuelle, dont les couleurs indiquent l’état de santé, avec la possibilité d’examiner les métriques de chaque conteneur. La vue Performance Monitoring fournit des graphiques de séries temporelles des performances du cluster, des nœuds, des pods et des conteneurs, sans aucune configuration manuelle de tableau de bord.

Pour ECS sur EC2, Container Insights installe l’agent CloudWatch en tant que service démon sur chaque instance de conteneur. Pour ECS sur Fargate, Container Insights utilise le collecteur de métriques secondaire de la version 1.4.0 de la plateforme Fargate. Vous accédez aux métriques ECS selon la dimension du cluster, du service, de la tâche ou du conteneur. Un modèle d’alerte courant consiste à déclencher une alarme lorsque MemoryUtilized s’approche de la valeur MemoryReserved de la tâche, afin de détecter d’éventuelles conditions OOM avant qu’elles n’entraînent l’arrêt des tâches.

CloudWatch ServiceLens intègre les métriques, les journaux et les traces dans une carte de services unifiée. Il nécessite l’activation de AWS X-Ray avec CloudWatch. ServiceLens visualise les flux de requêtes de bout en bout entre les services, met en évidence les goulots d’étranglement liés à la latence et affiche les taux d’erreur par service. CloudWatch Application Signals (son successeur plus récent) instrumente automatiquement les applications afin d’exposer les SLO et les SLI sans modification du code, ce qui permet de suivre la fiabilité au-delà des métriques brutes.

Les tableaux de bord CloudWatch efficaces suivent ces bonnes pratiques : séparez les tableaux de bord selon leur public (exploitation, direction ou développement), utilisez les widgets d’état des alarmes comme premier élément consulté par les équipes d’astreinte, épinglez les tableaux de bord pour y accéder fréquemment et utilisez les références dynamiques avec CloudFormation afin que les références aux métriques du tableau de bord restent cohérentes avec les noms réels des ressources. Évitez de surcharger un seul tableau de bord : la lisibilité est essentielle lorsque vous diagnostiquez un incident sous pression.

CloudWatch Contributor Insights analyse les données de journaux structurées afin d’identifier au fil du temps les N principaux contributeurs à une métrique. Par exemple, il peut indiquer quelles adresses IP génèrent le plus d’erreurs 5xx, quels chemins d’API enregistrent le plus grand volume de requêtes ou quels identifiants client provoquent le plus de limitations DynamoDB. Les règles définissent le champ JSON à extraire et sur lequel effectuer l’agrégation. Les résultats apparaissent sous forme de graphiques de séries temporelles qui se mettent continuellement à jour à mesure que de nouvelles données de journaux arrivent.

Testez votre compréhension des concepts d’architecte de solutions AWS (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les tableaux de bord CloudWatch prennent en charge plusieurs types de widgets et peuvent agréger des métriques entre comptes et Régions, que Container Insights collecte automatiquement les métriques au niveau des pods et des nœuds depuis ECS et EKS sans instrumentation manuelle, et que Contributor Insights identifie les principaux contributeurs à partir de données de journaux structurées. Nous allons maintenant découvrir les Trails CloudTrail et l’historique des événements pour l’audit au niveau des API.