Aller au contenu principal

Les trois piliers de l'observabilité

Résumé : l'observabilité repose sur trois types de données complémentaires. Les métriques répondent à « y a-t-il un problème ? ». Les logs répondent à « que s'est-il passé exactement ? ». Les traces répondent à « où, dans ma chaîne de services, se situe le problème ? ». Cette leçon détaille chacun, avec ses coûts et ses pièges, puis présente le quatrième pilier émergent.


1. Vue d'ensemble des trois piliers

Le point le plus important de cette leçon : ces trois piliers ne sont pas concurrents, ils s'enchaînent dans un flux de diagnostic. Une équipe qui n'aurait que des logs passerait son temps à chercher une aiguille dans une botte de foin. Une équipe qui n'aurait que des métriques saurait qu'un problème existe sans jamais pouvoir l'expliquer.


2. Pilier 1 — Les métriques

Les quatre types de métriques

Le conseil pratique le plus utile : pour la latence, utilisez toujours un histogramme, jamais une jauge de moyenne. La moyenne est trompeuse — c'est le sujet de la leçon 4.


3. Pilier 2 — Les logs

Log non structuré contre log structuré

Voici la différence concrète, qui change radicalement l'exploitabilité.

// Log non structuré : lisible par un humain, pénible pour une machine
"2026-08-06 14:32:11 ERROR Echec paiement commande 4471 montant 89.90 user 8823"

// Log structuré : interrogeable comme une base de données
{
"timestamp": "2026-08-06T14:32:11.482Z",
"level": "error",
"message": "Échec du paiement",
"service": "paiement",
"version": "2.14.3",
"order_id": 4471,
"amount": 89.90,
"currency": "EUR",
"user_id": 8823,
"payment_provider": "stripe",
"error_code": "card_declined",
"duration_ms": 1842,
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Ce que le format structuré permet et que le texte libre interdit : « montre-moi tous les échecs de paiement des dernières 24 heures, avec le code d'erreur card_declined, pour un montant supérieur à 50 euros, groupés par fournisseur de paiement ». Cette requête est immédiate sur du JSON, quasi impossible sur du texte libre.

Le champ le plus important de cet exemple : trace_id. C'est lui qui permet de relier ce log à la trace complète de la requête, et donc de faire le lien entre les piliers 2 et 3.

Les niveaux de log et leur bon usage

NiveauQuand l'utiliserFaut-il alerter ?
ERRORUne opération a échoué et nécessite une attentionSouvent oui
WARNAnomalie gérée, mais anormale (réessai réussi)Surveiller la tendance
INFOÉvénement métier notable (commande créée, connexion)Non
DEBUGDétail technique utile en investigationNon, désactivé en production
TRACEDétail très fin, rarement activéNon

Erreur très fréquente : laisser le niveau DEBUG actif en production. Le volume de logs explose, le coût suit, et l'information utile devient introuvable dans le bruit.


4. Pilier 3 — Les traces

À quoi ressemble une trace

Voilà exactement ce qu'aucune métrique ne peut vous dire. Une métrique vous indique « la latence du service commandes est de 2,3 secondes ». La trace vous montre pourquoi : 45 appels successifs au lieu d'un seul appel groupé. Le diagnostic prend quelques secondes au lieu de plusieurs heures.

Le problème « N+1 » illustré ici est extraordinairement fréquent — c'est probablement la cause de lenteur la plus courante dans les applications, et le traçage distribué le rend immédiatement visible.

L'échantillonnage


5. Le quatrième pilier émergent — le profilage continu

Pourquoi en parler dans un cours découverte : le profilage continu apparaît de plus en plus dans les offres d'emploi et les discussions techniques. Savoir qu'il existe et à quelle question il répond vous distingue déjà de la majorité des candidats.


6. Le tableau comparatif des piliers

CritèreMétriquesLogsTracesProfils
QuestionY a-t-il un problème ?Que s'est-il passé ?Où dans la chaîne ?Quelle ligne de code ?
NatureNombres agrégésÉvénements textuelsParcours de requêteÉchantillons processeur
Coût de stockageTrès faibleÉlevéMoyenFaible à moyen
Haute cardinalitéNonOuiOuiPartiellement
Conservation typiqueMois à annéesJours à semainesJoursJours
Usage principalAlerterDiagnostiquerLocaliserOptimiser
Outil courantPrometheusLoki, ELKJaeger, TempoPyroscope

Ce que ce tableau permet de décider : si votre budget d'observabilité est contraint, l'ordre de priorité est clair. Métriques d'abord (coût minime, valeur immédiate), logs structurés ensuite (avec une conservation courte et raisonnée), traces quand vous dépassez trois ou quatre services.


7. Comment les relier — la corrélation

C'est ce qui distingue une bonne installation d'une installation médiocre.

La différence pratique est spectaculaire. Sans corrélation, un ingénieur ouvre trois interfaces différentes et tente de faire correspondre des horodatages à la main. Avec corrélation, il navigue d'un clic de l'alerte à la ligne de code fautive. C'est souvent la différence entre vingt minutes et deux heures de diagnostic.


Retenir en 30 secondes

  • Métriques« y a-t-il un problème ? ». Peu coûteuses, agrégées, base des alertes. Faible cardinalité uniquement.
  • Logs« que s'est-il passé exactement ? ». Détail maximal, volume et coût élevés. Toujours structurés (JSON).
  • Traces« où dans ma chaîne de services ? ». Indispensables au-delà de trois ou quatre services.
  • Profils (4e pilier émergent) → « quelle ligne de code ? ». Pyroscope, Parca.
  • Les piliers s'enchaînent : métrique alerte → trace localise → logs détaillent.
  • Quatre types de métriques : compteur, jauge, histogramme (le bon choix pour la latence), résumé.
  • Pour les logs, préférez l'échantillonnage en queue des traces : gardez 100 % des erreurs et des lenteurs.
  • Ne laissez jamais le niveau DEBUG actif en production — le volume et le coût explosent.
  • La corrélation par identifiant de trace est ce qui distingue une bonne installation. Standard : W3C Trace Context.
  • Ordre de priorité si budget contraint : métriques → logs structurés → traces.

Suivant : Que mesurer exactement ? Les quatre signaux dorés →