00 — Les 3 piliers : logs, métriques, traces

Ce que tu vas apprendre

• La différence entre monitoring et observabilité
• Les 3 piliers et ce que chacun apporte que les autres n'apportent pas
• Pourquoi un système observable se débogue en minutes là où un système monitoré prend des heures
• La carte de cette série

Monitoring ≠ Observabilité

Le monitoring consiste à vérifier des métriques prédéfinies et à déclencher des alertes quand elles franchissent un seuil. C'est une boîte noire : tu sais que quelque chose ne va pas, pas pourquoi.

L'observabilité est la capacité à comprendre l'état interne d'un système à partir de ses sorties externes. Tu peux poser des questions auxquelles tu n'avais pas pensé au moment de déployer le système.

"Monitoring tells you whether the system works. Observability lets you ask why it doesn't." — Charity Majors, Observability Engineering (2022)

En pratique : ton dashbord montre que le taux d'erreur est monté à 5%. Le monitoring t'a alerté. Mais pour savoir si c'est un timeout vers la BDD, un bug introduit par le dernier déploiement, un pic de trafic sur une route spécifique, ou un problème réseau sur une zone géographique — tu as besoin d'observabilité.

Les 3 piliers

Charity Majors, Liz Fong-Jones et George Miranda dans Observability Engineering (2022) formalisent l'observabilité autour de trois types de données complémentaires.

Pilier 1 : Les logs

Les logs sont des enregistrements d'événements discrets dans le temps. Chaque ligne correspond à quelque chose qui s'est passé.

2026-06-01T10:23:41Z INFO  {"event":"order.created","orderId":"abc-123","userId":"user-456","total":4990}
2026-06-01T10:23:41Z ERROR {"event":"payment.failed","orderId":"abc-123","reason":"card_declined","attempt":1}

Ce que les logs donnent : le contexte exact d'un événement. Le quoi et le quand, avec les données associées.

Ce qu'ils ne donnent pas : la tendance dans le temps, les agrégations, la corrélation entre services.

Pilier 2 : Les métriques

Les métriques sont des mesures numériques agrégées dans le temps. Elles répondent à des questions du type "combien", "à quelle fréquence", "quelle est la distribution".

http_requests_total{method="POST",route="/orders",status="200"} 4821
http_request_duration_seconds{route="/orders",quantile="0.99"} 0.342
memory_usage_bytes 134217728

Ce que les métriques donnent : les tendances, la détection d'anomalies, les alertes à seuil.

Ce qu'elles ne donnent pas : le contexte d'un événement particulier — une métrique dit "il y a eu 42 erreurs en 5 minutes", pas "voici le stack trace de chacune".

Pilier 3 : Les traces distribuées

Les traces sont des enregistrements du chemin d'une requête à travers les différents services d'un système.

Trace abc-456 (durée totale : 234ms)
├── Span: API Gateway          [0ms - 2ms]
├── Span: OrderService         [2ms - 180ms]
│   ├── Span: DB query         [5ms - 120ms]  ← goulot d'étranglement
│   └── Span: PaymentService   [120ms - 178ms]
└── Span: NotificationService  [180ms - 234ms]

Ce que les traces donnent : la corrélation entre services, l'identification des goulots d'étranglement, la cause d'une latence élevée.

Ce qu'elles ne donnent pas : les tendances dans le temps (une trace = une requête).

Pourquoi les 3 sont nécessaires

Un scénario concret : une alerte déclenche à 10h23 — taux d'erreur 4% sur /orders.

1. Les métriques ont déclenché l'alerte. Elles montrent que l'erreur a commencé exactement à 10h21, juste après un déploiement.
2. Les logs révèlent que les erreurs sont toutes timeout vers le service de paiement, avec un orderId qui commence par ORD-2026.
3. Les traces montrent que le span PaymentService prend 30 secondes au lieu de 200ms — le timeout est côté client, le service de paiement répond mais trop lentement.

Sans les trois, tu aurais "il y a des erreurs". Avec les trois, tu sais "le service de paiement est lent depuis 10h21 sur les commandes avec le nouveau format d'ID".

L'évolution vers OpenTelemetry

Pendant longtemps, chaque pilier avait ses propres outils incompatibles : Datadog pour les métriques, ELK pour les logs, Jaeger pour les traces. Chaque outil avait son SDK, son format, sa façon de configurer l'instrumentation.

OpenTelemetry (CNCF, lancé en 2019 depuis la fusion d'OpenTracing et OpenCensus) unifie les trois piliers sous un seul standard ouvert :

• Un seul SDK pour instrumenter ton code (logs, métriques, traces)
• Un format d'export standard (OTLP — OpenTelemetry Protocol)
• Un collecteur intermédiaire qui route vers le backend de ton choix (Jaeger, Prometheus, Datadog, Grafana Cloud...)

Tu écris l'instrumentation une fois, tu choisis le backend après.

Ce que cette série couvre

Étape suivante : 01 — Logs structurés

Sources

• Majors, C., Fong-Jones, L., & Miranda, G. (2022). Observability Engineering. O'Reilly.
• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering, Chapitre 6 "Monitoring Distributed Systems". O'Reilly. sre.google/sre-book/monitoring-distributed-systems/
• OpenTelemetry Authors. What is Observability? opentelemetry.io/docs/concepts/observability-primer/