Stratégie d'Observabilité : Du Monitoring à la Compréhension des Systèmes
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.
- 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 |
- otlp receiver 4317/4318
- → memory_limiter
- → k8sattributes (pod, namespace)
- → batch
- traces: otlphttp → trace backend
- logs: kafka → SIEM
- → batch
- → redaction / transform
- → batch (see above)
- → k8sattributes (pod, namespace)
- → memory_limiter
- filelog receiver (/var/log/pods)
- → memory_limiter (see above)
memory_limiter en premier (refuser des données avant de manquer de mémoire), la rédaction avant tout export, batch en dernier (compresser de nombreux enregistrements par requête). Déployez-le deux fois : un petit agent par nœud (DaemonSet : logs des conteneurs, métriques de l'hôte, OTLP local, métadonnées des pods, buffer disque) et une gateway mise à l'échelle (3+ réplicas : tail sampling, rédaction, mapping OCSF, seul endroit détenant les identifiants des backends).Extrait de la fiche « Observability and Security Telemetry Pipelines » · Demander la fiche complète
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.
| Quantity | Formula | Example (SLO 99.9 %, 30 days) |
|---|---|---|
| Error budget | B = 1 - SLO | 0.1 % of requests, ≈ 43 min of full outage |
| Burn rate | r = e / B | e = 1.44 % errors → r = 14.4 |
| Budget used in a period | u = r × Δ t / T | 14.4 × 1 h / 720 h = 2 % |
| Page | r ≥ 14.4 over 1 h and 5 min | 2 % of the monthly budget in one hour |
| Page | r ≥ 6 over 6 h and 30 min | 5 % of the budget in six hours |
| Ticket | r ≥ 1 over 3 d and 6 h | 10 % of the budget in three days |
Extrait de la fiche « System and Serving KPIs » · Demander la fiche complète