Observabilité : logs, métriques et traces

L'observabilité est la capacité à comprendre ce qui se passe à l'intérieur d'un système en lisant seulement ce qu'il produit : ses logs, ses métriques et ses traces. Là où le monitoring détecte les pannes que vous aviez prévues, l'observabilité permet de diagnostiquer celles que personne n'avait imaginées. Cette leçon s'adresse aux développeurs et aux ops qui exploitent des systèmes distribués : elle explique les trois piliers, leur corrélation par un identifiant commun, le piège de la cardinalité et la place d'OpenTelemetry.

Il est 3 h du matin. Un client signale que ses paiements échouent depuis une heure. Vos tableaux de bord affichent un CPU normal, une mémoire normale et un taux d'erreur global de 0,3 % : tout est vert. Pourtant, quelque chose ne va pas.

Vous passez deux heures à fouiller les logs de six services, à reconstituer le parcours de la requête comme on recolle les tessons d'une poterie. À 5 h, vous trouvez enfin : un timeout sur l'API bancaire, déclenché seulement au-dessus de 500 €, parce qu'un contrôle anti-fraude externe était en panne. Votre monitoring disait que tout allait bien ; votre système n'était simplement pas observable.

Ce que vous allez apprendre

Cette leçon prolonge les SLO et error budgets : un SLO ne se pilote que si l'on sait mesurer le service et comprendre ses écarts. Elle pose le vocabulaire que les leçons de garde et d'incidents utiliseront.

• Distinguer le monitoring, qui répond aux questions prévues, de l'observabilité, qui explore l'inconnu.
• Identifier le rôle et les limites des trois piliers : logs, métriques, traces.
• Corréler les signaux par un trace_id pour diagnostiquer en minutes plutôt qu'en heures.
• Maîtriser la cardinalité pour éviter l'explosion des coûts de stockage.
• Choisir un cadre de métriques, RED, USE ou Golden Signals, et situer OpenTelemetry.
• Comprendre pourquoi l'observabilité sert aussi la sécurité, et comment elle peut fuiter des secrets.

Ces objectifs tiennent dans un périmètre précis : la leçon garde ce dont un parcours DevSecOps a besoin, soit les trois piliers, la corrélation, la cardinalité, les cadres RED, USE et Golden Signals, OpenTelemetry et le lien avec la sécurité. La distinction entre monitoring et observabilité n'y est qu'esquissée (tableau et deux sous-sections). Son historique, ses limites détaillées, les critères pour passer de l'un à l'autre et un scénario d'enquête complet sont dans la leçon Observabilité vs monitoring de la formation Observabilité.

Quelle différence entre monitoring et observabilité ?

Le monitoring vérifie des seuils que vous avez définis à l'avance ; l'observabilité vous laisse poser, après coup, des questions que vous n'aviez pas prévues. Les deux termes sont souvent pris pour des synonymes, alors qu'ils répondent à deux besoins distincts. Le tableau résume l'écart, que les deux sous-sections détaillent.

Aspect	Monitoring	Observabilité
Question	« Est-ce que X dépasse le seuil Y ? »	« Pourquoi le système se comporte-t-il ainsi ? »
Approche	Questions prédéfinies	Questions ad hoc, exploration
Force	Détecter les problèmes connus	Diagnostiquer les problèmes inconnus
Limite	Ne voit que ce qu'on lui demande	Demande une instrumentation riche

Glissez pour voir

Le monitoring répond aux questions connues

Le monitoring traditionnel repose sur un principe simple : vous décidez à l'avance quoi surveiller, vous posez des seuils, et une alerte part quand l'un d'eux est franchi. C'est une approche par questions prédéfinies.

Une alerte « CPU > 90 % » pose une question formulée en amont : « le CPU dépasse-t-il 90 % ? ». Le monitoring excelle donc sur les pannes connues, celles qu'on a déjà vécues ou anticipées. Face à l'inattendu, il reste muet : quand un utilisateur dit « c'est lent » et que tout est au vert, il ne sait répondre qu'aux questions qu'on lui a apprises.

L'observabilité permet de poser des questions nouvelles

Un système est observable si vous pouvez comprendre son état interne en analysant ses seules sorties, sans modifier son code ni le redéployer. Le terme vient de la théorie du contrôle, où il désigne exactement cette propriété.

