Observabilité AWS — CloudWatch, X-Ray et Synthetics DOP-C02 2026

📍 Article principal du cluster : AWS DevOps Engineer Professional DOP-C02 — guide complet 2026

Ce tutoriel fait partie du cluster certification AWS DOP-C02. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 4 « Monitoring and Logging » pèse 15 % de l’examen DOP-C02. Il combine CloudWatch (le service d’observability AWS), X-Ray (distributed tracing), et CloudWatch Synthetics (canaries pour monitoring synthétique). Ce tutoriel instrumente une application Node.js déployée sur Lambda + ECS pour démontrer le service map X-Ray, configure des alarms CloudWatch composites avec rollback automatique, et déploie une canary Synthetics pour vérifier la disponibilité du endpoint public.

Prérequis

• AWS CLI v2 configuré, région définie
• Node.js 22+ installé localement
• Tutoriels CodePipeline et CFN/CDK terminés
• 40 minutes

Étape 1 — Custom CloudWatch Metrics depuis une application

L’application doit exposer ses métriques business à CloudWatch. La méthode standard 2026 est l’embedded metrics format (EMF) — l’application logue des JSON spéciaux que CloudWatch parse automatiquement en métriques.

// app.js — Lambda handler simple avec EMF
const { metricScope, Unit } = require('aws-embedded-metrics');

exports.handler = metricScope(metrics => async (event) => {
  metrics.setNamespace('DopC02App');
  metrics.putDimensions({ Service: 'orders', Environment: 'prod' });
  metrics.putMetric('OrdersProcessed', 1, Unit.Count);
  metrics.putMetric('LatencyMs', Math.random() * 100, Unit.Milliseconds);

  return { statusCode: 200, body: 'OK' };
});

Aucun appel `PutMetricData` direct — on logue simplement avec aws-embedded-metrics. CloudWatch Logs détecte le format EMF et créé automatiquement la métrique. Pattern le plus efficace en 2026 pour 95 % des cas.

Étape 2 — Créer une CloudWatch Alarm sur métrique custom

Une alarm surveille une métrique et déclenche une action quand un seuil est dépassé. Indispensable pour réagir aux dégradations en production.

aws cloudwatch put-metric-alarm \
  --alarm-name dop-c02-high-latency \
  --metric-name LatencyMs \
  --namespace DopC02App \
  --statistic Average \
  --period 60 \
  --threshold 200 \
  --evaluation-periods 3 \
  --comparison-operator GreaterThanThreshold \
  --datapoints-to-alarm 2 \
  --dimensions Name=Service,Value=orders Name=Environment,Value=prod \
  --treat-missing-data notBreaching

L’alarm se déclenche quand 2 datapoints sur 3 dépassent 200ms en moyenne. Le `treat-missing-data` est crucial pour éviter les faux positifs — `notBreaching` signifie « si pas de données, considérer OK ». Tombe à l’examen.

Étape 3 — Composite alarms pour réduire le bruit

Une composite alarm combine plusieurs alarms via opérateurs booléens (AND, OR, NOT). Utilisée pour éviter les pages multiples sur un même incident.

aws cloudwatch put-composite-alarm \
  --alarm-name dop-c02-service-degraded \
  --alarm-rule "ALARM('dop-c02-high-latency') AND ALARM('dop-c02-error-rate-high')" \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:incident-topic

Le service est considéré « degraded » seulement si latence ET error rate sont en alarm simultanément. Évite de paginer un humain pour un pic de latence isolé sans erreurs. Pattern fortement testé en domaine 5.

Étape 4 — X-Ray instrumentation pour distributed tracing

X-Ray trace les requêtes qui traversent plusieurs services (Lambda → DynamoDB → S3). Le SDK X-Ray instrumente automatiquement les appels AWS et HTTP sortants.

const AWSXRay = require('aws-xray-sdk-core');
const AWS = AWSXRay.captureAWS(require('aws-sdk'));
const axios = AWSXRay.captureHTTPsGlobal(require('https'));

exports.handler = async (event) => {
  const segment = AWSXRay.getSegment();
  const sub = segment.addNewSubsegment('processOrder');

  try {
    const dynamodb = new AWS.DynamoDB.DocumentClient();
    await dynamodb.put({TableName: 'orders', Item: {id: '123', status: 'pending'}}).promise();

    sub.addAnnotation('orderId', '123');
    sub.close();
    return { statusCode: 200 };
  } catch (e) {
    sub.addError(e);
    sub.close();
    throw e;
  }
};

Le service map X-Ray devient extrêmement utile : vous voyez la latence par segment (Lambda invoke, DynamoDB put, HTTPs externe), les erreurs propagées, et les goulets d’étranglement. Pour activer Lambda → X-Ray, activer `Active tracing` dans la configuration de la fonction.

Étape 5 — CloudWatch Synthetics canary

Une canary Synthetics est un script (Puppeteer ou Selenium) qui simule un utilisateur réel et exécute périodiquement des actions. Détecte les pannes utilisateur avant que les vraies plaintes arrivent.

