Dans un système distribué moderne, une requête utilisateur peut traverser vingt microservices, trois files de messages et deux bases de données avant de renvoyer une réponse. Lorsque cette requête échoue ou tarde trop, l'équipe des opérations doit réagir en quelques minutes, pas en quelques heures. L'observabilité est la discipline qui rend cette réaction possible : la capacité à comprendre l'état interne d'un système à partir des signaux qu'il émet vers l'extérieur. Cet article développe les trois piliers de l'observabilité (logs, métriques et traces), les outils de référence pour les mettre en œuvre et les erreurs qui séparent un système instrumenté d'un système réellement observable.
Le terme vient de la théorie du contrôle : un système est observable si son état interne peut se déduire de ses sorties. Transposé au logiciel, cela signifie que, face à un comportement inattendu, nous devrions pouvoir expliquer la cause sans avoir à ajouter de nouvelle instrumentation ni à reproduire le problème dans un environnement contrôlé. Telle est la différence essentielle avec le débogage traditionnel, qui suppose que la panne peut se reproduire à volonté : en production distribuée, beaucoup d'incidents sont irréproductibles et ne laissent de trace que dans la télémétrie capturée à l'instant exact où ils se sont produits.
Les trois piliers de l'observabilité
Il convient de distinguer la surveillance de l'observabilité. La surveillance classique répond à des questions que vous saviez déjà formuler : le processeur dépasse-t-il 80 % ? y a-t-il des erreurs HTTP 500 ? L'observabilité va plus loin et permet de répondre à des questions que vous n'aviez jamais anticipées lors de la conception, en explorant les données de télémétrie sans avoir à déployer de nouveau code. Cette propriété repose sur trois types de signaux complémentaires.
Les métriques sont des valeurs numériques agrégées dans le temps (requêtes par seconde, latence du 99e centile, utilisation de la mémoire). Leur stockage est peu coûteux et elles permettent des alertes en temps réel, mais elles perdent le détail de chaque événement individuel. Les logs sont des enregistrements discrets d'événements, idéalement structurés en JSON avec des champs interrogeables ; ils offrent un maximum de détail, mais leur volume et leur coût augmentent vite. Les traces distribuées suivent le parcours complet d'une requête à travers tous les services, en lui attribuant un trace_id commun et en mesurant le temps consommé dans chaque tronçon, ou span. La combinaison des trois permet de passer de « quelque chose ne va pas » (métrique) à « cette requête précise a échoué ici » (trace) puis à « voici le message d'erreur exact » (log).
Pile de logs : la famille Elastic (ELK)
La pile ELK reste la référence pour la gestion centralisée des logs. Elle se compose d'Elasticsearch (moteur de recherche et de stockage fondé sur des index inversés), de Logstash ou des agents Beats plus légers pour l'ingestion, et de Kibana pour la visualisation. Un schéma courant envoie les logs de chaque conteneur via Filebeat vers un pipeline Logstash qui les analyse avec des expressions grok, normalise les horodatages et les enrichit de métadonnées (nom du service, version, environnement) avant de les indexer.
La clé d'un bon système de logs est la journalisation structurée. Un log en texte brut tel que Erreur lors du traitement de la commande 4521 est difficile à interroger ; son équivalent structuré {"level":"error","event":"order_failed","order_id":4521,"service":"checkout"} permet de filtrer, d'agréger et de corréler. Il est judicieux de définir des niveaux cohérents (DEBUG, INFO, WARN, ERROR), d'appliquer des politiques de rétention par index via l'Index Lifecycle Management (données chaudes sur SSD les premiers jours, données froides sur stockage bon marché ensuite) et, surtout, d'éviter d'enregistrer des données personnelles en clair : le Règlement général sur la protection des données impose la minimisation et la pseudonymisation, et les logs sont l'une des fuites de données personnelles les plus fréquentes et les plus oubliées.
Métriques et alertes avec Prometheus
Prometheus domine le domaine des métriques dans les environnements cloud-native. Son modèle est de type pull : le serveur interroge périodiquement les points de terminaison HTTP /metrics exposés par chaque service. Il stocke des séries temporelles identifiées par un nom et un ensemble d'étiquettes clé-valeur, que l'on interroge avec PromQL, un langage conçu pour les agrégations temporelles. Une expression comme histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) renvoie la latence du 99e centile sur les cinq dernières minutes.
La visualisation est généralement déléguée à Grafana, qui combine les données de Prometheus, d'Elasticsearch et d'autres sources dans des tableaux de bord unifiés. Les alertes sont gérées avec Alertmanager, qui regroupe, met en sourdine et achemine les notifications afin d'éviter la fatigue d'alertes : le phénomène par lequel une équipe reçoit tant d'avertissements sans intérêt qu'elle finit par ignorer aussi les importants. Une bonne règle d'alerte ne repose pas sur des seuils arbitraires de processeur, mais sur des symptômes perçus par l'utilisateur, formalisés sous forme de SLO (Service Level Objectives) et de leur consommation de budget d'erreur, selon la pratique de l'ingénierie de fiabilité décrite dans le corpus de connaissances SRE de Google.
Traçabilité distribuée et le standard OpenTelemetry
La pièce qui boucle la boucle est la trace distribuée, et le standard de fait est ici OpenTelemetry (OTel), projet de la Cloud Native Computing Foundation. OpenTelemetry unifie l'instrumentation des logs, des métriques et des traces sous une seule API et un protocole commun (OTLP), de sorte que le code de l'application ne reste pas lié à un fournisseur précis. Des backends comme Jaeger, Tempo ou des solutions commerciales consomment cette télémétrie sans qu'il soit nécessaire de réinstrumenter. Cette neutralité est stratégique : changer de fournisseur d'observabilité sans OpenTelemetry implique de réécrire l'instrumentation de centaines de services ; avec OpenTelemetry, il suffit de rediriger l'exportateur.
Le concept central est la propagation du contexte : lorsque le service A appelle le service B, il transmet le trace_id dans les en-têtes (standard W3C Trace Context). Le backend peut ainsi reconstruire l'arbre complet des spans et montrer exactement où le temps a été consommé. La résolution des problèmes de latence dans des systèmes comptant des dizaines de services devient ainsi une tâche visuelle plutôt qu'une archéologie de logs. Une bonne instrumentation ajoute en outre des attributs sémantiques à chaque span (code de réponse, identifiant d'utilisateur pseudonymisé, version du déploiement), ce qui permet de filtrer et de comparer les traces selon des caractéristiques métier et non seulement par service.
Cardinalité, volume et maîtrise des coûts
L'erreur opérationnelle qui fait le plus exploser les factures en observabilité est l'explosion de cardinalité. Dans Prometheus, chaque combinaison unique d'étiquettes crée une série temporelle indépendante ; ajouter comme étiquette un identifiant à forte variabilité (l'ID d'utilisateur, une URL avec paramètres, un UUID) peut générer des millions de séries et faire tomber le serveur. La règle pratique consiste à réserver les étiquettes aux dimensions à faible cardinalité et bornées (service, environnement, code d'état, région) et à laisser l'information à forte variabilité aux logs ou aux traces, où elle est stockée différemment.
Dans les logs, l'équivalent se produit avec le volume brut : journaliser au niveau DEBUG en production ou déverser des corps de requête complets peut multiplier par dix l'ingestion et le coût d'indexation. Les leviers pour le maîtriser sont l'échantillonnage (conserver 100 % des erreurs mais seulement une fraction des événements normaux), des politiques de rétention échelonnées selon l'ancienneté et la séparation entre le stockage des logs accessibles à la recherche et l'archive froide bon marché à des fins de conformité. Mesurer le coût par service et par gigaoctet ingéré, et le réviser périodiquement, évite la mauvaise surprise d'une facture cloud qui croît plus vite que le système lui-même.
Tableau comparatif des trois piliers
| Dimension | Métriques | Logs | Traces |
|---|---|---|---|
| Question à laquelle elle répond | Que se passe-t-il ? | Pourquoi est-ce arrivé ? | Où est-ce arrivé ? |
| Coût de stockage | Faible | Élevé | Moyen (avec échantillonnage) |
| Granularité | Agrégée | Par événement | Par requête |
| Adaptée aux alertes | Oui | Limitée | Pas directement |
| Outil de référence | Prometheus + Grafana | ELK Stack | Jaeger / Tempo + OTel |
Mise en œuvre par phases
Un déploiement ordonné évite le piège habituel qui consiste à tout instrumenter d'un coup et à se noyer dans les données. Une séquence raisonnable est la suivante : (1) centraliser les logs structurés de tous les services vers une destination unique et interrogeable ; (2) exposer les quatre métriques d'or (latence, trafic, erreurs et saturation) dans chaque service ; (3) définir des SLO réalistes à partir de données réelles et configurer des alertes fondées sur le budget d'erreur ; (4) instrumenter les traces avec OpenTelemetry sur les flux métier critiques ; et (5) corréler les trois piliers au moyen d'identifiants communs afin de pouvoir passer d'une métrique anormale à la trace puis au log exact en deux clics.
Erreurs courantes à éviter
La première est d'alerter sur les causes plutôt que sur les symptômes : une alerte de processeur à 90 % ne signifie rien si l'utilisateur continue de recevoir des réponses rapides, et elle sature l'équipe d'astreinte. La deuxième est la journalisation sans structure ni rétention, qui fait grimper la facture de stockage et laisse des données personnelles exposées. La troisième est d'instrumenter sans échantillonnage des traces à fort volume, ce qui génère des coûts et du bruit ; l'échantillonnage fondé sur la queue, qui conserve toujours les traces présentant des erreurs ou une latence élevée, résout le problème. La quatrième est de se fier à des tableaux de bord que personne ne regarde : l'observabilité n'apporte de la valeur que si elle est intégrée aux runbooks d'incidents et à la culture de l'équipe.
Questions fréquentes
Quelle est la différence entre surveillance et observabilité ?
La surveillance vérifie des conditions prédéfinies (seuils, contrôles de santé). L'observabilité permet d'explorer le système et de répondre à de nouvelles questions sans déployer de code, grâce à la richesse des logs, métriques et traces corrélés.
Ai-je besoin de Prometheus et d'ELK en même temps, ou puis-je n'en choisir qu'un ?
Ils résolvent des problèmes différents : Prometheus pour les métriques et les alertes en temps réel, ELK pour l'analyse détaillée des logs. Dans la plupart des architectures sérieuses, ils coexistent, généralement réunis par Grafana comme couche de visualisation commune.
Que sont les « quatre métriques d'or » ?
La latence, le trafic, le taux d'erreurs et la saturation. Il s'agit de l'ensemble minimal recommandé par l'ingénierie de fiabilité pour comprendre la santé de tout service orienté utilisateurs.
OpenTelemetry remplace-t-il Prometheus et la pile ELK ?
Il ne les remplace pas, il les unifie au niveau de la couche d'instrumentation. OpenTelemetry collecte les signaux de façon neutre et les envoie vers les backends de votre choix (Prometheus, Tempo, Elasticsearch), évitant le verrouillage par un fournisseur précis.
Conclusion
L'observabilité n'est ni un joli tableau de bord ni un outil que l'on achète : c'est une propriété du système qui se conçoit dès le premier commit. Une équipe disposant de logs structurés, de métriques alignées sur des SLO et de traces distribuées avec OpenTelemetry réduit drastiquement le temps moyen de détection et de résolution des incidents (MTTD et MTTR), qui sont les métriques déterminant réellement la fiabilité perçue. L'investissement ne se justifie pas par une économie générique, mais par quelque chose de concret : lorsque l'incident survient à trois heures du matin, la différence entre cinq minutes et cinq heures de diagnostic tient à une bonne instrumentation mise en place avant d'en avoir besoin. Chez Summum Marketing, nous concevons des architectures d'observabilité en partant des flux métier critiques, et non du catalogue d'outils, afin que chaque signal collecté réponde à une question précise.