AWS observability: CloudWatch, X-Ray, ADOT, Prometheus and Grafana

1. Vue d'ensemble #

Les briques d'observabilité d'AWS et leur rôle.

Une offre construite autour de CloudWatch #

Sur AWS, l'observabilité s'articule autour d'Amazon CloudWatch (métriques, journaux, alarmes, tableaux de bord et nombreuses fonctionnalités spécialisées), complété par AWS X-Ray pour les traces, Amazon Managed Service for Prometheus (AMP) pour les métriques au format Prometheus, Amazon Managed Grafana pour la visualisation et Amazon OpenSearch Service pour la recherche de journaux à grande échelle.

À savoir : CloudWatch collecte automatiquement les métriques de base de la plupart des services managés (EC2, RDS, ELB, Lambda…) sans agent. L'agent ou ADOT n'est nécessaire que pour les métriques du système invité (mémoire, disque), les journaux applicatifs et les traces.

Piliers pris en charge #

Point d'attention : Les profils restent le pilier le moins couvert nativement : AWS a réduit ses investissements sur CodeGuru. Pour le profilage continu, beaucoup d'équipes utilisent Grafana Pyroscope ou la solution de profilage de leur outil APM.

2. Les composants en détail #

Ce que fait chaque service et quand l'utiliser.

CloudWatch Metrics et alarmes #

Les métriques sont organisées par namespace (AWS/EC2, AWS/Lambda…), nom et dimensions. La résolution standard est d'une minute ; les métriques haute résolution descendent à la seconde. Les alarmes évaluent une métrique ou une expression (metric math) et déclenchent une notification SNS, une action Auto Scaling ou EC2. Les alarmes composites combinent plusieurs alarmes pour réduire le bruit, et la détection d'anomalies calcule une bande de valeurs attendues.

aws cloudwatch put-metric-alarm --alarm-name api-5xx \
  --namespace AWS/ApplicationELB --metric-name HTTPCode_Target_5XX_Count \
  --dimensions Name=LoadBalancer,Value=app/api/123abc \
  --statistic Sum --period 60 --evaluation-periods 5 --datapoints-to-alarm 3 \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:eu-west-3:111122223333:astreinte

Le format Embedded Metric Format (EMF) permet d'écrire des métriques dans un journal structuré JSON : CloudWatch les extrait automatiquement, ce qui est idéal pour Lambda.

CloudWatch Logs #

