Observabilité web : logs, métriques et traces avec AWS CloudWatch

Pourquoi l’observabilité est devenue incontournable en 2025

Vos utilisateurs quittent votre site si une page met plus de 3 secondes à charger. Google pénalise les sites lents dans ses résultats de recherche. Et quand un incident survient en production à 2 h du matin, chaque minute de downtime coûte en moyenne 5 600 $ aux entreprises selon Gartner.

Dans ce contexte, le simple monitoring — « le serveur répond-il oui ou non ? » — ne suffit plus. Il faut comprendre ce qui se passe à l’intérieur de vos systèmes. C’est exactement ce que permet l’observabilité.

L’observabilité repose sur trois piliers fondamentaux :

• Les logs : le journal détaillé de tout ce qui se passe.
• Les métriques : les indicateurs chiffrés agrégés dans le temps.
• Les traces : le parcours complet d’une requête à travers vos services.

AWS CloudWatch, le service de surveillance natif d’Amazon Web Services, permet d’unifier ces trois piliers dans une seule plateforme. Chez Lueur Externe, certifié AWS Solutions Architect, nous implémentons cette approche pour nos clients depuis plusieurs années. Voici notre retour d’expérience complet.

Les trois piliers de l’observabilité expliqués

Les logs : la mémoire brute de vos applications

Un log est un événement horodaté émis par votre application ou votre infrastructure. C’est la donnée la plus riche et la plus détaillée dont vous disposez.

Exemples de logs :

• Une erreur PHP dans votre boutique PrestaShop
• Une requête SQL lente sur votre base de données
• Un accès refusé sur votre API
• Le démarrage ou l’arrêt d’un conteneur Docker

Les logs sont indispensables pour le diagnostic post-incident. Sans eux, vous naviguez à l’aveugle. Mais attention : leur volume peut exploser très vite. Un site e-commerce moyen génère facilement 1 à 5 Go de logs par jour.

Les métriques : le pouls chiffré de votre infrastructure

Une métrique est une valeur numérique mesurée à intervalle régulier. Contrairement aux logs, les métriques sont légères, agrégées et faciles à visualiser sur des graphiques.

Exemples de métriques courantes :

• Utilisation CPU d’une instance EC2 (en %)
• Nombre de requêtes HTTP par seconde
• Temps de réponse moyen d’une API (en ms)
• Taux d’erreurs 5xx sur un load balancer
• Espace disque disponible (en Go)

Les métriques servent à détecter les anomalies en temps réel et à déclencher des alertes automatiques.

Les traces distribuées : le fil rouge d’une requête

Dans une architecture moderne (microservices, serverless, multi-tiers), une seule requête utilisateur peut traverser 5, 10, voire 20 services différents. Si cette requête met 4 secondes au lieu de 200 ms, comment identifier le service responsable ?

C’est le rôle des traces distribuées. Chaque requête reçoit un identifiant unique qui la suit de service en service, permettant de reconstituer son parcours complet avec les temps de latence à chaque étape.

Pilier	Ce qu’il mesure	Volume de données	Cas d’usage principal
Logs	Événements détaillés	Élevé	Diagnostic post-incident
Métriques	Valeurs numériques agrégées	Faible	Alerting et dashboards
Traces	Parcours d’une requête	Moyen	Analyse de latence

AWS CloudWatch : une plateforme d’observabilité unifiée

AWS CloudWatch n’est pas un simple outil de monitoring. C’est un écosystème complet qui couvre les trois piliers de l’observabilité. Voici ses composants principaux.

CloudWatch Logs : centraliser et analyser vos journaux

CloudWatch Logs permet de collecter, stocker et interroger les logs de toutes vos ressources AWS : instances EC2, fonctions Lambda, conteneurs ECS/EKS, bases de données RDS, etc.

Les fonctionnalités clés :

• Log Groups et Log Streams : organisation hiérarchique des logs
• Logs Insights : langage de requête puissant pour fouiller dans des téraoctets de logs en quelques secondes
• Filtres de métriques : transformer automatiquement un pattern de log en métrique
• Rétention configurable : de 1 jour à 10 ans, selon vos besoins de conformité

Voici un exemple de requête CloudWatch Logs Insights pour identifier les 10 requêtes les plus lentes sur un serveur web :

fields @timestamp, @message
| filter @message like /request_time/
| parse @message '"request_time":*,' as request_time
| filter request_time > 2.0
| sort request_time desc
| limit 10

Cette requête s’exécute en quelques secondes même sur plusieurs centaines de gigaoctets de logs. C’est un outil que nous utilisons quotidiennement chez Lueur Externe pour diagnostiquer les problèmes de performance sur les sites de nos clients.

CloudWatch Metrics : surveiller en temps réel

CloudWatch collecte automatiquement des métriques pour la plupart des services AWS, sans configuration :

