infra / monitoring-observabilite
Les 3 piliers de l'observabilité
Explication
Un peu d'histoire
Le mot "observabilité" vient à l'origine de la théorie du contrôle, une branche des mathématiques appliquées formalisée par l'ingénieur hongro-américain Rudolf Kálmán en 1960 : un système est "observable" si on peut déduire son état interne complet à partir de ses seules sorties visibles. L'industrie du logiciel récupère ce terme au tournant des années 2010, quand les architectures monolithiques laissent place aux microservices : Google publie en 2010 son papier fondateur sur Dapper, son système de tracing distribué interne, et Twitter développe des outils similaires pour gérer sa propre explosion de services. Prometheus, l'outil central de cette leçon, naît en 2012 chez SoundCloud (Julius Volz et Matt T. Proud), directement inspiré de Borgmon, l'outil de monitoring interne de Google. Le découpage en "3 piliers" (logs, métriques, traces) se popularise ensuite via le livre "Distributed Systems Observability" de Cindy Sridharan (O'Reilly, 2018).
Pourquoi apprendre le monitoring et l'observabilité aujourd'hui
Dès qu'une application dépasse un seul serveur, deviner "pourquoi ça a planché cette nuit" à l'oreille devient impossible : il faut des données. C'est devenu une compétence quasi obligatoire pour tout poste DevOps, SRE (Site Reliability Engineer) ou backend senior, et des entreprises entières (Datadog, Grafana Labs, New Relic, Elastic) valent des milliards de dollars rien que sur ce marché. Concrètement, savoir lire un dashboard Grafana, écrire une requête PromQL ou configurer une alerte Prometheus fait souvent la différence, en entretien technique, entre un profil junior et un profil qui a déjà touché à de la vraie production.
Ce que vous allez apprendre
- Distinguer les logs, les métriques et les traces, et savoir quand utiliser lequel des trois
- Comprendre pourquoi les métriques sont peu coûteuses à stocker par rapport aux logs
- Identifier ce qu'une trace apporte que les logs et métriques seuls ne peuvent pas donner
- Visualiser l'architecture typique d'une stack d'observabilité moderne (Prometheus, Loki, Jaeger, Grafana)
- Relier un même évènement (un paiement qui échoue) à ses trois représentations possibles
Dans quel contexte ?
Imagine une astreinte de nuit chez une plateforme e-commerce : à 3h du matin, une alerte Slack tombe, "taux d'erreur de paiement à 12%". L'ingénieur de garde n'a que quelques minutes pour comprendre la situation avant que le client ne s'énerve sur Twitter. Sans logs, métriques et traces bien organisés, il devrait se connecter en SSH sur chaque serveur et lire des fichiers texte à la main — une catastrophe à l'échelle d'une infrastructure moderne avec des dizaines de services.
D'abord, une question simple : qu'est-ce qu'on observe réellement ?
On observe un système pour répondre à trois questions très différentes : "est-ce que ça va mal ?", "pourquoi ça va mal ?" et "où précisément ça va mal ?". Chacune de ces questions appelle un outil différent, ce qui explique qu'on ne se contente jamais d'un seul des trois piliers.
Les logs sont des évènements horodatés, riches en détails, mais coûteux à stocker et à interroger en masse : parfaits pour comprendre le "pourquoi" d'un cas précis, une fois qu'on sait où chercher.
Une fois les logs posés, viennent les métriques
Une métrique est un nombre agrégé dans le temps — un compteur, une jauge, une distribution — beaucoup plus léger à stocker qu'un log complet, car on ne garde qu'une valeur numérique par intervalle de temps plutôt que du texte libre.
C'est cette légèreté qui rend les métriques idéales pour la surveillance continue et l'alerting : on peut se permettre de collecter http_requests_total toutes les 15 secondes pendant des mois, ce qui serait ingérable avec des logs complets.
| Pilier | Nature | Coût de stockage | Question à laquelle il répond |
|---|---|---|---|
| Logs | Évènements discrets et détaillés | Élevé | "Pourquoi CETTE requête a échoué ?" |
| Métriques | Nombres agrégés dans le temps | Faible | "Le taux d'erreur augmente-t-il depuis 14h ?" |
| Traces | Parcours complet d'une requête | Moyen | "Quel service ralentit CETTE requête ?" |
Prérequis
Cette leçon d'introduction ne demande aucune connaissance préalable en monitoring : elle pose juste le vocabulaire commun à tout le reste du cours.
Il reste une question : pourquoi ne pas se contenter des logs et métriques ?
Dans une architecture à un seul serveur, logs et métriques suffisent presque toujours. Le problème apparaît quand une seule requête utilisateur traverse cinq, dix, ou vingt services différents : savoir que "l'API Gateway a répondu lentement" ne dit pas QUEL service, parmi tous ceux appelés en interne, est le vrai responsable.
C'est exactement le rôle des traces : elles suivent une requête unique de bout en bout, avec un temps précis passé dans chaque service traversé. C'est la seule des trois briques capable de répondre à "où" avec cette précision-là.
Astuce
Pense aux 3 piliers comme un entonnoir de diagnostic : une métrique déclenche l'alerte ("le taux d'erreur monte"), une trace localise le service coupable, et un log donne le détail exact de l'erreur dans ce service précis.
Le piège à éviter dès le départ
Beaucoup de débutants pensent qu'il faut choisir UN outil et s'y tenir. En réalité, logs, métriques et traces sont complémentaires et se combinent quasi systématiquement dans une stack de production, chacun avec son propre backend (Loki ou ELK pour les logs, Prometheus pour les métriques, Jaeger ou Tempo pour les traces), le tout unifié dans une interface comme Grafana.
Maintenant que le vocabulaire est posé, la prochaine étape logique est concrète : installer Prometheus, l'outil qui va collecter ces fameuses métriques tout au long du cours.
Commandes & code
Les 3 piliers de l'observabilité
LOGS -> évènements discrets, horodatés, avec contexte détaillé
"2026-09-04T10:32:01Z ERROR user_id=42 payment failed: card_declined"
MÉTRIQUES -> valeurs numériques agrégées dans le temps, peu coûteuses à stocker
http_requests_total{status="500"} = 1204
TRACES -> le parcours COMPLET d'une requête à travers plusieurs services
request_id=abc123 : [API Gateway 2ms] -> [Auth 15ms] -> [DB 120ms] -> [Payment 300ms]Quand utiliser quoi ?
"Le taux d'erreur a augmenté depuis 14h" -> métriques (tendance dans le temps)
"Pourquoi CETTE requête de l'utilisateur 42 a échoué" -> logs (détail contextuel précis)
"Quel service ralentit cette requête spécifique" -> traces (chemin complet, latence par étape)# Exemple concret : une même erreur vue sous les 3 angles
# 1. Log structuré (contexte riche, un évènement précis)
import logging, json
logger = logging.getLogger("payment")
def log_payment_failure(user_id: str, order_id: str, reason: str):
logger.error(json.dumps({
"event": "payment_failed",
"user_id": user_id,
"order_id": order_id,
"reason": reason,
}))
# 2. Métrique (compteur agrégé, peu coûteux, interrogeable dans le temps)
from prometheus_client import Counter
payment_failures = Counter(
"payment_failures_total", "Nombre total d'échecs de paiement", ["reason"]
)
payment_failures.labels(reason="card_declined").inc()
# 3. Trace (contexte de bout en bout, voir leçon dédiée OpenTelemetry)
# span "process_payment" -> span enfant "charge_card" -> span enfant "call_stripe_api"Architecture typique d'une stack d'observabilité :
App (logs + métriques + traces)
| | |
v v v
Loki/ELK Prometheus Jaeger/Tempo
\ | /
\ v /
Grafana (vue unifiée)Résumé
- Logs = évènements détaillés et coûteux à stocker en masse ; métriques = agrégats numériques légers ; traces = parcours bout-en-bout d'une requête.
- Les 3 piliers sont complémentaires : une métrique alerte "quoi", un log explique "pourquoi", une trace montre "où".
- Grafana sert typiquement de vue unifiée par-dessus Prometheus (métriques), Loki/ELK (logs) et Jaeger/Tempo (traces).
Exercices pratiques
Mission : astreinte de nuit sur le service paiement
Objectif : Choisir le bon pilier d'observabilité à chaque étape du diagnostic d'un incident de paiement, et produire les artefacts (log, métrique) correspondants.
Contexte
Il est 3h du matin. Une alerte Slack tombe : le taux d'erreur de paiement est passé de 0.5% à 12% depuis 14h. Tu es d'astreinte et tu dois reconstituer, dans l'ordre, comment chacun des 3 piliers t'aide à répondre à une question différente sur cet incident précis (utilisateur 42, commande ORD-4821, raison card_declined).
Réponds aux questions dans l'ordre : détection, contexte détaillé, puis localisation.