1. Du Monitoring classique à l’Observabilité moderne

Alors que le monitoring traditionnel se borne à poser une question binaire (« Le serveur web répond-il sur le port 80 ? »), l’Observabilité mesure la capacité à déduire l’état interne d’un système distribué complexe à partir de l’analyse de ses sorties externes, permettant d’expliquer des comportements imprévus et inédits (« Pourquoi 3% des requêtes de paiement depuis Genève subissent-elles une latence de 4 secondes ? »).

2. Le triptyque fondamental : Logs, Métriques et Traces (LMT)

  • Métriques (Metrics) : Valeurs numériques mesurables agrégées sous forme de séries temporelles (taux d’occupation CPU, consommation RAM, nombre de requêtes par seconde). Stockées dans Prometheus ou Amazon CloudWatch et visualisées sous Grafana.
  • Journaux d’événements (Logs) : Enregistrements textuels horodatés détaillant un événement survenu à un instant T. Centralisés via la pile Grafana Loki ou Elasticsearch / Logstash / Kibana (ELK).
  • Traces distribuées (Traces) : Suivi du cheminement d’une requête utilisateur à travers une cascade de microservices grâce à l’injection d’un identifiant unique (TraceID). Standardisé par OpenTelemetry (OTel) et visualisé avec Jaeger.

3. Définition des objectifs de service : SLA, SLO et SLI

La culture Site Reliability Engineering (SRE) aligne les équipes techniques et métiers autour de trois notions :

+--------------------------------------------------------------------------------+
| SLI (Service Level Indicator) : Ce que nous mesurons en temps réel             |
| Exemple : "99.82% des requêtes HTTPS ont répondu avec succès en moins de 300 ms"|
+--------------------------------------------------------------------------------+
| SLO (Service Level Objective) : L'objectif cible que l'équipe s'engage à tenir |
| Exemple : "99.9% des requêtes doivent réussir au cours des 30 derniers jours"  |
+--------------------------------------------------------------------------------+
| SLA (Service Level Agreement) : L'engagement contractuel avec pénalités        |
| Exemple : "En dessous de 99.5% de disponibilité mensuelle, remboursement de 15%"|
+--------------------------------------------------------------------------------+

4. L’Error Budget (Budget d’erreur) et la gestion des alertes

L’Error Budget est la marge d’échec tolérée par le SLO (ex: 0.1% d’indisponibilité sur un mois, soit environ 43 minutes). Tant que ce budget n’est pas consommé, les développeurs peuvent déployer des fonctionnalités innovantes à grande vitesse. Dès que le budget d’erreur est épuisé par des incidents, les déploiements de nouvelles fonctionnalités sont gelés au profit exclusif de la fiabilisation de l’infrastructure.

Prévention de la fatigue d’alerte : Ne réveillez jamais un ingénieur d’astreinte au milieu de la nuit pour un voyant jaune. Une alerte critique (PagerDuty / Opsgenie) ne doit se déclencher que si le budget d’erreur se consume à une vitesse anormale (Burn Rate) et requiert une action humaine urgente et documentée.

Previous