L'observabilité repose sur trois piliers complémentaires : les métriques (ce qui s'est passé), les logs (pourquoi cela s'est passé) et les traces distribuées (où cela s'est passé), généralement mises en œuvre avec Prometheus, la pile ELK et OpenTelemetry. Contrairement à la supervision classique, elle permet aux équipes de répondre à de nouvelles questions sans déployer de nouveau code.
Dans un système distribué moderne, une seule 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 prend trop de temps, l'équipe d'exploitation doit réagir en quelques minutes, pas en quelques heures. L'observabilité est la discipline qui rend une telle réaction possible : la capacité de 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 véritablement observable.
Le terme vient de la théorie du contrôle : un système est observable si son état interne peut être déduit de ses sorties. Appliqué au logiciel, cela signifie que, face à un comportement inattendu, on doit pouvoir en expliquer la cause sans ajouter de nouvelle instrumentation ni reproduire le problème dans un environnement contrôlé. C'est la différence clé avec le débogage traditionnel, qui suppose que la panne peut être reproduite à volonté : en production distribuée, de nombreux incidents sont non reproductibles et ne laissent de trace que dans la télémétrie capturée au moment exact où ils se sont produits.
Les trois piliers de l'observabilité
Il convient de distinguer la supervision de l'observabilité. La supervision classique répond à des questions que l'on savait déjà poser : le CPU 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 jamais anticipées lors de la conception, en explorant les données de télémétrie sans 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 au 99e percentile, utilisation mémoire). Elles sont peu coûteuses à stocker et 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 détail maximal, mais leur volume et leur coût croissent rapidement. Les traces distribuées suivent le chemin complet d'une requête à travers chaque service, en attribuant un trace_id commun et en mesurant le temps passé dans chaque segment, ou span. Combiner les trois permet de passer de « quelque chose ne va pas » (métrique) à « c'est cette requête précise qui a échoué ici » (trace) et « 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 comprend Elasticsearch (un moteur de recherche et de stockage basé sur des index inversés), Logstash ou les agents Beats plus légers pour l'ingestion, et Kibana pour la visualisation. Un schéma courant consiste à envoyer les logs de chaque conteneur via Filebeat vers un pipeline Logstash qui les analyse avec des expressions grok, normalise les horodatages et les enrichit avec des métadonnées (nom du service, version, environnement) avant de les indexer.
La clé d'un bon système de logs est le logging structuré. Un log en texte brut comme Error processing order 4521 est difficile à interroger ; l'équivalent structuré {"level":"error","event":"order_failed","order_id":4521,"service":"checkout"} permet de filtrer, d'agréger et de corréler. Il est recommandé 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 un stockage bon marché ensuite) et, surtout, d'éviter de journaliser des données personnelles en texte brut : le règlement général sur la protection des données exige minimisation et pseudonymisation, et les logs sont l'une des sources les plus fréquentes et les plus négligées de fuites de données personnelles.
Métriques et alerting avec Prometheus
Prometheus domine l'espace des métriques dans les environnements cloud-native. Son modèle est basé sur le 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, interrogées 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 au 99e percentile sur les cinq dernières minutes.
La visualisation est généralement déléguée à Grafana, qui combine les données de Prometheus, 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 route les notifications pour éviter la fatigue d'alerte : le phénomène par lequel une équipe reçoit tant d'alertes non pertinentes qu'elle finit par ignorer aussi les plus importantes. Une bonne règle d'alerte ne repose pas sur des seuils de CPU arbitraires, mais sur des symptômes réellement perçus par l'utilisateur, formalisés en SLO (Service Level Objectives) et leur consommation d'error budget, en suivant la pratique de l'ingénierie de la fiabilité décrite dans le corpus SRE de Google.
Traçage distribué et le standard OpenTelemetry
La pièce qui referme la boucle est la trace distribuée, et ici le standard de facto est OpenTelemetry (OTel), un projet de la Cloud Native Computing Foundation. OpenTelemetry unifie l'instrumentation des logs, métriques et traces sous une seule API et un protocole commun (OTLP), afin que le code applicatif ne soit pas lié à un fournisseur spécifique. Des back-ends comme Jaeger, Tempo ou des solutions commerciales consomment cette télémétrie sans besoin de ré-instrumenter. Cette neutralité est stratégique : changer de fournisseur d'observabilité sans OpenTelemetry signifie réécrire l'instrumentation de centaines de services ; avec OpenTelemetry, il suffit de repointer l'exportateur.
Le concept central est la propagation de contexte : lorsque le service A appelle le service B, il transmet le trace_id dans les en-têtes (le standard W3C Trace Context). Le back-end peut alors reconstruire l'arbre complet des spans et montrer exactement où le temps a été passé. Cela transforme le débogage de latence dans des systèmes comptant des dizaines de services en une tâche visuelle plutôt qu'en un exercice d'archéologie des logs. Une bonne instrumentation ajoute aussi des attributs sémantiques à chaque span (code de réponse, identifiant utilisateur pseudonymisé, version de déploiement), ce qui permet de filtrer et de comparer les traces par caractéristiques métier et pas seulement par service.
Cardinalité, volume et maîtrise des coûts
L'erreur opérationnelle qui fait le plus grimper les factures d'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é (un identifiant utilisateur, une URL avec des paramètres, un UUID) peut générer des millions de séries et faire tomber le serveur. La règle empirique consiste à réserver les étiquettes aux dimensions bornées et à faible cardinalité (service, environnement, code de statut, région) et à laisser les informations à forte variabilité aux logs ou aux traces, où elles sont stockées différemment.
Avec les logs, l'équivalent se produit avec le volume brut : journaliser au niveau DEBUG en production ou déverser les corps complets des requêtes peut multiplier par dix le coût d'ingestion et 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 par ancienneté, et la séparation entre le stockage pour les logs interrogeables et des archives froides bon marché pour la conformité. Mesurer le coût par service et par gigaoctet ingéré, et le réviser périodiquement, évite la surprise d'une facture cloud qui croît plus vite que le système lui-même.
Comparaison 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é à l'alerting | Oui | Limité | Pas directement |
| Outil de référence | Prometheus + Grafana | Pile ELK | Jaeger / Tempo + OTel |
Mise en œuvre par phases
Un déploiement ordonné évite le piège courant consistant à tout instrumenter d'un coup et à se noyer dans les données. Une séquence raisonnable est : (1) centraliser les logs structurés de chaque service vers une destination unique et interrogeable ; (2) exposer les quatre signaux d'or (latence, trafic, erreurs et saturation) sur chaque service ; (3) définir des SLO réalistes à partir de données réelles et configurer des alertes basées sur l'error budget ; (4) instrumenter les traces avec OpenTelemetry sur les flux métier critiques ; et (5) corréler les trois piliers via des identifiants communs afin de pouvoir passer d'une métrique anormale à la trace et au log exacts en deux clics.
Erreurs courantes à éviter
La première est d'alerter sur les causes plutôt que sur les symptômes : une alerte CPU à 90 % ne veut rien dire si l'utilisateur continue de recevoir des réponses rapides, et elle submerge l'équipe d'astreinte. La deuxième est de journaliser sans structure ni rétention, ce qui gonfle la facture de stockage et expose des données personnelles. La troisième est d'instrumenter sans échantillonnage sur des traces à fort volume, ce qui génère coût et bruit ; l'échantillonnage tail-based, qui conserve toujours les traces avec erreurs ou latence élevée, résout le problème. La quatrième est de s'appuyer sur des tableaux de bord que personne ne regarde : l'observabilité n'apporte de valeur que si elle s'intègre aux runbooks d'incident et à la culture de l'équipe.
Questions fréquentes
Quelle est la différence entre supervision et observabilité ?
La supervision 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 à la fois de Prometheus et d'ELK, ou puis-je n'en choisir qu'un seul ?
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 rejoints par Grafana comme couche de visualisation commune.
Que sont les « quatre signaux d'or » ?
Latence, trafic, taux d'erreur et saturation. C'est l'ensemble minimal recommandé par l'ingénierie de la fiabilité pour comprendre l'état de santé de tout service exposé aux 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 manière neutre et les envoie vers les back-ends de votre choix (Prometheus, Tempo, Elasticsearch), évitant ainsi la dépendance à un fournisseur spécifique.
Conclusion
L'observabilité n'est pas un joli tableau de bord ni un outil que l'on achète : c'est une propriété du système, conçue dès le tout premier commit. Une équipe disposant de logs structurés, de métriques alignées sur des SLO et de traces distribuées via OpenTelemetry réduit drastiquement le temps moyen de détection et de résolution des incidents (MTTD et MTTR), qui sont les métriques qui déterminent réellement la fiabilité perçue. L'investissement ne se justifie pas par une économie générique, mais par quelque chose de concret : quand l'incident survient à trois heures du matin, la différence entre cinq minutes et cinq heures de diagnostic tient au fait d'avoir bien instrumenté avant d'en avoir besoin. Chez Summum Marketing, nous concevons des architectures d'observabilité en partant des flux métier critiques, pas du catalogue d'outils, afin que chaque signal collecté réponde à une question concrète.