Les 3 piliers de l'observabilité : logs, métriques et traces

SECTION 1

Observabilité et monitoring : ce qui change vraiment pour vos systèmes

L'observabilité est la capacité à comprendre l'état interne d'un système à partir des signaux qu'il émet, sans avoir à prédire chaque mode de défaillance à l'avance. À mesure que les entreprises migrent vers le cloud, multiplient les microservices et mettent des chaînes d'inférence IA en production, la visibilité sur les données de performance devient à la fois plus critique et plus difficile à obtenir : une requête peut traverser des dizaines de services avant de produire une réponse, et chaque maillon est un point de défaillance potentiel.

Le monitoring répond aux questions connues d'avance : un tableau de bord affiche des indicateurs choisis, une alerte se déclenche quand un seuil est franchi. L'observabilité va plus loin : elle fournit les outils pour inspecter et corréler les données afin de répondre aux questions que personne n'avait anticipées, les fameux « unknown unknowns ». C'est cette capacité d'exploration qui fait la différence quand un incident inédit survient à trois heures du matin et que le temps de résolution se compte en chiffre d'affaires perdu.

Les logs, les métriques et les traces sont considérés comme les trois piliers de l'observabilité, car aucun d'eux n'est réellement utile sans les deux autres. En 2026, ce triptyque s'enrichit d'un quatrième signal, le profiling continu, et surtout d'un socle commun, OpenTelemetry, qui a mis fin à la fragmentation des formats propriétaires qui compliquait encore récemment toute stratégie d'instrumentation.

SECTION 2

Les logs : la granularité indispensable au débogage

Un journal d'événements associe un horodatage à un contexte : ce qui s'est produit, où, avec quelles valeurs. Les logs existent sous forme binaire, structurée ou en texte brut, et restent le pilier le plus simple à générer, la quasi-totalité des langages et des frameworks les produisent nativement. Leur force est la granularité : quand un bug rare ne touche qu'un utilisateur sur dix mille, seul le log contient le détail qui permet de reconstituer le scénario exact, avec les paramètres, l'état et l'enchaînement précis des opérations.

### Passer aux logs structurés

En production moderne, le texte libre ne suffit plus : les logs structurés, généralement en JSON, portent des champs normalisés, identifiant de requête, trace_id, tenant, version du service, qui les rendent interrogeables comme une base de données et corrélables avec les traces. Cette discipline transforme un empilement de lignes en source d'analyse exploitable, y compris par des agents IA de diagnostic qui ont besoin de champs fiables pour raisonner sur un incident.

### Maîtriser le volume et le coût des journaux

Les limites des logs sont connues : un volume qui explose avec le trafic, un coût d'indexation et de stockage qui peut dépasser celui de l'infrastructure observée, et une incapacité à pointer seuls la cause racine dans un système distribué. Les pipelines de collecte modernes y répondent par le filtrage à la source, l'échantillonnage des messages répétitifs et le stockage hiérarchisé : les données chaudes restent indexées pour la recherche, les archives partent vers de l'object storage bon marché où elles restent réhydratables en cas d'audit.

SECTION 3

Les métriques : résumer la santé du système dans le temps

Les métriques sont des valeurs numériques agrégées qui résument le comportement et la performance dans le temps : latence au 99e percentile, taux d'erreur, saturation des ressources. Peu coûteuses à produire et à stocker, faciles à interroger, elles alimentent les tableaux de bord temps réel, l'alerting et surtout les SLO, qui traduisent la fiabilité en objectifs chiffrés partagés entre équipes produit et ingénierie. Prometheus et son langage PromQL restent le standard de facto de l'écosystème cloud-native, désormais pleinement interopérables avec la collecte OpenTelemetry.

Ce sont aussi les métriques qui établissent les repères de fonctionnement normal : sans historique de référence, impossible de savoir si une latence de 300 millisecondes est un incident ou un comportement habituel du vendredi soir. Cette mémoire longue, peu coûteuse à conserver, fait des métriques le premier pilier à mettre en place quand on part de zéro.

Pour choisir quoi mesurer, deux cadres ont fait leurs preuves : les quatre golden signals du SRE, latence, trafic, erreurs, saturation, pour les services exposés aux utilisateurs, et la méthode USE, utilisation, saturation, erreurs, pour les ressources d'infrastructure. Partir de ces cadres plutôt que d'exporter toutes les métriques disponibles évite les tableaux de bord de quatre cents graphiques que personne ne consulte, et concentre l'alerting sur les symptômes qui touchent réellement les utilisateurs plutôt que sur des causes internes sans impact.

### Le piège de la cardinalité

La contrepartie de cette efficacité est la généralisation : une métrique dit combien d'utilisateurs ont souffert, jamais lesquels. Et l'ajout de labels trop fins, identifiant client, URL complète, fait exploser la cardinalité, donc la mémoire des séries temporelles et la facture. La règle éprouvée : des métriques sobres pour détecter, des traces et des logs pour expliquer, et des exemplars pour passer de l'une aux autres en un clic.

SECTION 4

Les traces distribuées : suivre chaque requête de bout en bout

Une trace représente la série d'événements déclenchés par une requête lorsqu'elle traverse l'ensemble de vos systèmes. Décomposée en spans, un par opération, avec durée, statut et métadonnées, elle rend visibles la structure et le chemin réel d'un appel : quel service a ajouté huit cents millisecondes, quelle dépendance a expiré, où la file d'attente s'est formée. En environnement microservices, c'est le seul pilier capable de reconstituer la causalité entre des dizaines de composants qui ne se connaissent pas.

