Observabilité

L’observabilité est la capacité à comprendre l’état interne d’un système à partir de ses signaux externes — sans avoir à le modifier ni à deviner. Le terme vient de la théorie du contrôle ; appliqué aux systèmes distribués, il recouvre une question opérationnelle très concrète : quand quelque chose se comporte anormalement en production, peut-on répondre à « pourquoi ? » avec les données déjà disponibles ?

Observabilité et monitoring ne sont pas synonymes

Le monitoring répond à des questions connues d’avance : le service est-il up, la latence dépasse-t-elle le seuil, le disque est-il plein. Il fonctionne bien pour les pannes déjà rencontrées, celles pour lesquelles on a écrit une alerte. L’observabilité vise les questions qu’on n’avait pas anticipées — « pourquoi les requêtes de ce client précis sont-elles lentes depuis mardi ? » — en donnant les moyens d’explorer les données plutôt que de consulter des tableaux de bord figés. Un système peut être monitoré de près et rester opaque dès qu’un incident sort du scénario prévu.

Les trois types de signaux

Les métriques sont des valeurs numériques agrégées dans le temps (taux d’erreur, latence, saturation) : peu coûteuses à stocker, idéales pour l’alerte et les tendances, mais sans le détail d’une requête individuelle. Les logs sont des événements horodatés et contextualisés : riches, mais volumineux et chers à indexer. Les traces distribuées suivent une requête à travers tous les services qu’elle traverse et montrent où le temps se perd — indispensables dès que l’architecture dépasse le monolithe. Aucun des trois ne remplace les autres ; c’est leur corrélation (retrouver les logs et la trace correspondant au pic d’une métrique) qui fait la valeur de l’ensemble.

Le coût est le vrai sujet

Tout instrumenter, tout stocker, tout indexer est techniquement possible et financièrement absurde : la facture d’observabilité peut croître plus vite que le trafic, notamment via la cardinalité des métriques et la rétention des logs. L’erreur classique consiste à collecter d’abord et réfléchir ensuite. La démarche inverse — partir des questions auxquelles on doit pouvoir répondre, typiquement celles que posent des SLO, et instrumenter pour y répondre — donne un système observable à un coût maîtrisé.