• EC2 : CPU, réseau, disque, statut d’instance
• RDS : connexions actives, IOPS, latence de réplication
• ALB/NLB : requêtes, temps de réponse, codes d’erreur
• Lambda : durée d’exécution, invocations, erreurs, cold starts
• S3 : nombre de requêtes, taille du bucket

Mais la vraie puissance réside dans les métriques personnalisées. Vous pouvez publier vos propres métriques métier directement depuis votre application.

Exemple en Python avec boto3 pour publier une métrique personnalisée :

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='eu-west-3')

cloudwatch.put_metric_data(
    Namespace='MonSiteEcommerce',
    MetricData=[
        {
            'MetricName': 'PanierValide',
            'Dimensions': [
                {
                    'Name': 'Environnement',
                    'Value': 'Production'
                },
            ],
            'Value': 1,
            'Unit': 'Count'
        },
    ]
)

Avec cette approche, vous pouvez suivre sur un même dashboard le taux de conversion de votre boutique à côté de l’utilisation CPU de vos serveurs. Quand les deux courbes divergent, vous savez immédiatement qu’il y a un lien.

CloudWatch Alarms : réagir avant l’impact utilisateur

Les alarmes CloudWatch surveillent une métrique et déclenchent une action lorsqu’un seuil est franchi :

• Envoyer une notification SNS (email, SMS, Slack via Lambda)
• Déclencher un Auto Scaling (ajouter des serveurs)
• Exécuter une action EC2 (redémarrer une instance)
• Lancer une fonction Lambda de remédiation automatique

Une bonne pratique consiste à définir trois niveaux d’alerte :

1. Warning : temps de réponse > 500 ms pendant 5 minutes → notification Slack
2. Critical : temps de réponse > 2 s pendant 2 minutes → notification SMS + escalade
3. Emergency : taux d’erreurs 5xx > 10 % → auto-scaling + page d’astreinte

AWS X-Ray : le tracing distribué intégré

AWS X-Ray est le service de traces distribuées d’AWS. Il s’intègre nativement avec CloudWatch pour offrir une vue complète.

X-Ray instrumente automatiquement :

• Les appels HTTP entrants et sortants
• Les requêtes vers DynamoDB, RDS, SQS, SNS
• Les invocations Lambda
• Les appels à des API externes

Le résultat : une Service Map visuelle qui montre tous vos services, leurs interconnexions et les points de latence. Quand un client signale qu’une page est lente, vous identifiez en quelques clics que le problème vient, par exemple, d’une requête DynamoDB non indexée qui prend 800 ms au lieu de 5 ms.

Depuis 2023, X-Ray est directement intégré dans la console CloudWatch sous le nom CloudWatch ServiceLens, ce qui simplifie encore la corrélation entre logs, métriques et traces.

Mettre en place une stratégie d’observabilité efficace

Étape 1 : Définir vos SLI, SLO et SLA

Avant de collecter quoi que ce soit, définissez ce qui compte pour vos utilisateurs :

• SLI (Service Level Indicator) : la métrique mesurée. Exemple : temps de chargement de la page d’accueil.
• SLO (Service Level Objective) : l’objectif interne. Exemple : 95 % des requêtes en moins de 500 ms.
• SLA (Service Level Agreement) : l’engagement contractuel. Exemple : disponibilité de 99,9 % par mois.

Ces définitions guident tout le reste : quelles métriques collecter, quels seuils d’alerte configurer, quelle granularité de logs conserver.

Étape 2 : Instrumenter vos applications

L’observabilité commence dans le code. Ajoutez :

• Des logs structurés au format JSON (pas de texte libre) pour faciliter l’analyse automatique
• Des métriques personnalisées sur vos KPIs métier (commandes, inscriptions, erreurs de paiement)
• Le SDK X-Ray pour activer le tracing distribué

Exemple de log structuré :

{
  "timestamp": "2025-01-15T14:32:07Z",
  "level": "ERROR",
  "service": "payment-service",
  "trace_id": "1-678e1a2b-abc123",
  "message": "Payment gateway timeout",
  "gateway": "stripe",
  "response_time_ms": 30000,
  "order_id": "ORD-98765",
  "customer_id": "CUST-12345"
}

Notez la présence du trace_id : c’est ce qui permet de corréler ce log avec la trace X-Ray correspondante.

Étape 3 : Construire des dashboards orientés métier

Un dashboard efficace raconte une histoire. Structurez-le en trois niveaux :

1. Vue executive : disponibilité, chiffre d’affaires temps réel, nombre d’utilisateurs actifs
2. Vue opérationnelle : temps de réponse par service, taux d’erreurs, utilisation des ressources
3. Vue technique : détail par instance, par conteneur, par fonction Lambda

