Observabilité : logs, métriques et traces avec OpenTelemetry
Les trois piliers de l'observabilité et pourquoi OpenTelemetry est devenu le standard pour instrumenter des systèmes distribués sans se lier à un fournisseur.
Quand une requête traverse dix microservices et que l'utilisateur se plaint que « c'est lent », par où commencer ? La surveillance (monitoring) classique répond à une question binaire : « est-ce que ça marche ? ». L'observabilité vise plus haut : comprendre l'état interne d'un système à partir de ce qu'il émet, y compris pour diagnostiquer des pannes qu'on n'avait pas anticipées. C'est une nuance capitale dans les architectures distribuées modernes.
Les trois signaux (les « piliers »)
- Logs — des événements horodatés et détaillés (« à 10h32, échec de connexion à la base »). Précieux pour le détail, mais volumineux et coûteux à stocker.
- Métriques — des mesures numériques agrégées dans le temps (taux d'erreur, latence p95, débit, usage CPU). Peu coûteuses, idéales pour les tableaux de bord et les alertes.
- Traces — le chemin complet d'une requête à travers tous les services, décomposé en « spans », avec le temps passé dans chacun.
Les métriques disent qu'un problème existe ; les traces montrent où ; les logs expliquent pourquoi.
Le problème des traces distribuées
Pour reconstituer le parcours d'une requête à travers dix services, chacun doit propager un identifiant de trace commun (le « trace context ») à ses appels sortants. Sans standard, chaque bibliothèque et chaque outil réinvente son format — un cauchemar d'intégration, et un verrouillage fournisseur garanti.
OpenTelemetry : le standard qui unifie
OpenTelemetry (OTel) est un projet de la CNCF, né de la fusion de deux projets antérieurs, OpenTracing et OpenCensus, qui résolvaient le même problème chacun de leur côté. OTel fournit un ensemble unifié : une spécification, un protocole (OTLP), des conventions sémantiques (des noms standardisés pour les données courantes), des API et SDK dans tous les langages, et un Collector qui reçoit, transforme et exporte la télémétrie.
OpenTelemetry repose sur deux principes affichés : vous possédez vos données (pas de verrouillage fournisseur) et vous n'apprenez qu'un seul jeu d'API. L'avantage décisif : vous instrumentez votre code une seule fois, puis vous exportez vers l'outil de votre choix — Jaeger, Prometheus, Grafana, ou une offre commerciale comme Datadog. Changer de backend d'observabilité ne demande plus de tout réécrire. À noter : OTel n'est pas un backend de stockage ni un outil de visualisation ; il s'arrête volontairement à la production et au transport des données.
Par où commencer concrètement
Inutile de tout instrumenter d'un coup. Une approche pragmatique :
- Activez l'instrumentation automatique d'OTel (souvent sans changer le code) sur vos services les plus critiques.
- Concentrez-vous d'abord sur quelques métriques clés — les « signaux d'or » du SRE : latence, trafic, erreurs, saturation.
- Ajoutez des traces sur les parcours utilisateurs importants (paiement, connexion) pour repérer les goulots.
- Corrélez logs, métriques et traces via le trace-id pour passer du « quoi » au « pourquoi » en un clic.
L'observabilité se construit progressivement, guidée par les vraies questions qu'on se pose en incident, pas par la volonté de tout mesurer.