Qu'est-ce que l'observabilité ?
L'observabilité est la capacité à comprendre l'état interne d'un système en observant ses sorties externes (métriques, logs, traces). Le terme vient de la théorie du contrôle en ingénierie. En informatique, un système est "observable" quand on peut diagnostiquer n'importe quel problème sans modifier le code ni redeployer. L'observabilité va au-delà du monitoring traditionnel en permettant l'exploration de problèmes imprévus.
Les trois piliers
Les trois piliers de l'observabilité sont les métriques (données numériques agr egees dans le temps : latence, taux d'erreur, utilisation CPU), les logs (enregistrements textuels d'événements discrets avec contexte), et les traces distribuees (suivi d'une requête à travers tous les services). Chaque pilier répond à des questions différentes et les trois ensemble donnent une vue complète. OpenTelemetry est le standard emergent qui unifie la collecte des trois signaux.
OpenTelemetry
OpenTelemetry (OTel) est un projet CNCF qui fournit un ensemble standardise d'APIs, de SDKs et d'outils pour générer, collecter et exporter des données de telemetrie. Il est supporté par tous les principaux fournisseurs (Datadog, Grafana, New Relic, AWS). Les avantages : instrumentation unique indépendante du backend, auto-instrumentation pour les frameworks courants, et un collecteur (OTel Collector) qui normalise et route les données vers n'importe quel backend.
Corrélation et contexte
La puissance de l'observabilité vient de la corrélation entre les signaux. Un trace ID lie une trace distribuee aux logs generes pendant son exécution et aux métriques impactees. Quand une alerte se declenche sur une métrique (latence elevee), on consulte les traces pour identifier le service lent, puis les logs de ce service pour comprendre la cause. Sans corrélation, chaque signal est une ile isolee. Les exemplars de Prometheus lient les métriques aux traces individuelles.
Pratiques et culture
L'observabilité est autant une pratique culturelle qu'un ensemble d'outils. Les équipes SRE (Site Reliability Engineering) définissent des SLI (Service Level Indicators) et des SLO (Service Level Objectives) pour mesurer la fiabilité. Les error budgets (budget d'erreur) définissent le niveau d'erreur acceptable avant d'arrêter les releases. Les post-mortems (blameless) après les incidents utilisent les données d'observabilité pour comprendre et prévenir les recurrences. L'objectif est de passer du réactif (combattre les incendies) au proactif (détecter les degradations avant l'impact).