Observabilité : du SLO à l'astreinte sereine

L'observabilité n'est plus un sujet de plateforme, c'est un sujet produit. Quand une équipe SRE doit défendre un release freeze auprès du CPO, elle a besoin de chiffres : un taux d'erreur mesuré sur une fenêtre glissante, un budget d'erreur consommé à 87 %, un p99 qui a doublé depuis le dernier déploiement. Sans cette donnée, la discussion se transforme en négociation politique. Voici comment structurer une stack qui produit ces chiffres, avec OpenTelemetry comme colonne vertébrale.

OpenTelemetry, la fin des agents propriétaires

Depuis que le projet OTel a atteint le statut GA sur les traces (2021), les métriques (2023) et maintenant les logs (stable en 2024 sur la plupart des SDK), il n'y a plus de raison technique d'instrumenter une application avec un agent propriétaire type Datadog APM ou New Relic Agent. Le pattern qui s'impose :

• SDK OTel dans le code applicatif (auto-instrumentation quand elle existe, manuelle pour la logique métier)
• OTel Collector en sidecar ou en DaemonSet, qui reçoit en OTLP et route vers un ou plusieurs backends
• Backend au choix : Grafana Tempo/Mimir/Loki, Elastic, Honeycomb, Datadog, Dynatrace… vous changez sans retoucher le code

Exemple minimal d'un pipeline Collector qui envoie les traces vers Tempo et duplique les métriques critiques vers Prometheus et Datadog :

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 5s
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 500 }

exporters:
  otlp/tempo:
    endpoint: tempo:4317
  prometheusremotewrite:
    endpoint: https://mimir/api/v1/push
  datadog:
    api:
      key: ${DD_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, batch]
      exporters: [otlp/tempo, datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheusremotewrite, datadog]

Le tail sampling est le point qui change tout en production : vous conservez 100 % des traces en erreur ou lentes, et 1 à 5 % du reste. Sur un service à 20 k req/s, on passe typiquement de 40 To/mois de traces à moins de 2 To, sans perdre le signal utile.

Les trois piliers, mais reliés

Métriques, logs et traces cessent d'être utiles quand ils vivent dans trois outils déconnectés. Le vrai gain vient de la corrélation via le trace_id propagé partout :

| Signal | Question à laquelle il répond | Outil typique | |---|---|---| | Métriques | Est-ce que ça va mal ? | Prometheus, Mimir | | Traces | Où ça va mal ? | Tempo, Jaeger, Honeycomb | | Logs | Pourquoi ça va mal ? | Loki, Elastic |

Un dashboard Grafana qui affiche un pic d'erreurs sur une métrique doit permettre en un clic d'accéder aux exemplars (traces échantillonnées attachées à un point de métrique), puis aux logs filtrés par trace_id. Sans cette continuité, votre MTTR reste dominé par le temps de recherche manuelle.

SLI, SLO et error budget : passer du vœu à la contrainte

Un SLO n'est pas un objectif de disponibilité affiché dans un slide de comité de direction. C'est une contrainte opérationnelle qui pilote les décisions de release. Le modèle Google reste la référence, et Sloth ou Pyrra permettent aujourd'hui de générer les règles Prometheus à partir d'un manifeste déclaratif.

version: prometheus/v1
service: checkout-api
slos:
  - name: availability
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{service="checkout",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
    alerting:
      page_alert:
        labels: { severity: page }
      ticket_alert:
        labels: { severity: ticket }

Sloth génère automatiquement les alertes multi-fenêtres (short/long burn rate) recommandées dans le SRE Workbook. Résultat : une alerte page uniquement quand le budget est consommé à un rythme qui menace le SLO mensuel, pas à chaque hoquet à 3 h du matin.

Error budget policy

Définir un SLO sans error budget policy est un exercice stérile. La policy doit être écrite, signée par produit et engineering, et déclencher des actions automatiques :

• Budget consommé à 50 % : revue post-mortem des incidents en cours de sprint
• Budget consommé à 75 % : gel des features non critiques, priorité à la fiabilité
• Budget épuisé : freeze complet des déploiements non liés à la stabilité

Rendre l'astreinte tenable

Une équipe qui reçoit plus de deux pages par semaine et par personne va se déliter en six mois. Quelques principes qui fonctionnent :

• Alertes basées sur les symptômes, pas sur les causes (alerter sur un taux d'erreur utilisateur, pas sur un CPU à 90 %)
• Runbooks liés à chaque alerte dans le payload PagerDuty/Opsgenie, avec les requêtes Grafana pré-remplies
• Rotation de 7 jours maximum, avec un secondary pour absorber les pics
• Blameless post-mortems dans les 48 h, avec au moins une action corrective priorisée dans le sprint suivant

Checklist de maturité observabilité

• [ ] Auto-instrumentation OTel déployée sur 100 % des services critiques
• [ ] Tail sampling actif en production
• [ ] Corrélation trace_id vérifiée entre métriques, logs et traces
• [ ] SLO définis pour chaque parcours utilisateur critique (pas par microservice)
• [ ] Alertes multi-window burn rate en place
• [ ] Error budget policy écrite et appliquée
• [ ] Chaque alerte page dispose d'un runbook testé
• [ ] Post-mortem systématique pour tout incident consommant > 10 % du budget

À retenir

• OpenTelemetry est le standard par défaut : instrumenter avec autre chose en 2025 crée une dette technique immédiate.
• Le tail sampling est la seule façon de garder des coûts sous contrôle sans perdre le signal.
• Un SLO sans error budget policy est un indicateur décoratif, pas un outil de pilotage.
• Les alertes multi-fenêtres (burn rate) réduisent drastiquement le bruit et protègent les équipes d'astreinte.
• La corrélation métrique → trace → log est ce qui fait passer le MTTR de la dizaine de minutes à quelques minutes.