Qu'est-ce que l'Observability ?

Qu'est-ce que l'observability ?

L'observability est la propriété d'un système qui te permet de comprendre son état interne depuis ses outputs externes sans avoir à shipper du nouveau code pour investiguer. Les trois outputs externes sont les logs (quels événements se sont produits), les metrics (séries temporelles numériques comme RPS, latency, CPU) et les traces (breakdowns par requête à travers les services). Un système est observable quand un engineer sans contexte préalable peut répondre à des questions arbitraires sur un incident de production uniquement depuis ces trois signaux.

Le terme vient de la control theory : un système est observable si son état interne est entièrement déterminable depuis un historique fini d'outputs. En software la barre pratique est plus basse mais le principe tient. Si un client signale un checkout lent et ta seule réponse est d'ajouter des log lines, redéployer et attendre que l'erreur revienne, ton système n'est pas observable.

Observability vs monitoring

Monitoring et observability se chevauchent mais ne sont pas la même chose :

• Monitoring pose des questions pré-définies : la homepage est up, CPU sous 80%, error rate sous 1% ? Tu configures dashboards et alerts à l'avance contre des failure modes que tu prédis. Idéal pour les failure modes connus.
• Observability pose des questions arbitraires à des données high-cardinality après coup : "montre-moi toutes les requêtes p99 de la dernière heure groupées par customer_id et région où le downstream call vers stripe.com a dépassé 800 ms." Idéal pour les failure modes inconnus.

Un système de monitoring peut te dire que quelque chose est cassé. Un système observable te permet de trouver quoi. Une production saine a besoin des deux.

Les trois pillars (et le piège de cardinality)

• Logs : records d'événements discrets. Faciles à écrire, chers à query à l'échelle, faibles en corrélation entre services sauf si tu propages des trace IDs dans chaque log line.
• Metrics : séries temporelles numériques. Pas chères à stocker, rapides à query, mais perdent le contexte par requête. La cardinality (nombre de combinaisons uniques de tags) est le driver de coût.
• Traces : arbres de spans par requête à travers les services. Le signal le plus fort pour l'investigation d'incidents. Souvent samplés (1-10%) parce que stocker chaque trace est prohibitif.

Les outils modernes d'observability (Honeycomb, Datadog, Grafana, Splunk, New Relic, Elastic) essaient d'unifier les trois autour d'un trace ID partagé, de sorte qu'un clic passe d'un spike de metric à la trace lente aux logs correspondants.

Ce que couvre l'observability en pratique

1. Investigation d'incident : production en feu, on-call engineer corrèle le spike de metric à la trace à la query lente au mauvais deploy en moins de 10 minutes.
2. Mesure de SLO : error rate et percentiles de latency par endpoint, par tier client, slicé comme tu veux.
3. Détection de régression de performance : comparer la latency p95 de l'endpoint X avant et après un deploy, scopé à une seule cohorte client.
4. Escalation support : "cet utilisateur signale que son checkout était lent à 14:32 UTC" mappé à la trace exacte.
5. Capacity planning : metrics historiques corrélés à des patterns de trafic. Voir capacity testing.

Comment devenir observable

Commencer en propageant un trace ID dans chaque requête : header HTTP (W3C traceparent), dans les messages de queue, dans les jobs background. Puis instrumenter avec un SDK OpenTelemetry (vendor-neutral) qui émet des traces et metrics vers ton backend de choix. Puis standardiser les log lines pour inclure trace_id et customer_id.

L'observability complémente le load testing. Lancer load testing ou soak testing contre un staging entièrement instrumenté et les mêmes dashboards que tu utilises en production deviennent tes résultats de test. Voir aussi latency.

Si ton équipe doit lancer des load tests de production corrélés à ton stack d'observability existant, LoadFocus propose des services de load testing où des ingénieurs conçoivent les scenarios et documentent contre tes données APM et tracing.