Reprenons le scénario d'ouverture. Avec un système observable, vous partez du symptôme (« paiements échoués pour ce client »), vous filtrez les traces de ce client, vous voyez quel service pose problème, puis vous lisez les logs de ce service. Au lieu de deux heures de fouille, quelques minutes d'investigation structurée.

Quels sont les trois piliers de l'observabilité ?

Les trois piliers de l'observabilité sont les logs, qui racontent chaque événement, les métriques, qui agrègent des mesures dans le temps, et les traces, qui suivent une requête de service en service. Chacun éclaire le système sous un angle différent, et c'est leur combinaison qui donne une compréhension complète. Le schéma montre comment un même identifiant les relie.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Pilier	Rôle	Force	Faiblesse
Logs	Récit détaillé des événements	Débogage, audit, conformité	Volume énorme, coût de stockage
Métriques	Vue d'ensemble agrégée	Tendances, alertes, tableaux de bord	Pas de détail individuel
Traces	Parcours d'une requête	Goulots d'étranglement, dépendances	Complexité de mise en place

Glissez pour voir

Les logs : le récit détaillé

Un log est un enregistrement horodaté d'un événement : il raconte ce qui s'est passé dans le système, ligne après ligne, comme un journal de bord. Un log bien structuré ressemble à ceci :

{
  "timestamp": "2026-01-10T14:32:15.123Z",
  "level": "ERROR",
  "service": "payment-api",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user_id": "usr_456",
  "message": "Payment failed",
  "error_code": "CARD_DECLINED",
  "amount": 99.99,
  "currency": "EUR"
}

Chaque champ apporte du contexte. Le timestamp dit quand, le service dit où, et le trace_id relie ce log aux autres événements de la même requête. Les champs métier (amount, currency) donnent l'impact réel. Le trace_id suit ici le format du standard W3C Trace Context : 32 caractères hexadécimaux.

Les logs brillent pour le débogage détaillé, l'audit et la conformité : ils prouvent qui a fait quoi, et quand. Leur faiblesse est le volume : une application peut produire des gigaoctets par jour, et répondre à « combien d'erreurs de paiement cette semaine ? » en parcourant des millions de lignes reste pénible.

Le piège des logs non structurés

Un log en texte libre (« Error: payment failed for user John ») ne se filtre ni ne s'agrège à grande échelle. Adoptez du JSON avec des champs standardisés dès le départ : reprendre le format après coup coûte cher.

Le guide Les logs : comprendre le signal le plus riche détaille les niveaux de log, le pipeline de collecte et le requêtage à grande échelle.

Les métriques : la vue d'ensemble

Une métrique est une mesure numérique suivie dans le temps : combien de requêtes, quel temps de réponse, quel taux d'erreur. Là où les logs racontent des histoires individuelles, les métriques donnent la vue d'ensemble. Voici deux métriques au format d'exposition de Prometheus, l'outil de métriques le plus répandu :

# HELP http_requests_total Requêtes HTTP traitées.
# TYPE http_requests_total counter
http_requests_total{service="payment-api",status="500"} 142
# HELP http_request_duration_seconds Durée des requêtes HTTP.
# TYPE http_request_duration_seconds summary
http_request_duration_seconds{service="payment-api",quantile="0.99"} 2.3
http_request_duration_seconds_sum{service="payment-api"} 5120.4
http_request_duration_seconds_count{service="payment-api"} 12873

La première compte les requêtes terminées en erreur 500. La seconde donne le temps de réponse au 99e percentile : 2,3 secondes signifie que 99 % des requêtes sont servies en moins de 2,3 secondes. Les labels entre accolades (service, status) découpent chaque métrique en séries temporelles.

Les métriques forment quatre familles. Les counters ne font qu'augmenter (requêtes totales, erreurs cumulées). Les gauges montent et descendent (mémoire utilisée, connexions actives). Les histogrammes répartissent les valeurs par intervalles (buckets) pour reconstruire une distribution au moment de la requête. Les summaries calculent les percentiles côté application, comme le quantile="0.99" ci-dessus : plus légers à interroger, mais impossibles à agréger entre plusieurs instances d'un même service.

