Amazon DOP-C02: Surveillance, journalisation et observabilité — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-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.

Vue d’ensemble

La surveillance, la journalisation et l’observabilité sur AWS nécessitent de combiner les métriques, les journaux, les traces, les événements et la télémétrie de l’état de santé en signaux exploitables. Les architectures efficaces utilisent Amazon CloudWatch pour les métriques, les alarmes et les tableaux de bord ; CloudWatch Logs et Logs Insights pour l’ingestion et l’analyse des journaux ; AWS X-Ray pour le traçage distribué ; AWS CloudTrail pour l’audit et l’intégrité ; Amazon EventBridge pour la détection et l’automatisation événementielles ; AWS Health pour les événements de service spécifiques au compte ; et des pipelines centralisés (Kinesis Data Firehose et OpenSearch) pour la recherche et la corrélation à grande échelle. Les modèles ci-dessous mettent l’accent sur la réduction du bruit, le routage précis des signaux, l’automatisation et les opérations multi-comptes/multi-régions.

Métriques, alarmes, tableaux de bord et alarmes composites CloudWatch

Les métriques CloudWatch sont le fondement des SLO, de la mise à l’échelle (scaling) et des alertes. Publiez des métriques personnalisées avec des dimensions granulaires pour isoler les signaux (par exemple, apiOperation, appVersion, statusCode). Utilisez le format CloudWatch Embedded Metric Format (EMF) avec des journaux structurés pour émettre efficacement des dimensions à haute cardinalité depuis Lambda, les conteneurs et EC2, en évitant la surcharge de l’API PutMetricData.

Configurez les alarmes avec une évaluation robuste :

Choisissez des périodes alignées sur la granularité des données et les fenêtres de SLO.
Définissez datapointsToAlarm (m sur n) pour la résilience face au bruit transitoire.
Utilisez TreatMissingData pour éviter les faux positifs lors des déploiements ou des pauses.
Tirez parti des bandes de détection d’anomalies lorsque les lignes de base varient avec la saisonnalité, et de metric math pour les indicateurs dérivés (latence p95, pourcentages d’erreur, ratios de saturation).
Attachez des actions aux alarmes : notifier via SNS, créer des OpsItems dans OpsCenter, exécuter une SSM Automation ou restaurer des instances EC2. Les politiques de mise à l’échelle peuvent référencer les états d’alarme pour agir, mais les alarmes composites ne peuvent pas déclencher directement la mise à l’échelle.

Les alarmes composites réduisent la fatigue liée aux alarmes en combinant plusieurs alarmes sous-jacentes avec une logique AND/OR. Par exemple, n’alertez que lorsque la latence p95 est élevée ET que le taux d’erreurs 5xx dépasse le seuil ET que la saturation du CPU persiste, s’alignant ainsi sur l’impact utilisateur. Les alarmes composites acceptent les mises à jour d’état des alarmes enfants à travers les régions/comptes via l’observabilité inter-comptes ou des flux de métriques (metric streams) vers un compte central.

Les tableaux de bord visualisent les indicateurs clés à travers les services. Utilisez des widgets pour les métriques, les résultats de requêtes Logs Insights et l’état des alarmes (Alarm Status). Standardisez les conventions des tableaux de bord (nommage, plages de temps, superpositions de SLO) et tirez parti des vues inter-régions/inter-comptes avec CloudWatch Observability Access Manager (OAM). Pour la corrélation ad hoc, épinglez les widgets Logs Insights et X-Ray ServiceLens côte à côte avec les widgets de carte de service (service map) et les taux d’erreur de Kinesis Firehose.

CloudWatch Logs : Groupes de journaux, filtres de métriques, filtres d’abonnement et Logs Insights

Structurez les groupes de journaux par application/composant et par étape du cycle de vie. Définissez des politiques de rétention explicites (ne vous fiez pas à « Never Expire ») et activez le chiffrement KMS si nécessaire. Utilisez des politiques de ressources et des autorisations IAM granulaires pour contrôler les producteurs et les abonnés. Pour une ingestion à haut débit, assurez une concurrence et un traitement par lots adéquats pour les flux de journaux.

Les filtres de métriques transforment les modèles de journaux en métriques. Définissez un modèle de filtre avec des jetons extraits (JSON ou délimités par des espaces) et mappez ces jetons à des dimensions de métrique. Cela prend en charge des cas d’usage tels que les métriques par API, par version, par code de réponse, publiées directement depuis les journaux sans modifier les producteurs. Assurez-vous que les unités et les valeurs par défaut sont correctes ; préférez 1 par événement et dérivez les taux via metric math. Utilisez ces métriques pour les alertes SLO et les tableaux de bord.