CloudWatch Dashboards permet de mélanger métriques AWS natives, métriques personnalisées, résultats de requêtes Logs Insights et widgets texte, le tout sur un même écran.

Étape 4 : Automatiser la réponse aux incidents

L’observabilité atteint son plein potentiel quand elle déclenche des actions automatiques :

• Redémarrage automatique d’un service qui ne répond plus
• Scaling horizontal quand le CPU dépasse 70 % pendant 3 minutes
• Basculement DNS vers un site de secours en cas de panne régionale
• Notification enrichie avec les logs pertinents déjà extraits

Cette automatisation, couplée à CloudWatch Composite Alarms (qui combine plusieurs alarmes en une logique AND/OR), réduit considérablement les faux positifs et le temps de réaction.

Bonnes pratiques et pièges à éviter

Ce qu’il faut faire

• Activer les detailed monitoring sur vos instances EC2 (granularité 1 minute au lieu de 5)
• Utiliser des namespaces et dimensions cohérents pour vos métriques personnalisées
• Configurer la rétention des logs selon vos obligations légales (RGPD, PCI-DSS)
• Taguer toutes vos ressources AWS pour filtrer facilement les métriques par projet, environnement ou équipe
• Exporter vos logs vers S3 pour l’archivage longue durée à moindre coût

Ce qu’il faut éviter

• Logger des données sensibles (mots de passe, numéros de carte bancaire) dans CloudWatch
• Créer trop d’alarmes sans priorisation : l’alert fatigue tue la réactivité
• Ignorer les coûts : surveillez votre consommation CloudWatch avec… CloudWatch (métrique EstimatedCharges)
• Collecter sans analyser : des téraoctets de logs inutilisés ne servent à rien sauf à augmenter la facture

Comparaison rapide : CloudWatch vs solutions tierces

Critère	AWS CloudWatch	Datadog	Grafana + Prometheus
Intégration AWS native	★★★★★	★★★★☆	★★★☆☆
Facilité de mise en place	★★★★☆	★★★★★	★★★☆☆
Coût (petit volume)	Gratuit partiel	~15 $/host/mois	Gratuit (self-hosted)
Coût (gros volume)	Compétitif	Élevé	Infra à gérer
Tracing distribué	X-Ray intégré	APM natif	Jaeger/Tempo à ajouter
Multi-cloud	AWS uniquement	Oui	Oui

Pour les architectures 100 % AWS, CloudWatch reste le choix le plus cohérent. L’intégration native élimine des couches de complexité et réduit la latence de collecte.

Cas concret : observabilité d’un site e-commerce PrestaShop sur AWS

Prenons l’exemple d’une boutique PrestaShop hébergée sur AWS avec l’architecture suivante :

• ALB (Application Load Balancer) en frontal
• 2 instances EC2 derrière l’ALB (Auto Scaling Group)
• RDS MySQL en Multi-AZ
• ElastiCache Redis pour les sessions et le cache
• S3 + CloudFront pour les médias

Voici la stratégie d’observabilité mise en place :

1. Logs Apache et PHP → CloudWatch Logs via l’agent CloudWatch
2. Logs slow queries MySQL → CloudWatch Logs via RDS enhanced monitoring
3. Métriques ALB → temps de réponse, codes HTTP, requêtes actives
4. Métriques EC2 → CPU, mémoire (via agent), réseau
5. Métriques personnalisées → nombre de commandes/heure, taux d’abandon panier
6. Alarmes → temps de réponse ALB > 1 s, CPU > 80 %, erreurs 5xx > 5 %
7. Dashboard unifié → vue temps réel combinant toutes ces données

Résultat : le MTTR (temps moyen de résolution) est passé de 45 minutes à moins de 8 minutes. Les incidents sont détectés avant que les clients ne les signalent dans 92 % des cas.

Conclusion : l’observabilité n’est pas un luxe, c’est une nécessité

En 2025, lancer un site web ou une application sans stratégie d’observabilité, c’est comme conduire de nuit sans phares. Vous avancez, mais vous ne voyez pas les obstacles.

AWS CloudWatch offre une plateforme mature, intégrée et économique pour mettre en place les trois piliers de l’observabilité : logs, métriques et traces. La clé du succès réside dans une implémentation réfléchie, alignée sur vos objectifs métier et vos contraintes techniques.

Chez Lueur Externe, nous accompagnons nos clients — des PME aux grandes enseignes — dans la conception et le déploiement de leurs architectures AWS, observabilité incluse. Certifiés AWS Solutions Architect et forts de plus de 20 ans d’expérience dans le web, nous transformons la complexité technique en avantage concurrentiel.

Vous souhaitez mettre en place ou améliorer l’observabilité de votre infrastructure AWS ? Contactez l’équipe Lueur Externe pour un audit personnalisé de votre architecture et des recommandations concrètes adaptées à votre contexte.