L'observabilité repose sur trois piliers — logs, métriques et traces — et l'objectif est de répondre à « qu'est-ce qui ne va pas et pourquoi » pour un système trop volumineux pour être inspecté manuellement. À grande échelle, la stratégie consiste à corréler, échantillonner et maîtriser les coûts.
| Pilier | Répond à | Outils |
|---|
| Métriques | Quelque chose ne va-t-il pas ? (taux, latence) | Prometheus, Grafana |
| Traces | Où dans le flux ? | OpenTelemetry, Jaeger |
| Logs | Qu'est-ce qui s'est exactement passé ? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
L'ID de trace/corrélation doit traverser les libellés de métriques, les lignes de log et les spans, afin que vous puissiez basculer entre eux.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Journal à 100% est inabordable et noie le signal. Échantillonnez, structurez et créez des alertes sur les SLO à la place.
Avec des centaines de services, vous ne pouvez pas vous connecter en SSH et regarder — l'observabilité est le seul moyen de comprendre le comportement en production.
La stratégie gagnante est corrélée, échantillonnée et basée sur les SLO : elle met en évidence les vrais problèmes rapidement sans vous ruiner sur le stockage de télémétrie ou noyer l'équipe d'astreinte dans le bruit.