Les filtres d’abonnement diffusent (stream) les journaux en quasi temps réel vers :

Kinesis Data Firehose pour la transformation et la livraison vers S3/OpenSearch.
Kinesis Data Streams pour des consommateurs personnalisés.
Lambda pour le routage personnalisé, la rédaction des PII (informations d’identification personnelle) ou les notifications événementielles. Utilisez une destination CloudWatch Logs avec un rôle IAM pour les abonnements inter-comptes. Planifiez les nouvelles tentatives et la contre-pression (backpressure) ; Lambda et Firehose fournissent respectivement des nouvelles tentatives intégrées et des DLQ/compartiments S3 d’erreurs.

CloudWatch Logs Insights fournit une capacité de requête interactive et sans serveur sur les journaux. Les opérateurs principaux incluent fields, filter, parse, stats, sort, limit, dedup, et bin pour le regroupement temporel. Analysez les champs JSON ou utilisez une analyse de type grok pour les journaux texte. Exemples :

filter status >= 500 | stats count() by apiOperation, appVersion
parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service Enregistrez les requêtes fréquemment utilisées avec QueryDefinition pour les réutiliser en équipe, et intégrez-les dans les tableaux de bord en tant que widgets de requête. Pour l’automatisation, planifiez une fonction Lambda via EventBridge pour exécuter StartQuery/GetQueryResults et publier des résumés sur SNS ou dans OpsCenter. Restreignez le périmètre de la requête à des groupes de journaux et des fenêtres temporelles spécifiques pour maîtriser les coûts.

AWS X-Ray : Traçage, Règles d’échantillonnage, Cartes de service et Annotations

X-Ray capture les traces distribuées à travers les services pour identifier les contributeurs à la latence et les limites des défaillances. Instrumentez les services avec AWS Distro for OpenTelemetry (ADOT) ou les SDK X-Ray, propagez l’en-tête de trace (par ex., X-Amzn-Trace-Id), et exécutez le démon/agent X-Ray là où c’est nécessaire (ECS/EKS/EC2). De nombreux services gérés s’intègrent nativement (API Gateway, ALB via la journalisation des accès qui propage les traces, Lambda avec le traçage actif, Step Functions via des sous-segments).

Les règles d’échantillonnage contrôlent le volume de données et la fidélité du signal. Utilisez un ensemble de règles d’échantillonnage centralisé avec :

Un réservoir fixe par seconde pour les traces de base par service.
Un pourcentage d’échantillonnage basé sur un taux pour s’adapter au débit.
Une priorité de règle et une correspondance par service/URL pour les chemins critiques et les scénarios d’erreur. Augmentez l’échantillonnage pendant les incidents et pour le trafic canary afin de préserver l’observabilité tout en maîtrisant les coûts.

Les cartes de service (Service maps) visualisent le graphe d’appels, montrant les liens avec la latence, les taux d’erreur et les indicateurs de limitation (throttling). Explorez les traces pour examiner les segments et sous-segments des dépendances en aval. Utilisez des annotations (paires clé-valeur indexées) pour un filtrage à haute cardinalité tel que customerTier, apiOperation, appVersion, ou les ID de requête AWS. Utilisez les métadonnées (metadata) pour un contexte verbeux et non indexé afin d’éviter l’explosion de l’index. Combinez les groupes de traces X-Ray avec CloudWatch ServiceLens pour corréler les journaux, les métriques et les traces dans une vue unique. Créez des expressions de filtre (par ex., annotation.appVersion = “2.3.1” and fault = true) pour isoler les régressions et exporter les ID de trace pour une recherche ciblée dans les journaux.

Gouvernance et Événements : CloudTrail, EventBridge et AWS Health

CloudTrail enregistre l’activité des API à des fins de gouvernance et d’analyse forensique. Activez un journal de suivi (trail) d’organisation pour tous les comptes et toutes les Régions, livrez-le dans un compartiment S3 centralisé avec SSE-KMS, activez la validation des fichiers journaux, et intégrez-le avec CloudWatch Logs pour une détection quasi temps réel. Distinguez les classes d’événements :

