Observability Strategy: From Monitoring to Understanding Systems

L'observabilité n'est pas du monitoring rebaptisé. Le monitoring dit quand quelque chose est cassé ; l'observabilité aide à comprendre pourquoi. À mesure que les systèmes distribués gagnent en complexité, une stratégie d'observabilité délibérée fait la différence entre le mode pompier et l'ingénierie de la résilience.

Les Quatre Piliers

Les classiques "trois piliers" se sont élargis. Le profiling est désormais un signal de première classe.

Signaux d'Observabilité
├── Métriques        (numériques, agrégées, séries temporelles)
│   ├── RED : Rate, Errors, Duration (services)
│   └── USE : Utilization, Saturation, Errors (ressources)
├── Logs             (événements discrets, structurés ou non)
│   ├── Logs applicatifs
│   ├── Logs d'audit
│   └── Logs d'accès
├── Traces           (chemins de requêtes distribués)
│   ├── Spans
│   ├── Propagation de contexte
│   └── Stratégies d'échantillonnage
└── Profils          (profiling continu)
    ├── Flame graphs CPU
    ├── Allocation mémoire
    └── Contention de verrous

Observabilité vs Monitoring

Dimension	Monitoring	Observabilité
Question	"Ça marche ?"	"Pourquoi ça ne marche pas ?"
Modèle de données	Dashboards prédéfinis, seuils	Haute cardinalité, données explorables
Approche	Inconnus connus (alertes sur pannes attendues)	Inconnus inconnus (investigation ad-hoc)
Instrumentation	Basée sur agents, centrée métriques	Basée sur SDK, tracés + événements structurés
Facteur de coût	Nombre d'hôtes/services	Volume de données (événements, spans)
Culture	Portée par les Ops	Responsabilité partagée par l'ingénierie

Modèle de Maturité

Niveau	Nom	Caractéristiques
0	Réactif	Aucun monitoring. SSH pour lire les logs.
1	Monitoring Basique	Checks de disponibilité, alertes CPU/mémoire, logs non structurés.
2	Monitoring Structuré	Logs centralisés, APM, dashboards basiques, runbooks.
3	Observabilité	Tracing distribué, logs structurés, SLOs, astreintes.
4	Observabilité Proactive	Profiling continu, détection d'anomalies, chaos engineering.
5	Adaptive	AIOps, remédiation automatisée, pipelines de télémétrie optimisés en coût.

Décisions Stratégiques

Éditeur vs OSS : Une stack Grafana (Prometheus + Loki + Tempo + Pyroscope) offre zéro lock-in mais nécessite de l'ingénierie plateforme dédiée. Datadog ou Dynatrace réduit la charge opérationnelle mais crée une exposition significative aux coûts à grande échelle.

Stratégie d'instrumentation : Adoptez OpenTelemetry comme couche d'instrumentation unique. OTel est CNCF graduated, neutre vis-à-vis des éditeurs, et supporté par tous les backends majeurs.

Échantillonnage et maîtrise des coûts : À grande échelle, on ne peut pas stocker chaque tracé. Implémentez un échantillonnage tail-based dans le Collector OTel pour capturer 100% des erreurs et requêtes lentes tout en échantillonnant le trafic normal.

SLOs plutôt qu'alertes : Définissez des SLOs avec des budgets d'erreur. Alertez sur le burn rate, pas sur des seuils bruts. Cela réduit la fatigue d'alerte et concentre l'effort sur l'impact utilisateur.

Ressources

:::