Le nommage se vérifie avec promtool, l'outil livré avec Prometheus. Sur l'exemple ci-dessus enregistré dans metrics.txt, la commande suivante ne renvoie rien et sort en code 0 (testé avec Prometheus 3.7.3) :

docker run --rm -i --entrypoint promtool \
  prom/prometheus:v3.7.3@sha256:49214755b6153f90a597adcbff0252cc61069f8ab69ce8411285cd4a560e8038 \
  check metrics < metrics.txt

Une métrique nommée api_latency_ms est en revanche refusée, avec le code 3 et ce message : metric names should not contain abbreviated units. La convention Prometheus veut des unités de base en toutes lettres, d'où http_request_duration_seconds.

Les métriques brillent pour les tendances et les alertes : « le taux d'erreur augmente-t-il ? » est une question triviale avec elles, pénible avec des logs seuls. Mais elles ne disent pas le pourquoi, et elles perdent le détail individuel : impossible d'y retrouver la requête précise qui a échoué pour un client. Le guide Les métriques : le signal compact et rapide détaille les conventions de nommage de chaque type.

Les traces : le chemin de la requête

Une trace suit le parcours d'une requête à travers les services d'un système distribué. Dans une architecture en microservices, une requête peut traverser dix services avant de revenir à l'utilisateur ; la trace capture ce voyage. Elle se compose de spans, une span par opération : un appel HTTP, une requête en base, un traitement interne.

Trace: 4bf92f35… (durée totale : 850 ms)
├── api-gateway (12 ms)
│   └── auth-service (45 ms)
├── payment-api (650 ms)  ← goulot d'étranglement
│   ├── fraud-check (120 ms)
│   └── bank-api (480 ms)  ← appel externe lent
└── notification-service (35 ms)

D'un coup d'œil, on voit que 650 ms sur 850 ms se passent dans payment-api, dont 480 ms dans l'appel externe à l'API bancaire. Le goulot d'étranglement saute aux yeux, et les dépendances entre services apparaissent, y compris des appels dont l'équipe ignorait l'existence.

La contrepartie est la mise en place : chaque service doit propager le contexte de trace au suivant. À grande échelle, l'échantillonnage devient nécessaire, car on ne stocke pas 100 % des traces. Le guide Traces distribuées : spans, propagation et sampling détaille la propagation W3C et les stratégies d'échantillonnage.

Comment corréler logs, métriques et traces ?

On corrèle les trois piliers grâce à un identifiant unique, le trace_id, créé à l'entrée de chaque requête puis propagé à tous les services et inscrit dans chaque log et chaque span. Seul, chaque pilier reste partiel : les métriques disent quoi, les traces disent où, les logs disent pourquoi. Reliés, ils forment un parcours de diagnostic continu.

Dans les faits, une alerte se déclenche : « taux d'erreurs 500 > 5 % sur payment-api ». C'est la métrique qui prévient. Vous filtrez les traces en erreur des quinze dernières minutes et voyez que 80 % d'entre elles ont une span bank-api en timeout : la trace montre où.

Vous ouvrez une de ces traces et lisez les logs associés par leur trace_id : « External API returned RATE_LIMIT_EXCEEDED ». Le log explique pourquoi. En cinq minutes, la cause est trouvée : un batch de réconciliation lancé par la finance a saturé les quotas de l'API bancaire. Vous suspendez le batch, les erreurs s'arrêtent.

Sans corrélation, vous auriez eu trois outils et trois vues partielles, à relier à la main. Ce même fil sert ensuite au postmortem, que la leçon Incidents et postmortems apprend à mener. Le guide Corrélation des signaux détaille la propagation du trace_id, y compris à travers les files de messages.

Pourquoi la cardinalité fait-elle exploser les coûts ?

La cardinalité d'une métrique est le nombre de combinaisons uniques de valeurs de ses labels ; chaque combinaison crée une série temporelle à stocker et à interroger. Une métrique avec un label service (5 valeurs) et un label status (5 valeurs) produit 25 séries : une faible cardinalité, parfaitement gérable.