Événements de gestion (Management events) : plan de contrôle (par ex., CreateUser, RunInstances). Configurez pour inclure les événements en lecture seule et en écriture seule selon les besoins.
Événements de données (Data events) : opérations à haut volume du plan de données telles que l’accès au niveau des objets S3, l’invocation de Lambda, les API d’éléments DynamoDB, les appels au serveur d’API EKS. Ciblez les événements de données de manière sélective (par compartiment/fonction/table) pour contrôler les coûts. Utilisez CloudTrail Insights pour détecter les pics d’API inhabituels, et envoyez les événements CloudTrail vers EventBridge pour une remédiation automatique. Validez l’intégrité des journaux à l’aide des fichiers de synthèse (digest files) et de la commande AWS CLI

undefined

lors des audits.

EventBridge fournit une structure d’événements (event fabric) pour la détection et l’automatisation. Utilisez le bus d’événements par défaut pour les événements des services AWS et créez des bus personnalisés pour les événements du domaine applicatif. Définissez des modèles d’événements (event patterns) correspondant à la source, au type de détail (detail-type), aux champs de détail, aux préfixes, aux plages numériques et à la logique « tout-sauf ». Appliquez des transformateurs d’entrée (input transformers) pour remodeler les événements, attachez des politiques basées sur les ressources pour la publication inter-comptes, et configurez les tentatives (retry) et les files de lettres mortes (DLQ) sur les cibles. Les cibles courantes incluent Lambda (remédiation), Step Functions (orchestration), SQS (découplage), Systems Manager Automation (actions opérationnelles), CodePipeline (déclencheurs CI) et SNS (notifications). Archivez et rejouez les événements pour récupérer après des pannes de consommateurs, et utilisez le registre de schémas (schema registry) pour générer des modèles d’événements fortement typés.

AWS Health fait remonter les événements de service spécifiques au compte, les changements planifiés et les problèmes opérationnels. Intégrez via EventBridge avec la source aws.health et le detail-type AWS Health Event pour router vers les canaux d’incidents, ouvrir des OpsItems dans OpsCenter, ou déclencher des actions d’arrêt ou de mise à l’échelle sécurisées pour les fenêtres de maintenance. Utilisez la vue organisationnelle (Organizational View) avec un compte administrateur délégué pour agréger les événements Health de tous les comptes, et envisagez d’utiliser l’API AWS Health ou la solution AWS Health Aware pour pousser des notifications personnalisées dans les systèmes d’astreinte.

Journalisation centralisée avec Kinesis Data Firehose et OpenSearch

Une stratégie de journalisation multi-comptes et multi-régions standardise l’ingestion et la recherche. Dans chaque compte producteur, configurez les filtres d’abonnement de CloudWatch Logs vers une destination Logs inter-comptes s’appuyant sur un Kinesis Data Firehose central. Activez les fonctionnalités de Firehose :

Transformation des données via Lambda pour la normalisation (JSON), la rédaction des PII et l’enrichissement avec les métadonnées de compte AWS, de région, de VPC et de service.
Compression (GZIP) et partitionnement dynamique lors de la livraison à S3 pour optimiser les performances des requêtes dans Athena.
Chiffrement avec KMS et livraison en VPC pour les points de terminaison privés. Livrez à Amazon OpenSearch Service pour une recherche à faible latence et une visualisation avec Kibana/OpenSearch Dashboards. Utilisez des modèles d’index, des politiques ILM/ISM pour le roulement et la rétention, et des politiques d’accès affinées mappant les utilisateurs à des modèles d’index (par ex., compte/équipe/service). Configurez la sortie des erreurs vers S3 pour les documents en échec et surveillez les métriques de livraison de Firehose et d’ingestion d’OpenSearch (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests). Pour des volumes très élevés, envisagez de stocker tous les logs dans S3 via Firehose et d’utiliser un sous-ensemble diffusé vers OpenSearch, avec des requêtes Athena à la demande sur S3 pour les investigations sur la longue traîne afin de maîtriser les coûts.

Combinez ce pipeline avec les filtres de métriques CloudWatch pour des compteurs rapides et peu coûteux, et avec Logs Insights pour des requêtes approfondies ad hoc. Utilisez des règles EventBridge déclenchées par des anomalies Firehose/OpenSearch ou des alarmes CloudWatch pour lancer des remédiations ou créer des incidents.

Scénario de problème pratique

Airbnb subit des pics intermittents d’erreurs d’API et de latence sur des microservices déployés sur EKS et Lambda, avec plusieurs versions d’applications mobiles en production. Les opérations nécessitent une détection quasi temps réel par opération d’API, code de réponse et version d’application ; une analyse rapide de la cause racine à travers les traces et les logs ; une remédiation automatisée pour les schémas de défaillance connus ; et des pistes d’audit de niveau gouvernance.

Standardiser la journalisation structurée