// canary-script.js
const synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const homepageCheck = async function () {
  const page = await synthetics.getPage();
  await synthetics.executeStep('navigate', async () => {
    await page.goto('https://www.example.com');
    const title = await page.title();
    if (!title.includes('Welcome')) throw new Error('Title check failed');
  });

  await synthetics.executeStep('check-login-button', async () => {
    await page.waitForSelector('#login-btn', { timeout: 5000 });
  });
};

exports.handler = async () => {
  return await synthetics.executeHttpStep('homepage', homepageCheck);
};

Cette canary tourne toutes les 5 minutes (configurable) depuis plusieurs régions AWS. En cas d’échec, CloudWatch Alarm + SNS + PagerDuty. Vous découvrez les pannes en moins de 5 minutes au lieu d’attendre les tickets utilisateur.

Étape 6 — CloudWatch Logs Insights — recherches puissantes

Logs Insights est le langage de requête CloudWatch pour fouiller des Go de logs. Syntaxe simple, performance excellente.

aws logs start-query \
  --log-group-name /aws/lambda/dop-app \
  --start-time $(date -d '1 hour ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter level = "ERROR" | sort @timestamp desc | limit 20'

Cette requête liste les 20 dernières erreurs Lambda triées par timestamp. Logs Insights supporte les agrégations (`stats`), les groupements (`by`), les patterns regex (`parse`). Maîtriser cette syntaxe est testé directement à l’examen.

Étape 7 — Container Insights pour ECS

Container Insights ajoute des dashboards prédéfinis et des métriques agrégées au niveau cluster, service, task, et conteneur. Activation simple via tag de cluster.

aws ecs update-cluster-settings \
  --cluster dop-c02-cluster \
  --settings name=containerInsights,value=enabled

aws cloudwatch list-dashboards | head -20

Une fois activé, le namespace `ECS/ContainerInsights` se peuple avec CPUUtilization, MemoryUtilization, NetworkRxBytes, etc. — par cluster, service, task. Indispensable pour piloter la capacité ECS.

Étape 8 — Application Insights pour détection automatique

CloudWatch Application Insights crée automatiquement des dashboards et alarms basés sur les meilleures pratiques pour des stacks classiques (LAMP, .NET sur EC2, Node sur ECS). Gain de temps massif sur le bootstrap d’observability.

aws application-insights create-application \
  --resource-group-name dop-c02-resource-group \
  --auto-config-enabled \
  --auto-create

L’option `–auto-config-enabled` détecte les ressources existantes et configure les alarms appropriées sans intervention manuelle. Excellent point de départ avant de personnaliser.

Comprendre la différence Metrics vs Logs vs Traces vs Events

Quatre signaux d’observability à ne pas confondre. Metrics sont des nombres agrégés dans le temps (CPU %, requests/sec). Faible volume, faible coût, idéal pour alarms. Logs sont des événements textuels horodatés. Volume élevé, coût élevé, idéal pour debug post-mortem. Traces représentent le chemin d’une requête à travers plusieurs services. Volume moyen, idéal pour comprendre les latences distribuées. Events (EventBridge) sont des notifications structurées entre services AWS — pas un signal d’observability mais une primitive d’automation reactive.

L’examen DOP-C02 teste régulièrement votre capacité à choisir le bon signal pour un cas d’usage. Question type : « Une équipe veut détecter les régressions de latence après un déploiement ». Réponse : Metrics CloudWatch avec composite alarm, pas Logs (trop verbeux pour de l’alerting).

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les startups dakaroises et abidjanaises sur AWS, l’observability est souvent négligée par budget. Pourtant CloudWatch en mode embedded metrics + Logs Insights est gratuit jusqu’à 5 Go logs/mois et 10 métriques custom — largement suffisant pour 5-10 microservices en early-stage. X-Ray est gratuit pour les premiers 100k traces/mois. Le combo CloudWatch + X-Ray + Synthetics donne une observability équivalente à Datadog (qui coûte 2 000-5 000 USD/mois pour la même couverture) pour un coût marginal sur AWS Free Tier étendu. Pratique pour préparer DOP-C02 et utile en production réelle.

Tutoriels frères

• Pipeline CodePipeline + CodeBuild + CodeDeploy ECS
• CloudFormation et AWS CDK TypeScript

Pour aller plus loin

• 🔝 Retour au pilier : AWS DOP-C02 — guide complet 2026
• CloudWatch User Guide : docs.aws.amazon.com/AmazonCloudWatch
• X-Ray Developer Guide : docs.aws.amazon.com/xray
• Synthetics canaries : docs.aws.amazon.com/AmazonCloudWatch/Synthetics

FAQ

CloudWatch ou Datadog en production ?
Pour 80 % des cas d’usage, CloudWatch suffit et coûte 5-10x moins cher. Datadog se justifie pour des stacks multi-cloud ou avec des besoins APM très avancés.

X-Ray vs OpenTelemetry ?
OpenTelemetry est le standard ouvert montant. AWS supporte OTel via ADOT (AWS Distro for OpenTelemetry) qui forwarde vers X-Ray. À l’examen, X-Ray reste le focus, mais connaître OTel est un plus en interview.

Mots-clés secondaires : cloudwatch metrics, x-ray distributed tracing, synthetics canary, embedded metrics format, container insights, application insights aws, dop-c02 monitoring