Amazon DVA-C02: Surveillance, Journalisation et Débogage (CloudWatch, X-Ray, Traçage, Alarmes) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Journaux, métriques et filtres de métriques de journal CloudWatch

CloudWatch Logs est le pipeline principal pour la télémétrie des applications et de la plateforme ; les développeurs devraient concevoir des journaux structurés (JSON) afin que Metrics et Insights puissent les analyser de manière fiable. Pour les métriques d’application personnalisées, préférez le format CloudWatch Embedded Metric Format (EMF) ou PutMetricData pour des dimensions immédiates et des besoins de haute résolution ; EMF intègre du JSON _aws dans les lignes de journal et permet à CloudWatch d’extraire de nombreuses métriques en un seul appel PutLogEvents pour une efficacité en termes de coût et de débit. Lorsque vous devez dériver des métriques à partir de journaux textuels côté service, créez des filtres de métriques (PutMetricFilter) sur un groupe de journaux qui associent des modèles de filtre à des MetricTransformations ; ceux-ci produisent des métriques CloudWatch qui peuvent être représentées sous forme de graphiques et déclencher des alarmes. Les API opérationnelles courantes sont CreateLogGroup, CreateLogStream et PutLogEvents (faites attention au sequenceToken et aux limites de taille de lot de PutLogEvents), et AssociateKmsKey pour attacher une clé KMS gérée par le client à un groupe de journaux pour le chiffrement au repos. Surveillez IAM : PutLogEvents et PutMetricData nécessitent des autorisations explicites, et les autorisations (grants) KMS doivent permettre au principal de service d’utiliser les clés pour le chiffrement. Utilisez des politiques de rétention pour maîtriser les coûts et ne préférez les métriques à haute résolution (PutMetricData avec StorageResolution=1) que lorsque vous avez besoin d’une visibilité inférieure à la minute.

Traçage et X-Ray pour les systèmes distribués

Le traçage distribué instrumente les flux de requêtes à travers les services pour révéler où la latence et les erreurs se produisent ; AWS X-Ray est l’option intégrée. Activez le traçage actif (Active tracing) sur les fonctions Lambda (Lambda TracingConfig Mode: Active) et activez X-Ray pour les étapes (stages) d’API Gateway afin de propager l’en-tête de trace X-Ray. Utilisez le SDK AWS X-Ray dans votre environnement d’exécution (runtime) (

undefined

pour Node,

undefined

pour Python,

undefined

pour Java) pour créer des sous-segments, ajouter des annotations (indexées, petites valeurs) et des métadonnées (non indexées, objets plus volumineux). Capturez les appels SDK en aval en enveloppant (wrapping) les clients AWS SDK avec l’enregistreur X-Ray afin que le SDK instrumente automatiquement les requêtes vers S3, DynamoDB et les appels HTTP. Pour les charges de travail conteneurisées, exécutez le démon X-Ray en tant que sidecar ou utilisez la couche (layer) du démon ; il accepte les paquets UDP (port 2000 par défaut) et les envoie par lots au service X-Ray. Configurez des règles d’échantillonnage (CreateSamplingRule) pour éviter le bruit, mais ajustez les règles ou utilisez la surcharge (override) du SDK pour les flux critiques que vous souhaitez toujours tracer. Soyez attentif aux limites de taille des documents de segment et n’incluez jamais d’informations personnelles identifiables (PII) dans les annotations car elles sont indexées et consultables.

Conception des alarmes, notifications et alertes

Les alarmes doivent détecter des événements exploitables, réduire le bruit et s’intégrer avec des guides opérationnels (runbooks). Utilisez les alarmes CloudWatch sur des métriques natives, des métriques personnalisées (provenant de PutMetricData ou de filtres de métriques), ou des expressions mathématiques sur les métriques ; ajustez DatapointsToAlarm et EvaluationPeriods pour éviter l’instabilité (flapping) et préférez les alarmes composites pour les conditions à signaux multiples (service en aval défaillant + taux d’erreur en hausse) afin de réduire le volume d’alertes. Les actions d’alarme peuvent publier sur des sujets (topics) SNS pour des flux de travail humains/automatisés, invoquer Auto Scaling ou Systems Manager OpsCenter (créer des OpsItems), ou router via des règles EventBridge pour des scénarios complexes (playbooks) (source : aws.cloudwatch). Pour les besoins d’astreinte rapides, utilisez SNS -> point de terminaison (endpoint) HTTP ou l’intégration PagerDuty ; pour la remédiation automatisée, utilisez EventBridge -> Step Functions ou Lambda avec le principe du moindre privilège IAM. Envisagez des modèles de détection d’anomalies pour établir une ligne de base du trafic et définissez des seuils OK avec un hystérésis. Les pièges courants incluent la création d’un trop grand nombre d’alarmes dimensionnées (explosion des coûts de surveillance), le fait de se fier uniquement à des déclencheurs basés sur un seul point de données, et l’échec de la sécurisation des sujets de notification (politiques d’accès SNS) pour que les alertes ne fuient pas vers des destinataires non prévus.