Implémenter des logs JSON structurés EMF dans les services (EKS, Lambda) incluant des champs pour apiOperation, statusCode, appVersion, tenantId et latencyMs.
Pourquoi : EMF permet l’extraction directe de métriques dans CloudWatch avec une faible surcharge et des dimensions à haute cardinalité pour des alarmes précises.

Créer des filtres de métriques CloudWatch Logs

Pour chaque groupe de logs de service, définir des filtres de métriques qui incrémentent des compteurs par apiOperation, statusCode et appVersion.
Pourquoi : Produit des métriques par dimension sans chemins de code supplémentaires, permettant des tableaux de bord et des alarmes exploitables par API et par version de client.

Construire des alarmes CloudWatch superposées et une alarme composite

Alarmer sur la latence p95, le taux de 5xx et la saturation (CPU, mémoire, concurrence/throttling). Créer une alarme composite : LatencyHigh ET ErrorsHigh sur 2 des 3 périodes consécutives.
Pourquoi : Réduit le bruit et se concentre sur les incidents impactant l’utilisateur.

Déployer le traçage X-Ray avec un échantillonnage ciblé

Utiliser les collecteurs ADOT sur EKS et le traçage actif pour Lambda. Définir des règles d’échantillonnage pour capturer toutes les traces d’erreur et un échantillon représentatif des appels réussis, avec un échantillonnage plus élevé sur les nouvelles versions d’application.
Pourquoi : Garantit la visibilité sur les défaillances et une couverture suffisante pour les points chauds de performance tout en maîtrisant les coûts.

Corréler avec ServiceLens et Logs Insights

Créer des tableaux de bord combinant des widgets de métriques, la carte de service X-Ray et des requêtes Logs Insights (par ex., filter status >= 500 | stats count() by apiOperation, appVersion).
Pourquoi : La corrélation sur un panneau unique accélère le diagnostic de l’opération et de la version client qui ont régressé.

Centraliser les logs via Firehose vers OpenSearch et S3

Configurer des filtres d’abonnement vers un Firehose central avec une transformation Lambda pour normaliser, rédiger les PII et enrichir avec le compte/la région. Livrer à OpenSearch pour une recherche à chaud sur 7 jours et à S3 pour une rétention durable et des requêtes Athena.
Pourquoi : Recherche rapide et inter-équipes sur les problèmes actuels avec une analyse historique à faible coût.

Automatiser la détection et la remédiation avec EventBridge

Créer des règles EventBridge pour les changements d’état des alarmes CloudWatch et certains événements d’API d’écriture CloudTrail (par ex., modifications de groupes de sécurité). Cibles : Lambda pour des restaurations sécurisées (par ex., annuler des feature flags) et Step Functions pour une remédiation en plusieurs étapes.
Pourquoi : Les boucles de contrôle événementielles réduisent le MTTR et appliquent des garde-fous.

Intégrer AWS Health et la gestion de la maintenance

Ajouter des règles EventBridge pour les événements aws.health affectant EC2, EKS ou le réseau. Cibler SSM Automation pour isoler/drainer les nœuds ou dévier le trafic.
Pourquoi : L’atténuation proactive des problèmes planifiés ou opérationnels réduit les temps d’arrêt.

Renforcer la gouvernance avec une piste d’organisation CloudTrail et l’intégrité

Activer une piste d’organisation multi-régions avec des événements de données pour S3 et Lambda, le chiffrement SSE-KMS et la validation des fichiers de logs. Diffuser vers CloudWatch Logs et OpenSearch pour la détection d’anomalies et les investigations.
Pourquoi : Un audit complet et infalsifiable répond à la conformité et accélère la RCA.

Notifications et intégration Ops

Acheminer les événements critiques vers SNS et les systèmes d’astreinte, ouvrir des OpsItems dans OpsCenter avec des runbooks joints, et attacher des balises d’alarme pour la propriété et la gravité.
Pourquoi : Une propriété claire et des runbooks automatisés améliorent la qualité et la vitesse de la réponse.

Cette conception a été choisie pour combiner des métriques à faible latence et riches en dimensions (CloudWatch + EMF), une corrélation de trace approfondie (X-Ray + ServiceLens), une recherche à grande échelle (OpenSearch + S3/Athena), une remédiation événementielle (EventBridge + Lambda/SSM/Step Functions) et une gouvernance auditable (CloudTrail avec intégrité). Elle équilibre le coût et la fidélité avec l’échantillonnage, les niveaux de rétention et des alarmes ciblées qui reflètent l’impact utilisateur réel.

← Infrastructure en tant que code et gestion de la configuration · Tous les domaines · Sécurité →

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