Ajoutez un label user_id sur un million d'utilisateurs, et vous passez à 5 × 5 × 1 000 000, soit 25 millions de séries. La base de métriques grossit d'autant, et des requêtes qui répondaient en millisecondes deviennent lentes ou échouent. C'est le piège invisible : une ligne de code ajoutée en revue suffit à le déclencher.

La règle est simple : jamais de label à valeurs illimitées. Identifiants d'utilisateur, de requête ou de session, adresses e-mail : ces valeurs vont dans les logs, conçus pour stocker des événements individuels, et pas dans les métriques, conçues pour agréger. Les labels à cardinalité maîtrisée ont un nombre fini et prévisible de valeurs : service, endpoint, status_code, region, environment.

Quelles métriques suivre en premier : RED, USE ou Golden Signals ?

Pour démarrer, suivez les Golden Signals sur vos services critiques, RED sur chaque service qui reçoit des requêtes, et USE sur les ressources (CPU, mémoire, disque, réseau). Ces trois cadres évitent de partir de zéro face à un nouveau système, et ils se recoupent largement. Le tableau aide à choisir.

Cadre	Cible	Métriques	Quand l'utiliser
RED	Services (API)	Rate, Errors, Duration	Microservices, points d'entrée utilisateur
USE	Ressources (infra)	Utilization, Saturation, Errors	CPU, mémoire, disque, réseau
Golden Signals	Services critiques	Latency, Traffic, Errors, Saturation	Alerting de production, SRE

Glissez pour voir

Le modèle RED pour les services

Le modèle RED, proposé par Tom Wilkie, mesure trois choses sur tout service qui reçoit des requêtes. Le Rate : combien de requêtes par seconde. Les Errors : quelle part échoue. La Duration : combien de temps elles prennent. Une chute du débit peut trahir une panne en amont, une hausse des erreurs une régression, une hausse de la durée une saturation qui approche.

Le modèle USE pour les ressources

Le modèle USE, formalisé par Brendan Gregg, s'applique à chaque ressource. L'Utilization : quelle part de la capacité est occupée. La Saturation : du travail attend-il son tour ? Les Errors : la ressource renvoie-t-elle des erreurs ? Un CPU à 75 % avec une file d'attente vide est sain ; le même CPU avec une file qui s'allonge est saturé, même si son utilisation ne semble pas critique.

Les Golden Signals de Google SRE

Les quatre signaux dorés viennent du livre Site Reliability Engineering de Google, au chapitre consacré à la surveillance des systèmes distribués. La Latency mesure le temps de réponse, en séparant les succès des erreurs : une erreur rapide ne veut pas dire la même chose qu'une erreur après timeout. Le Traffic quantifie la demande, les Errors comptent les échecs, et la Saturation indique la marge de capacité restante. Le livre les présente comme le minimum à suivre si l'on ne peut en mesurer que quatre.

Commencez petit

Mieux vaut quatre métriques bien comprises que cent métriques ignorées. Commencez par les Golden Signals, et n'ajoutez une métrique que lorsqu'un diagnostic l'exige.

Qu'apporte OpenTelemetry ?

OpenTelemetry (OTel) est le standard ouvert qui permet d'instrumenter une application une seule fois pour ses logs, ses métriques et ses traces, puis d'envoyer ces données vers n'importe quel outil compatible. Avant lui, chaque outil imposait ses formats et ses SDK : passer de Jaeger à Zipkin, ou de Prometheus à Datadog, obligeait à réinstrumenter tout le code.

Le projet est porté par la CNCF (Cloud Native Computing Foundation), qui a annoncé sa graduation le 21 mai 2026. C'est son plus haut niveau de maturité, celui de Kubernetes et de Prometheus. Le protocole d'échange, OTLP, est devenu la langue commune des agents et des backends.

L'architecture compte trois éléments. L'application est instrumentée avec le SDK OTel. Le Collector reçoit les données de plusieurs applications, les filtre ou les échantillonne, puis les route vers une ou plusieurs destinations. Les backends stockent et analysent. Ce découplage permet de changer de backend sans toucher au code applicatif.

Un quatrième signal progresse : le profiling continu, des captures CPU et mémoire au niveau du code, corrélées aux traces. Côté OpenTelemetry, le signal profiles n'est qu'en alpha publique depuis mars 2026 : les trois piliers historiques restent le socle à maîtriser d'abord. Le guide OpenTelemetry : le standard d'instrumentation universel détaille l'API, le SDK, le Collector et OTLP pas à pas.