Les journaux sont rangés en groupes et flux, avec une rétention configurable par groupe. Logs Insights interroge les journaux avec son langage de requête (ainsi qu'en SQL et PPL selon les versions), Live Tail les suit en direct, les filtres de métriques transforment des motifs en métriques et la classe Infrequent Access réduit le coût des journaux peu consultés. La protection des données masque automatiquement des données sensibles.

aws logs start-query --log-group-name /aws/lambda/commande \
  --start-time $(date -d '-1 hour' +%s) --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter level = "ERROR" | stats count() by bin(5m)'

Traces : X-Ray, Transaction Search et Application Signals #

AWS X-Ray reçoit les segments et spans, construit une carte des services et permet d'analyser les traces. Transaction Search stocke désormais l'ensemble des spans dans CloudWatch Logs (groupe aws/spans) pour les rechercher et les agréger. CloudWatch Application Signals apporte une vue APM : services découverts automatiquement, métriques RED (volume, erreurs, latence), dépendances et SLO avec budget d'erreur, à partir d'une instrumentation OpenTelemetry (ADOT).

Bonne Pratique : Activez Application Signals sur EKS, ECS, EC2 ou Lambda pour obtenir en quelques minutes un tableau de bord par service et définir des SLO directement dans CloudWatch.

Fonctionnalités spécialisées de CloudWatch #

Managed Prometheus, Managed Grafana et OpenSearch #

Amazon Managed Service for Prometheus stocke des métriques Prometheus sans serveur à gérer : on y écrit par remote write (Prometheus, ADOT, Grafana Alloy) ou avec ses scrapers managés pour EKS, puis on l'interroge en PromQL. Amazon Managed Grafana fournit des espaces Grafana avec authentification IAM Identity Center ou SAML et des sources de données CloudWatch, X-Ray, AMP, OpenSearch, Athena et partenaires. OpenSearch Service sert à l'analyse de journaux et de traces avec OpenSearch Dashboards.

3. Fiche détaillée de chaque composant #

Rôle, contenu, types de données, rétention et interactions internes et externes de chaque brique du schéma.

Vue récapitulative #

Le tableau suivant résume chaque composant du schéma d'architecture ; les fiches qui suivent les détaillent une par une.

Valeurs indicatives : Les durées de rétention, limites et modèles de prix évoluent régulièrement : vérifiez-les dans la documentation officielle avant de dimensionner une architecture.

ADOT Collector (AWS Distro for OpenTelemetry) #

Le collecteur ADOT est la distribution du collecteur OpenTelemetry maintenue par AWS : il reçoit la télémétrie des applications, l'enrichit et l'exporte vers les services AWS.

À savoir : Déploiement : module complémentaire EKS, conteneur sidecar ECS, couche Lambda ou service sur EC2.

Agent CloudWatch et Fluent Bit (FireLens) #

L'agent CloudWatch collecte ce que la plateforme ne voit pas depuis l'extérieur d'une machine ; Fluent Bit, souvent via FireLens sur ECS, achemine les journaux des conteneurs.

CloudWatch Metrics #

Le magasin de séries temporelles d'AWS : chaque service y publie ses métriques, et les applications peuvent y ajouter les leurs.

Amazon Managed Service for Prometheus (AMP) #

Un back-end Prometheus sans serveur à gérer, compatible PromQL.

AWS X-Ray, Transaction Search et Application Signals #

La brique traces et APM d'AWS, désormais intégrée à CloudWatch.

CloudWatch Logs #

Le magasin central des journaux sur AWS.

Amazon Managed Grafana #

Des espaces Grafana entièrement gérés par AWS.

API de requête (CloudWatch, Logs, X-Ray, AMP) #

Toutes les données d'observabilité AWS sont accessibles par API : c'est la principale porte de sortie « en lecture ».

À savoir : Pour un outil tiers, préférez Metric Streams à l'interrogation périodique : moins de latence et pas de coût d'appels GetMetricData.

Alarmes CloudWatch, SNS et EventBridge #

La chaîne qui transforme une condition sur les données en action ou en notification.

Amazon Data Firehose (Metric Streams et abonnements) #

Le service de diffusion en continu qui fait sortir métriques et journaux d'AWS vers d'autres outils.

4. Compatibilité OpenTelemetry #

ADOT, points de terminaison OTLP et configuration d'un collecteur.

AWS Distro for OpenTelemetry (ADOT) #

ADOT est la distribution d'OpenTelemetry maintenue par AWS : collecteur, SDK et agents d'instrumentation automatique (Java, Python, .NET, Node.js) avec les composants AWS (détecteurs de ressources EC2, ECS, EKS, Lambda, exportateurs awsemf et awsxray, authentification sigv4auth). Elle est disponible en module complémentaire EKS, en couche Lambda et en image de conteneur.

CloudWatch expose aussi des points de terminaison OTLP pour les traces (X-Ray) et les journaux : un collecteur OpenTelemetry standard peut y envoyer ses données en OTLP/HTTP, signées avec SigV4.

extensions:
  sigv4auth:
    region: eu-west-3
    service: aps
receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
processors:
  batch: {}
  resourcedetection: { detectors: [env, eks, ec2] }
exporters:
  awsemf:                      # métriques vers CloudWatch (Embedded Metric Format)
    namespace: Boutique
  awsxray: {}                  # traces vers X-Ray
  prometheusremotewrite:       # métriques vers Managed Prometheus
    endpoint: https://aps-workspaces.eu-west-3.amazonaws.com/workspaces/ws-1234/api/v1/remote_write
    auth: { authenticator: sigv4auth }
service:
  extensions: [sigv4auth]
  pipelines:
    traces:  { receivers: [otlp], processors: [resourcedetection, batch], exporters: [awsxray] }
    metrics: { receivers: [otlp], processors: [resourcedetection, batch], exporters: [awsemf, prometheusremotewrite] }

À savoir : Les SDK OpenTelemetry s'utilisent tels quels : pour X-Ray, ajoutez le générateur d'identifiants et le propagateur X-Ray seulement si vous devez interopérer avec d'anciens services instrumentés par le SDK X-Ray ; sinon le contexte W3C suffit.

5. Interconnexions avec les produits externes #

Envoyer les données AWS vers d'autres outils et inversement.

Exporter depuis AWS #

Bonne Pratique : Préférez Metric Streams à l'interrogation des API (polling) pour envoyer les métriques à un outil tiers : la latence passe de plusieurs minutes à quelques secondes et le coût des appels GetMetricData disparaît.

Centraliser plusieurs comptes #

L'observabilité inter-comptes de CloudWatch (Observability Access Manager) relie des comptes sources à un compte de supervision : métriques, journaux, traces et Application Signals y sont consultables sans copie de données. Combinée à AWS Organizations, elle donne une vue unique de toute l'organisation.

6. Coûts et bonnes pratiques #

Maîtriser la facture et rendre l'observabilité utile.

Bonnes pratiques #

• Définir une rétention par groupe de journaux (la valeur par défaut est « jamais expirer »).
• Limiter la cardinalité des dimensions personnalisées : chaque combinaison est une métrique facturée.
• Instrumenter avec OpenTelemetry (ADOT) pour rester portable vers d'autres back-ends.
• Utiliser les alarmes composites et la détection d'anomalies pour réduire le bruit.
• Échantillonner les traces (règles d'échantillonnage X-Ray ou échantillonnage par queue dans le collecteur).
• Activer l'observabilité inter-comptes et tagger les ressources pour attribuer les coûts.

Erreur courante : Les journaux sont souvent le premier poste de coût : ingérer tous les journaux de debug en production peut coûter plus cher que les serveurs eux-mêmes.