### Propagation de contexte et échantillonnage

Le tracing exige que chaque composant propage le contexte de la requête, le standard W3C Trace Context s'en charge dans les en-têtes HTTP, et son coût se maîtrise par l'échantillonnage : en tête de requête (head-based) pour la simplicité, ou en fin de requête (tail-based) pour conserver systématiquement les transactions lentes ou en erreur. Une instrumentation même partielle apporte déjà des insights précieux, et l'instrumentation automatique fournie par les SDK modernes abaisse fortement le ticket d'entrée : quelques lignes de configuration suffisent pour couvrir les frameworks web, les clients HTTP et les bases de données les plus courants.

Les traces produisent en outre des sous-produits précieux : des cartes de dépendances entre services générées automatiquement, des métriques dérivées des spans, latence et taux d'erreur par opération, et la détection des dépendances inattendues introduites par un déploiement. Beaucoup d'équipes découvrent leur architecture réelle en instrumentant le tracing, souvent assez éloignée des schémas d'architecture officiels.

@cite:patterns-observabilite-systemes-distribues

SECTION 5

OpenTelemetry : le standard qui unifie logs, métriques et traces

La grande évolution de la décennie est la standardisation. OpenTelemetry, projet gradué de la CNCF, fournit un SDK par langage, un protocole de transport unique (OTLP) et des conventions sémantiques communes pour les trois piliers, tous trois stables et généralement disponibles. Instrumenter une fois et choisir librement son backend, open source ou commercial, met fin au verrouillage propriétaire des agents d'APM historiques, et le Collector OpenTelemetry sert de point de passage unique pour filtrer, enrichir et router la télémétrie.

### Le profiling continu, quatrième signal

Depuis mars 2026, le signal de profiling d'OpenTelemetry est en alpha publique, avec une disponibilité générale visée dans l'année. Collecté en continu via eBPF avec un surcoût minime, il montre quelle fonction consomme le CPU ou la mémoire, et se corrèle aux traces par trace_id et span_id. Le triptyque devient un quatuor : les traces localisent le service en cause, le profiling descend jusqu'à la ligne de code responsable, sans redéploiement ni instrumentation manuelle.

Pour les organisations encore équipées d'agents propriétaires, la migration se fait par étapes : déployer le Collector en passerelle devant le backend existant, basculer service par service vers les SDK OpenTelemetry, puis rationaliser les backends une fois la collecte unifiée. L'investissement d'instrumentation est ainsi préservé quel que soit le choix d'outillage ultérieur, un renversement complet du rapport de force avec les éditeurs d'observabilité.

SECTION 6

Corréler les signaux : des données brutes aux insights actionnables

Trois piliers stockés dans trois silos ne font pas une observabilité : la valeur naît de la corrélation. Une alerte sur une métrique doit ouvrir les traces concernées ; une trace lente doit exposer ses logs ; un log d'erreur doit remonter à la requête d'origine. Les identifiants partagés, trace_id injecté dans chaque ligne de log, exemplars reliant métriques et traces, transforment trois bases de données en un seul graphe navigable, et divisent le temps de diagnostic par autant.

C'est aussi le terrain où l'IA change la pratique quotidienne : les plateformes d'AIOps corrèlent les signaux à grande échelle, regroupent les alertes redondantes en incidents uniques et proposent des hypothèses de cause racine, tandis que des agents LLM assurent un premier tri des alertes avant l'astreinte humaine. Ces systèmes ne valent toutefois que par la qualité de la télémétrie qu'on leur fournit : sans piliers bien instrumentés et sémantiquement cohérents, pas d'IA opérationnelle utile.

Concrètement, un diagnostic corrélé ressemble à ceci : une alerte SLO signale une hausse de latence au 99e percentile ; l'exemplar attaché à la métrique ouvre une trace représentative ; la trace montre qu'un appel à la base de données consomme l'essentiel du temps ; les logs du span concerné révèlent un plan de requête dégradé après une migration. Quatre signaux, un seul enchaînement, quelques minutes au lieu de quelques heures de recherche en aveugle.

@cite:qu-est-ce-que-l-aiops

SECTION 7

Mettre en œuvre une observabilité rentable avec Adservio

Les trois piliers forment un tout : les traces relient les logs, les métriques éclairent la santé et la performance globales, et ensemble ils constituent le socle d'un système observable. Reste la question du coût, devenue centrale : la télémétrie peut représenter une part significative de la facture cloud si elle n'est pas gouvernée. Échantillonnage adapté à la criticité, filtrage dans les pipelines de collecte, durées de rétention différenciées par signal et revue régulière de la cardinalité maintiennent le rapport entre valeur produite et dépense engagée.

Chez Adservio, nous aidons les organisations à atteindre l'observabilité de leurs systèmes en nous appuyant sur les standards ouverts et les meilleures pratiques : instrumentation OpenTelemetry, définition des SLO, corrélation des signaux et maîtrise des coûts, en évitant les pièges et les anti-patterns coûteux. Plus un système est complexe, plus il a besoin d'observabilité, et plus sa mise en œuvre gagne à être guidée par l'expérience du terrain plutôt que par l'empilement d'outils.

@cite:combler-l-ecart-sre-vers-l-observabilite-autonome

FAQ

Questions fréquentes