Pourquoi l'observabilité sert-elle aussi la sécurité ?

L'observabilité sert la sécurité parce que les mêmes signaux qui expliquent une panne révèlent aussi une attaque : un pic d'erreurs d'authentification, un appel sortant vers un domaine inconnu, un service qui lit soudain une base qu'il n'interroge jamais. Sans ces données, une intrusion passe pour un incident de performance, ou passe inaperçue.

Les logs fournissent la piste d'audit : qui s'est connecté, qui a modifié quoi, depuis où. Les traces dessinent la carte réelle des appels, et un appel qui n'y figurait pas hier mérite une question. La détection runtime, comme celle de la leçon Détection runtime avec Falco, s'appuie sur ces mêmes événements pour lever une alerte de sécurité.

Le revers est réel : l'observabilité est aussi une source de fuite. Un log qui écrit un en-tête Authorization, une trace qui capture un jeton dans ses attributs, un label qui porte une adresse e-mail : ces données partent vers des outils que beaucoup plus de monde consulte que la base de production. Le guide Fuites de secrets : logs, Docker, variables montre comment masquer ces valeurs avant qu'elles quittent l'application.

Quelles bonnes pratiques adopter au quotidien ?

L'observabilité n'est pas un outil qu'on installe une fois, mais une discipline qui s'intègre au développement de chaque service. Les pratiques ci-dessous se rangent par pilier ; elles évitent les pièges décrits plus haut et gardent les coûts sous contrôle.

Pour les logs, adoptez un format structuré (JSON) avec un schéma commun dès le premier jour, et incluez toujours le trace_id. Réservez le niveau ERROR aux vraies erreurs, échantillonnez les logs DEBUG en production, et filtrez les données sensibles avant l'écriture.

Pour les métriques, traitez la cardinalité comme une règle d'or. Préférez les percentiles (p50, p90, p99) à la moyenne, qui masque les valeurs extrêmes subies par les utilisateurs. Nommez en unités de base, vérifié par promtool, et alertez sur les symptômes (latence vue par l'utilisateur) plutôt que sur les causes (CPU élevé).

Pour les traces, propagez le contexte à travers tous les services, files de messages comprises. Échantillonnez avec discernement : toutes les requêtes en erreur, une fraction du trafic normal. Ajoutez des attributs métier aux spans et instrumentez les appels externes, où se cache souvent la latence.

Enfin, une alerte qui sonne pour rien et une enquête refaite à la main chaque semaine sont du toil, ce travail répétitif que la leçon Éliminer le toil apprend à réduire. Pour aller au-delà de cette leçon, la section Fondamentaux de l'observabilité traite chaque pilier et la gouvernance des coûts en détail.

À retenir

1. Le monitoring répond aux questions que vous avez anticipées ; l'observabilité permet d'en poser de nouvelles face à l'inconnu.
2. Les trois piliers apportent chacun un angle : les logs le détail, les métriques la tendance, les traces le parcours.
3. La corrélation par un trace_id commun transforme trois vues partielles en un diagnostic de quelques minutes.
4. La cardinalité est le facteur de coût à surveiller : les valeurs illimitées (user_id, request_id) vont dans les logs, jamais dans les labels de métriques.
5. RED, USE et Golden Signals cadrent vos métriques selon que vous surveillez un service, une ressource ou un système critique.
6. OpenTelemetry, gradué par la CNCF le 21 mai 2026, permet d'instrumenter une fois et de changer de backend sans toucher au code.
7. L'observabilité sert la sécurité (audit, détection) et peut aussi fuiter des secrets : filtrez ce qui part dans les logs et les traces.

Contrôle de connaissances

Vérifiez que vous avez retenu l'essentiel de ce guide. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Qu'est-ce que l'observabilité ?

Quelle est la différence entre monitoring et observabilité ?

Quels sont les trois piliers de l'observabilité ?

Qu'est-ce que la cardinalité en observabilité ?

Qu'est-ce qu'OpenTelemetry ?

Comment corréler logs, métriques et traces ?

L'observabilité sert-elle aussi la sécurité ?

×

📖 Voir la documentation →