Modèles de dépannage et bonnes pratiques SDK/API

Commencez le dépannage en définissant une chronologie attendue par rapport à celle observée, puis corrélez les journaux, les métriques et les traces. Utilisez CloudWatch Logs Insights pour des requêtes ad-hoc (champs @timestamp, @message | parse … | stats count() by bin(1m)) afin de trouver les pics, puis de basculer vers les traces X-Ray pour des latences détaillées. Pour les API basées sur Lambda, vérifiez les démarrages à froid (cold-starts), les temps d’attachement des ENI VPC (pour les fonctions dans un VPC), et si des destinations Lambda ou des DLQ sont configurées pour capturer les invocations asynchrones échouées. Pour capturer les invocations échouées, utilisez les destinations Lambda (onFailure vers SNS, SQS ou EventBridge) ou une DLQ asynchrone pour préserver les charges utiles (payloads). Lors de l’instrumentation du code, gérez la limitation des API (throttling) en implémentant un backoff exponentiel avec gigue (jitter) et en surveillant les erreurs 429 via des filtres de métriques ou des compteurs EMF. Pièges courants : PutLogEvents nécessite le jeton de séquence correct et d’abord CreateLogStream ; PutMetricData peut être limité (throttled) — regroupez et émettez des métriques agrégées ; X-Ray requiert les permissions xray:PutTraceSegments et xray:PutTelemetryRecords (politique gérée AWSXRayDaemonWriteAccess) ; et l’échantillonnage peut masquer des problèmes à moins que vous n’ajustiez les règles pour les flux peu fréquents mais critiques.

Problème pratique : Scénario de cas d’usage

Scénario : Acme Retail exploite un service de paiement serverless sur AWS utilisant API Gateway -> Lambda -> DynamoDB. L’équipe utilise des journaux CloudWatch et X-Ray centralisés, mais il lui manque des métriques de débit des appareils par minute et elle a besoin d’alertes fiables sur les pics de latence de l’API sans créer d’alertes bruyantes.

Défi : Capturer des comptages d’appareils/messages par minute quasi en temps réel, assurer un traçage de bout en bout pour les requêtes lentes, et créer une alarme à faible bruit qui déclenche une Lambda de remédiation automatisée et notifie l’équipe d’astreinte.

Approche recommandée :

Instrumenter la Lambda de paiement pour émettre une métrique personnalisée à haute résolution en utilisant l’API PutMetricData avec Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1, et StorageResolution=1 ; les regrouper en mémoire et les vider toutes les 30s pour éviter la limitation de l’API.
Intégrer également du JSON EMF dans les journaux Lambda pour des dimensions plus riches (customerId, region) et s’appuyer sur CloudWatch Logs pour extraire des métriques supplémentaires via PutLogEvents et des filtres de métriques (PutMetricFilter) pour les comptages d’erreurs.
Activer le traçage X-Ray : définir le Mode de TracingConfig de la Lambda sur Active, activer X-Ray sur l’étage (stage) de l’API Gateway, et utiliser le SDK X-Ray pour ajouter des annotations (non-PII) et des sous-segments autour des appels HTTP externes vers des API tierces.
Créer une alarme composite CloudWatch qui combine une métrique de latence élevée au 95e percentile (metric math) avec un pic de DeviceReportsPerMinute ; définir EvaluationPeriods=3, DatapointsToAlarm=2, Action sur un sujet SNS qui déclenche un point de terminaison (endpoint) d’astreinte plus une règle EventBridge qui invoque une Lambda de remédiation (avec un rôle de moindre privilège).

Justification : L’émission de métriques à haute résolution et EMF fournit à la fois des comptages immédiats par minute et une dimensionnalité plus riche ; X-Ray fournit la cause racine de la latence jusqu’aux appels en aval ; les alarmes composites réduisent le bruit en exigeant des conditions corrélées avant de déclencher une alerte et permettent l’automatisation via EventBridge.

← Sécurité · Tous les domaines · Stockage →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →