Observabilité : journaux, métriques et traces

Supervision et observabilité

La supervision (monitoring) consiste à collecter des mesures et des vérifications prédéfinies et à déclencher une alarme quand elles franchissent un seuil : disque plein à 90 %, taux d’erreur supérieur à 1 %, contrôle de santé en échec. Elle répond à des questions que vous saviez devoir poser à l’avance. L’observabilité est une propriété du système : la mesure dans laquelle vous pouvez comprendre son état interne, y compris des états que personne n’avait prévus, à partir de la télémétrie qu’il émet déjà, sans déployer de nouveau code pour le découvrir. Le mot vient de la théorie de la commande, où Rudolf Kálmán l’a défini en 1960 comme la capacité de déduire l’état interne d’un système à partir de ses sorties.

La distinction compte, car les systèmes distribués tombent surtout en panne de façons nouvelles. Une commande de livraison de repas peut être lente parce que l’app tablette d’un restaurant multiplie les nouvelles tentatives de façon agressive, parce que l’endpoint d’un prestataire de paiement est dégradé dans une région, ou parce qu’une nouvelle fonctionnalité de la carte rend une requête de base de données lente, uniquement pour les restaurants qui ont plus de 500 articles. Personne n’a créé de tableau de bord pour aucun de ces cas. La supervision vous dit que le paiement est lent ; l’observabilité vous permet de demander pour qui, où et pourquoi, en découpant la télémétrie selon n’importe quel attribut jusqu’à ce que le motif apparaisse.

Les praticiens ne s’accordent pas sur la portée de cette distinction. Une vision, répandue chez les éditeurs d’outils, présente l’observabilité comme un parapluie couvrant trois piliers : journaux, métriques et traces. Charity Majors, Liz Fong-Jones et George Miranda (Observability Engineering, O’Reilly, 2022) soutiennent que ce cadrage en piliers passe à côté de l’essentiel, et que l’observabilité exige des événements riches, structurés et à forte cardinalité, que l’on peut interroger selon des combinaisons arbitraires. Les deux camps s’accordent sur la conséquence architecturale : l’observabilité est un attribut de qualité qui doit être intégré dès la conception, grâce à une instrumentation cohérente, à des identifiants partagés et à la propagation du contexte, car on ne peut pas l’ajouter après coup pendant un incident.

Journalisation structurée (structured logging)

Une ligne de journal comme Payment failed for order 81F3 after 3001ms est facile à écrire et difficile à exploiter : chaque recherche nécessite une expression régulière fragile, et chaque développeur formule les choses différemment. La journalisation structurée (structured logging) écrit chaque entrée sous forme de champs clé-valeur, généralement en JSON, avec des noms convenus : horodatage, niveau, service, nom de l’événement, identifiants métier (commande, restaurant, livreur), résultat, durée, ainsi que les identifiants de trace et de span qui relient la ligne à sa trace. Les recherches deviennent précises (tous les événements card_authorisation_failed pour le prestataire cardco au cours de la dernière heure, regroupés par http_status), et les journaux de différents services peuvent être joints.

Quelques règles gardent les journaux utiles et abordables. Journalisez des événements, pas de la prose ; utilisez un nom d’événement fixe pour chaque type d’événement. Utilisez les niveaux de façon cohérente, et ne journalisez pas au niveau erreur des situations qui ne demandent aucune action. Ne journalisez jamais de secrets, de jetons, de numéros de carte complets ni de données personnelles inutiles ; les pipelines de télémétrie sont copiés, envoyés à des tiers et conservés pendant des mois : ils sont donc une source courante de fuites de données, et les données personnelles présentes dans les journaux relèvent du RGPD comme toute autre copie (section 8.7). La journalisation et la détection de sécurité, un objectif voisin mais différent, avec ses propres besoins de conservation et d’intégrité, sont traitées à la section 8.8.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             version-trace id (16 bytes)-parent span id (8 bytes)-flags (01 = sampled)

{"ts": "2026-10-22T12:31:07.412Z", "level": "error",
 "service": "payment-service", "event": "card_authorisation_failed",
 "order_id": "ord_81F3", "provider": "cardco", "http_status": 504,
 "duration_ms": 3001, "attempt": 2,
 "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "span_id": "00f067aa0ba902b7"}

Les métriques, et pourquoi les percentiles ne se moyennent pas

La plupart des systèmes de métriques, comme Prometheus (projet « graduated » de la CNCF) et le modèle de métriques d’OpenTelemetry, proposent les mêmes quelques types. Un compteur (counter) ne fait qu’augmenter, comme le nombre total de requêtes servies ; vous le lisez sous forme de taux (requêtes par seconde sur les cinq dernières minutes), ce qui résiste aussi aux redémarrages. Une gauge (jauge) est une valeur courante qui monte et descend : longueur d’une file d’attente, connexions utilisées, mémoire. Un histogramme répartit les observations dans des compartiments, ou buckets (par exemple requêtes de moins de 50 ms, de moins de 100 ms, de moins de 250 ms, etc.), avec en plus un nombre total et une somme, à partir desquels on estime les percentiles. Prometheus a aussi un type summary, qui calcule des quantiles à l’intérieur de chaque processus.

La distinction entre histogrammes et summaries n’est pas un détail. Comme l’a noté la section 2.4, un percentile est une propriété d’une distribution entière, et le percentile d’une distribution combinée ne peut pas être calculé à partir des percentiles de ses parties. Faire la moyenne de valeurs de p99 entre serveurs, ou entre minutes, produit un nombre qui n’est le percentile de rien. Les nombres par compartiment, en revanche, peuvent simplement être additionnés : additionnez chaque compartiment sur tous les serveurs, puis estimez le percentile à partir de l’histogramme fusionné. C’est pourquoi les SLI de latence à l’échelle d’un parc doivent reposer sur des histogrammes (ou sur des nombres de requêtes sous un seuil, comme dans la section 9.5), jamais sur des summaries par instance.

Que mesurer : RED, USE et les signaux d’or

Trois courtes listes de contrôle couvrent l’essentiel de ce qu’un service doit exposer. La méthode RED, proposée par Tom Wilkie en 2015, s’applique à tout ce qui sert des requêtes : Rate (le débit, en requêtes par seconde), Errors (les requêtes en échec par seconde) et Duration (la distribution des temps de réponse). La méthode USE, de Brendan Gregg, s’applique aux ressources : pour chaque CPU, disque, lien réseau, pool de connexions et file d’attente, vérifiez l’Utilisation (son degré d’occupation), la Saturation (la quantité de travail en attente) et les Errors (erreurs). Les quatre signaux d’or (four golden signals) du chapitre du livre SRE de Google consacré à la supervision des systèmes distribués sont la latence, le trafic, les erreurs et la saturation : en pratique, RED plus la saturation.

En pratique, RED décrit ce que vivent les utilisateurs et USE explique pourquoi. Si la durée du service de paiement augmente (RED), USE appliqué à ses ressources peut révéler un pool de connexions utilisé à 100 % avec 40 requêtes en attente (saturation), ce qui désigne à son tour le prestataire de cartes lent qui garde des connexions ouvertes. Mesurez la latence séparément pour les réussites et pour les échecs : une erreur rapide n’est pas une bonne latence, et un délai d’expiration (timeout) est à la fois une erreur et une réponse lente.

Traçage distribué (distributed tracing)

Dans un monolithe, une pile d’appels (stack trace) montre où une requête lente a passé son temps. Entre services, il n’y a pas de pile unique. Le traçage distribué (distributed tracing) en reconstruit une : chaque requête reçoit un identifiant de trace à la périphérie, chaque unité de travail devient un span (avec un nom, une heure de début, une durée, un statut, des attributs et l’identifiant de son span parent), et un backend de traçage assemble les spans en arbre. L’article de Google sur Dapper (Sigelman et ses collègues, 2010) a décrit l’approche à grande échelle : un faible surcoût, une instrumentation dans des bibliothèques partagées plutôt que dans le code applicatif, et un échantillonnage pour que seule une fraction des requêtes soit enregistrée.

Le traçage dépend entièrement de la propagation du contexte : chaque service doit transmettre le contexte de trace au suivant. La spécification W3C Trace Context (recommandation du W3C depuis 2020) la normalise pour HTTP avec un en-tête traceparent qui contient une version, un ID de trace de 16 octets, l’ID de 8 octets du span appelant et des indicateurs, par exemple si la trace est échantillonnée, ainsi qu’un en-tête tracestate facultatif pour les données propres aux fournisseurs. Pour la messagerie, les mêmes valeurs circulent dans les en-têtes des messages, et le span du consommateur fait référence à celui du producteur. Un seul service qui perd l’en-tête (une vieille bibliothèque, un client HTTP écrit à la main, un traitement par lots) casse toutes les traces qui passent par lui : c’est pourquoi la propagation a sa place dans les bibliothèques partagées de la plateforme, et non dans le code de chaque équipe.

Enregistrer chaque span de chaque requête coûte cher à grande échelle, si bien que les traces sont échantillonnées. L’échantillonnage en tête (head-based sampling) décide au début de la requête (en garder 1 sur 100) et coûte peu, mais il écarte la plupart des requêtes lentes ou en échec, rares, qui vous intéressent. L’échantillonnage en queue (tail-based sampling) met les spans en mémoire tampon jusqu’à la fin de la requête, puis conserve toutes les erreurs, toutes les requêtes plus lentes qu’un seuil et une petite fraction du reste ; il demande plus de mémoire dans le collecteur, mais garde les traces intéressantes.

OpenTelemetry : un standard unique pour l’instrumentation

Jusque vers 2019, chaque fournisseur de traçage et de supervision avait ses propres agents et bibliothèques, si bien que changer de fournisseur obligeait à réinstrumenter chaque service. OpenTelemetry (OTel) est né en 2019 de la fusion de deux projets open source antérieurs, OpenTracing et OpenCensus, sous l’égide de la Cloud Native Computing Foundation (CNCF), et a atteint le stade de projet « graduated » de la CNCF en mai 2026. Il fournit des API et des SDK pour chaque langage, une instrumentation automatique pour les frameworks et clients courants, le protocole de transport OTLP, le Collector, et des conventions sémantiques qui fixent les noms d’attributs comme http.request.method et http.response.status_code, afin que la télémétrie de différentes équipes et de différents langages concorde. Les traces, les métriques et les journaux sont stables ; les profils ont été ajoutés comme quatrième signal et sont entrés en alpha publique en 2026.

L’intérêt architectural tient à la séparation entre l’instrumentation et le backend. Les services émettent de l’OTLP vers un Collector, qui tourne généralement à côté de chaque nœud ou comme passerelle centrale ; le Collector regroupe les données par lots, les échantillonne, supprime les attributs sensibles, ajoute des métadonnées comme la version déployée, et les exporte vers les stockages qu’utilise l’organisation, quels qu’ils soient. Changer de fournisseur, ou envoyer les mêmes données à deux backends pendant une migration, devient une modification de configuration du Collector au lieu d’une modification de code dans deux cents services. Une équipe plateforme fournit généralement la configuration du SDK, la propagation et le Collector sous forme de chemin balisé (paved road), si bien que les équipes produit n’ont qu’à ajouter des attributs métier.

from opentelemetry import trace
import structlog

tracer = trace.get_tracer("order-service")
log = structlog.get_logger()

def place_order(order):
    with tracer.start_as_current_span("place_order") as span:
        span.set_attribute("restaurant.id", order.restaurant_id)
        span.set_attribute("order.item_count", len(order.items))
        quote = pricing.quote(order)       # instrumented HTTP client adds
        payment.authorise(order, quote)    # the traceparent header itself
        log.info("order_placed", order_id=order.id,
                 total_pence=quote.total_pence)
        return order.id

Cardinalité et coût

La télémétrie peut facilement coûter plus cher que le système qu’elle observe. Pour les métriques, le principal facteur de coût est la cardinalité : chaque combinaison distincte de valeurs d’étiquettes est une série temporelle distincte qu’il faut stocker et indexer. Les étiquettes qui ont peu de valeurs (méthode HTTP, classe de statut, région) ne posent pas de problème. Les étiquettes aux valeurs non bornées (ID d’utilisateur, ID de commande, URL complète contenant des identifiants, texte d’un message d’erreur) multiplient les séries sans limite et peuvent faire tomber un système de métriques.

Les autres leviers de coût sont l’échantillonnage des traces (l’échantillonnage en queue conserve les traces utiles), une conservation plus courte pour les données détaillées et plus longue pour les agrégats, la suppression par défaut des journaux de débogage en production, et la refacturation de la télémétrie aux équipes qui la produisent, pour que son coût soit visible. Traitez le volume de télémétrie comme un paramètre de conception doté d’un budget, comme n’importe quelle autre ressource.

Alerter sur les symptômes, pas sur les causes

Selon le livre SRE, les alertes d’astreinte doivent porter sur les symptômes que ressentent les utilisateurs, et non sur les nombreuses causes possibles. Un CPU élevé, un disque plein sur une réplique ou un conteneur redémarré sont des causes : souvent sans conséquence, parfois déjà traitées par l’automatisation, et jamais une liste complète de ce qui peut mal tourner. Un SLO dont le budget fond, des paiements en échec ou un pipeline de positions des livreurs bloqué sont des symptômes : ils comptent quelle qu’en soit la cause. Les alertes fondées sur les symptômes sont moins nombreuses, rarement fausses, et couvrent des défaillances que personne n’avait prévues ; les signaux fondés sur les causes ont leur place sur des tableaux de bord qui aident à diagnostiquer un symptôme une fois l’alerte déclenchée.

Chaque alerte d’astreinte doit être urgente, actionnable et réelle. La lassitude face aux alertes (alert fatigue) est en soi un risque pour la fiabilité : les ingénieurs d’astreinte réveillés par des alertes sans intérêt apprennent à les ignorer et manquent celle qui compte. Une règle pratique consiste à alerter l’astreinte sur les taux de consommation des SLO (section 9.5), à envoyer les consommations plus lentes et les avertissements sur les ressources vers une file de tickets, et à relier chaque alerte d’astreinte à un runbook (procédure d’exploitation) et à un tableau de bord.

Des tableaux de bord qui répondent à des questions

Un mur de cinquante graphiques ne répond vite à aucune question. Les bons tableaux de bord se conçoivent comme n’importe quelle interface utilisateur : pour un public identifié et une question précise. Une vue d’ensemble du service répond à ce service est-il en bonne santé ? avec ses SLO, le budget d’erreur restant et les métriques RED en haut, et les métriques USE de ses ressources clés en dessous. Un tableau de bord de parcours pour l’ouverture des ventes répond à les fans obtiennent-ils des billets ? avec les admissions, les blocages de places, les paiements et les échecs par minute, de bout en bout. Les tableaux de bord de diagnostic s’atteignent en descendant dans le détail ; ils ne s’affichent pas en premier.

Gérez les tableaux de bord en tant que code sous contrôle de version, donnez à chacun un propriétaire, affichez les déploiements et les changements de feature flags sous forme d’annotations sur les graphiques (la plupart des incidents suivent un changement), et supprimez les tableaux de bord que personne n’a ouverts depuis des mois. Pendant un incident, la première vue utile est généralement le parcours vu par l’utilisateur, la deuxième la trace d’une requête en échec, et seulement ensuite les métriques des ressources.