Observabilité moderne : d'OpenTelemetry aux SLO

L'observabilité n'est plus un luxe réservé aux GAFAM. Avec des architectures distribuées (microservices, serverless, event-driven) et des équipes produit qui livrent plusieurs fois par jour, la capacité à comprendre l'état d'un système en production conditionne directement la vélocité business. Pourtant, beaucoup d'équipes confondent encore monitoring (surveiller des seuils connus) et observability (poser des questions arbitraires sur le système sans redéployer).

Voici comment nous structurons les missions d'observabilité chez DCT, de l'instrumentation jusqu'aux rotations on-call.

OpenTelemetry : le standard de fait

Depuis 2024, OpenTelemetry (OTel) est devenu le standard CNCF incontournable pour l'instrumentation. Il remplace progressivement les SDK propriétaires de Datadog, New Relic ou Dynatrace côté collecte. L'avantage est stratégique : vous découplez l'instrumentation du backend d'analyse. Changer de fournisseur ne demande plus de réinstrumenter 200 services.

L'architecture type repose sur trois éléments :

• SDK OTel dans l'application (auto-instrumentation pour Java, Python, Node.js, Go)
• OpenTelemetry Collector déployé en sidecar ou DaemonSet, qui traite et route les signaux
• Backend(s) : Tempo/Loki/Mimir (Grafana stack), ClickHouse + SigNoz, Honeycomb, Datadog, etc.

Exemple minimal d'instrumentation Python avec auto-instrumentation FastAPI :

from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
)
trace.set_tracer_provider(provider)

app = FastAPI()
FastAPIInstrumentor.instrument_app(app)

En moins de dix lignes, chaque requête HTTP génère un span propagé via le header traceparent (W3C Trace Context). Couplé à l'instrumentation requests ou httpx, vous obtenez des traces distribuées de bout en bout.

Les trois piliers, et pourquoi la corrélation prime

Métriques, logs, traces : la trilogie est connue. Ce qui distingue une stack mature, c'est la corrélation entre ces signaux.

| Signal | Cas d'usage principal | Coût stockage | Cardinalité | |-----------|----------------------------------------|---------------|-------------| | Métriques | Alerting, dashboards SLO | Faible | Limitée | | Logs | Forensic, debug fin | Élevé | Illimitée | | Traces | Latence, dépendances inter-services | Moyen | Élevée |

La règle pratique : injectez systématiquement le trace_id dans vos logs structurés (JSON). Sur Grafana ou SigNoz, un clic depuis une métrique en dérive vous emmène sur les traces concernées, puis sur les logs du span. Sans cette corrélation, vos ingénieurs perdent 15 à 30 minutes par incident à recoller les morceaux.

SLI/SLO : passer de l'alerte symptôme à l'alerte usager

La pratique SRE popularisée par Google reste sous-utilisée en Europe. Pourtant, définir des SLI (Service Level Indicators) orientés utilisateur permet de réduire drastiquement le bruit d'alerting.

Un SLI pertinent répond à : « Quel pourcentage de requêtes utilisateur sont servies correctement et rapidement ? »

Exemple concret pour une API de checkout :

• SLI disponibilité : (requêtes 2xx + 3xx + 4xx hors 429) / requêtes totales
• SLI latence : requêtes < 300ms / requêtes totales
• SLO : 99,5 % sur 28 jours glissants

L'error budget correspondant est de 0,5 % × volume mensuel. S'il est consommé à 80 %, on gèle les déploiements non critiques. S'il est consommé à 100 %, on bascule en mode stabilisation. Ce mécanisme aligne enfin le produit et la prod sur une même métrique négociable.

Des outils comme Sloth (générateur de règles Prometheus à partir de manifestes YAML) ou OpenSLO standardisent cette définition en GitOps.

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

On-call : la dette humaine de l'observabilité

Une stack observable mal calibrée fatigue les équipes. En 2025, les benchmarks que nous observons chez nos clients :

• < 2 pages par astreinte de 7 jours : sain
• 2 à 5 pages : zone de vigilance, audit des seuils nécessaire
• > 5 pages : burnout assuré sous 6 mois

Quelques pratiques qui fonctionnent :

• Chaque alerte page DOIT pointer vers un runbook versionné (Markdown dans le repo du service)
• Post-mortems blameless systématiques au-delà de 30 minutes d'impact
• Rotation minimum 6 personnes pour éviter la concentration
• Compensation explicite (financière ou récup), sinon attrition garantie

Des plateformes comme PagerDuty, Grafana OnCall ou incident.io intègrent désormais l'analyse de la charge d'astreinte (MTTA, MTTR, fréquence) pour piloter cette dette.

Checklist de maturité observabilité

• [ ] OpenTelemetry SDK déployé sur > 80 % des services
• [ ] trace_id injecté dans tous les logs structurés
• [ ] Au moins un SLO défini et publié pour chaque service critique
• [ ] Error budget tracké et revu en sprint review
• [ ] Runbook lié à chaque alerte de niveau page
• [ ] Post-mortems blameless archivés et indexés
• [ ] Coût d'ingestion télémétrie suivi mensuellement (cardinalité !)

À retenir

• OpenTelemetry est le choix par défaut en 2025 : il découple instrumentation et backend, ce qui protège vos investissements sur 5 ans.
• La corrélation métriques/logs/traces via trace_id est ce qui distingue une stack mature d'un empilement d'outils.
• Les SLO orientés utilisateur réduisent le bruit d'alerting et créent un langage commun produit/SRE.
• L'error budget est un levier de gouvernance, pas une métrique vanity.
• L'on-call est un système socio-technique : surveiller la charge humaine est aussi important que le MTTR.