Monitoring vs observability cloud : 3 piliers et OpenTelemetry

Monitoring et observability sont confondus par défaut, alors qu’ils répondent à deux questions différentes. Le monitoring répond à « ma VM est-elle UP ? » — questions définies à l’avance avec seuils. L’observability répond à « pourquoi cette requête a-t-elle pris 3 secondes pour les utilisateurs européens en 4G hier soir ? » — questions imprévues exigeant une télémétrie riche. Cette page distingue les deux concepts, présente les 3 piliers universels (logs, metrics, traces), explique pourquoi OpenTelemetry s’est imposé comme standard 2026, et défend la discipline SLI/SLO/error budget comme pratique opérationnelle qui transforme l’observability en levier de qualité de service.

Ce que vous allez apprendre

La distinction monitoring (questions connues) vs observability (questions inconnues)
Les 3 piliers : logs, metrics, traces, et leur corrélation par trace ID
OpenTelemetry : pourquoi c’est le standard 2026 et comment l’adopter
La discipline SLI / SLO / error budget issue du SRE
Le défaut moderne — instrumentation OTel dès le J1

Prérequis : avoir compris la responsabilité partagée et l’asynchrone. Si besoin, lisez d’abord Synchrone vs asynchrone.

1. Monitoring vs observability — les deux questions différentes

Monitoring — répondre à des questions connues

Le monitoring consiste à surveiller des métriques pré-définies avec des seuils d’alerte. Vous savez à l’avance ce que vous voulez vérifier.

Exemples de questions monitoring :

Mon serveur est-il UP ?
Le CPU dépasse-t-il 80 % ?
La RAM dépasse-t-elle 90 % ?
Le disque est-il rempli à plus de 85 % ?
Y a-t-il des erreurs HTTP 500 dans les logs ?

Ces questions sont fermées : la réponse est binaire (oui / non, alerte / OK), définie à l’avance, mesurée sans surprise.

Outils typiques : Nagios, Zabbix, CloudWatch Metrics, Azure Monitor, Cloud Monitoring.

Observability — répondre à des questions inconnues à l’avance

L’observability consiste à collecter une télémétrie riche qui permet de répondre à des questions non prévues à l’avance, posées en investigation.

Exemples de questions observability :

Pourquoi cette requête utilisateur a-t-elle pris 3,2 secondes hier à 22h47 ?
Quels services ont contribué à la latence anormale entre 14h et 14h30 ?
L’augmentation de 15 % du temps de réponse coïncide avec quel déploiement ?
Quelle proportion d’erreurs 503 provient de quel service en aval ?
L’utilisateur premium #4242 voit-il une dégradation depuis sa dernière session ?

Ces questions sont ouvertes : on ne les connaît pas à l’avance, elles émergent en investigation, leur réponse exige une télémétrie riche, structurée, corrélable.

Outils typiques : Datadog, New Relic, Honeycomb, Grafana + Loki + Tempo + Mimir, OpenTelemetry-based tooling.

Pourquoi cette distinction matter

Aspect	Monitoring	Observability
Questions	Connues à l’avance	Imprévues
Données	Métriques numériques + seuils	Logs structurés + metrics + traces
Volume	Faible (échantillonnage)	Élevé (télémétrie riche)
Coût	Bas	Plus élevé
Cas d’usage	Alerter sur anomalies attendues	Diagnostiquer des comportements anormaux
Compétence requise	Lecture de seuils	Analyse exploratoire, querying

Sur un monolithe stable, monitoring suffit. Sur des microservices distribués où une requête traverse 12 services, observability est obligatoire. C’est cette distinction qui explique pourquoi l’observability est devenue un sujet à part entière dans les architectures modernes.

2. Les 3 piliers de l’observability

L’observability moderne s’appuie sur trois types de signaux complémentaires, chacun adapté à des questions différentes.

Pilier 1 — Logs (événements)

Les logs sont des événements textuels horodatés, typiquement structurés en JSON moderne. Ils racontent ce qui s’est passé dans l’application, ligne par ligne.

Exemples :

{"timestamp":"2026-04-28T14:32:18Z","level":"INFO","service":"order-service","trace_id":"abc123","msg":"Order created","order_id":12345,"customer_id":"cust-789","amount":89.50}
{"timestamp":"2026-04-28T14:32:18Z","level":"ERROR","service":"payment-service","trace_id":"abc123","msg":"Payment timeout","order_id":12345,"gateway":"stripe","duration_ms":30000}

Quand utiliser : compréhension fine du flux applicatif, contexte riche par événement, débogage des cas particuliers.

Outils 2026 : CloudWatch Logs, Azure Log Analytics, Cloud Logging, Loki, Splunk, Elastic Stack.

Pilier 2 — Metrics (mesures numériques)

Les metrics sont des mesures numériques échantillonnées à intervalles réguliers, agrégées dans le temps. Elles répondent au « combien » à un instant donné ou sur une période.

Exemples :

http_requests_total{service="api",method="GET",status="200"} 12453
cpu_usage_percent{instance="web-01"} 67.3
database_query_duration_seconds{quantile="0.99",query="SELECT users"} 0.043

Quand utiliser : tendances, alarmes, dashboards de santé en temps réel.

Outils 2026 : Prometheus, CloudWatch Metrics, Azure Monitor, Cloud Monitoring, Mimir, Datadog Metrics.

Pilier 3 — Traces (requêtes distribuées)

Les traces suivent une requête unique à travers tous les services qu’elle traverse. Chaque trace contient plusieurs spans (un span = une unité de travail dans un service).

Exemple visuel d’une trace de requête e-commerce :

[trace_id: abc123]
├─ frontend         (45 ms total)
│  ├─ DNS lookup    (5 ms)
│  ├─ HTTP request  (40 ms)
│  └─ render        (3 ms)
├─ api-gateway      (38 ms total)
│  └─ validate auth (8 ms)
└─ order-service    (28 ms total)
   ├─ db query      (12 ms)
   ├─ cache lookup  (2 ms)
   └─ payment-svc   (10 ms)  ← bottleneck identifié

Quand utiliser : comprendre où est passée la latence dans une architecture distribuée, identifier les bottlenecks, déboguer les corrélations entre services.

Outils 2026 : Jaeger, Zipkin, AWS X-Ray, Application Insights, Cloud Trace, Honeycomb, Tempo.

La corrélation par trace ID

Le vrai pouvoir de l’observability moderne vient de la corrélation entre les 3 piliers via un trace ID commun. Une requête utilisateur génère un trace ID au point d’entrée, ce trace ID se propage dans tous les logs, toutes les metrics, toutes les traces liées.

Avec un trace ID, vous pouvez :

Voir tous les logs de tous les services impliqués dans une requête.
Voir les metrics correspondantes (latence, débit) sur la fenêtre de temps.
Voir la trace de la requête dans son intégralité.

Sans trace ID partagé, les 3 piliers restent trois îlots déconnectés — vous savez qu’il y a une erreur quelque part, mais vous ne pouvez pas remonter jusqu’à la cause.

3. OpenTelemetry — le standard 2026

L’historique

Avant 2019, chaque outil d’observability avait son propre SDK d’instrumentation. Migrer de Datadog vers New Relic exigeait de réinstrumenter toute l’application. Le vendor lock-in était massif.

En 2019, deux projets concurrents (OpenTracing et OpenCensus) ont fusionné en OpenTelemetry (OTel), sous l’égide de la CNCF. L’objectif : un standard vendor-neutral d’instrumentation et de transport de la télémétrie.

OpenTelemetry est devenu le second projet le plus actif de la CNCF en 2023 (après Kubernetes). En 2026, c’est le standard de fait pour toute nouvelle instrumentation.

Les composants OpenTelemetry

SDKs et auto-instrumentation : disponibles pour toutes les langues majeures (Java, Python, Go, Node.js, .NET, Ruby, Rust). Auto-instrumentation pour les frameworks populaires (Spring, Express, FastAPI, Gin) — souvent sans modification de code applicatif.

Collector : agent qui reçoit la télémétrie depuis les applications, la transforme (filtrage, sampling, enrichissement) et l’envoie vers un ou plusieurs backends. Permet de changer de backend sans toucher au code applicatif.

Format de transport : protocole OTLP (OpenTelemetry Protocol), basé sur gRPC, supporté par tous les backends modernes.

Architecture typique

[Application avec SDK OTel]
        │
        │ OTLP (gRPC)
        ▼
[OpenTelemetry Collector]
        │
        ├──► Backend Logs (Loki, CloudWatch Logs)
        ├──► Backend Metrics (Prometheus, Mimir)
        └──► Backend Traces (Jaeger, Tempo, X-Ray)

Bénéfice principal : si vous voulez migrer de Datadog vers Grafana Cloud, ou vers une stack auto-hébergée Loki+Mimir+Tempo, vous changez la configuration du Collector — l’application ne change pas. Le vendor lock-in est neutralisé.

Qui supporte OTel en 2026

Backend / outil	Support OTel
Datadog	Natif (OTLP receiver)
New Relic	Natif
Honeycomb	Natif (créateur du standard)
Grafana Cloud	Natif
AWS X-Ray	Via ADOT (AWS Distro for OpenTelemetry)
Azure Monitor	Via Azure Monitor OpenTelemetry exporter
GCP Operations Suite	Natif
Splunk Observability Cloud	Natif

Conséquence : il n’y a plus aucune raison de démarrer en 2026 avec un SDK propriétaire. Tout nouveau projet doit s’instrumenter en OTel par défaut.

4. SLI / SLO / Error budget — la discipline SRE

Pourquoi mesurer

Avoir des dashboards riches ne sert à rien si l’équipe ne sait pas ce qu’est un service en bonne santé vs un service à risque. La discipline SRE (Site Reliability Engineering, popularisée par Google) répond avec trois concepts.

SLI — Service Level Indicator

Un SLI est une métrique précise qui mesure un aspect de qualité du service.

Exemples :

Pourcentage de requêtes HTTP qui retournent un statut 2xx ou 3xx (succès).
Pourcentage de requêtes dont la latence est inférieure à 200 ms.
Pourcentage de jobs batch complétés sans erreur dans les 4 heures.

Un bon SLI est mesuré du point de vue de l’utilisateur, pas du point de vue infrastructure. Le CPU à 50 % ne dit rien à l’utilisateur — la latence p95 à 800 ms, oui.

SLO — Service Level Objective

Un SLO est un objectif chiffré sur un SLI, sur une période donnée.

Exemples :

99,9 % des requêtes HTTP retournent succès sur 30 jours roulants.
95 % des requêtes ont une latence < 200 ms sur 7 jours.
99 % des batchs sont complétés sous 4 heures sur 30 jours.

Le SLO est l’engagement interne que l’équipe se fixe — distinct du SLA contractuel avec les clients (généralement plus permissif que le SLO interne). Cf. Disponibilité vs durabilité (SLA).

Error budget

L’error budget est ce qui reste sous le SLO. Si le SLO est 99,9 %, l’error budget est de 0,1 % — soit ~43 minutes d’indisponibilité autorisée par mois.

Comment l’utiliser :

L’error budget est consommé par les incidents. Si on dépasse, on est en faute SLO.
L’error budget est aussi consommé par les déploiements à risque, les expérimentations.
Une fois le budget épuisé, on freine : pas de nouveaux déploiements jusqu’à la fin de la période.
Tant que le budget est largement disponible, on peut prendre plus de risques (déployer plus souvent, tester en prod).

C’est un mécanisme de régulation entre vélocité de développement et fiabilité. Sans error budget, l’équipe oscille entre « on déploie tout, ça casse » et « on ne déploie plus, c’est figé ».

5. Le défaut moderne — instrumentation dès le J1

Sur un nouveau projet en 2026, voici la stack que je recommande.

Instrumentation applicative

OpenTelemetry SDK dès le J1, dans la langue de l’application.
Auto-instrumentation pour les frameworks (Spring Boot, FastAPI, Express).
Trace ID propagation automatique via headers traceparent (W3C Trace Context).
Logs structurés JSON avec trace ID et user ID inclus.
Custom metrics applicatives (business metrics : commandes/min, paniers actifs, conversions).

Stack de collecte

OpenTelemetry Collector déployé en sidecar ou daemonset Kubernetes.
Sampling côté Collector (typiquement 10 % des traces, 100 % des erreurs).
Filtrage côté Collector pour réduire le volume coûteux (DEBUG hors prod).
Routage vers backends spécialisés selon le type de signal.

Backends — choix multi-cloud

Type de signal	Choix souverain	Choix hyperscaler	Choix SaaS
Logs	Loki (auto-hébergé)	CloudWatch Logs	Datadog Logs
Metrics	Mimir (auto-hébergé)	CloudWatch Metrics	Datadog Metrics
Traces	Tempo (auto-hébergé)	X-Ray, Cloud Trace	Honeycomb, Datadog APM
Visualisation	Grafana	natif fournisseur	Datadog Dashboards

La stack Grafana Cloud ou Grafana auto-hébergé + Loki + Mimir + Tempo est devenue le standard ouvert pour les organisations qui veulent souveraineté et flexibilité. Sur les hyperscalers, les services natifs sont parfaitement utilisables avec OTel.

Discipline SLI / SLO

Définir 2 à 4 SLI par service critique, mesurables côté utilisateur.
Fixer des SLO réalistes, négociés avec le métier.
Calculer l’error budget mensuel ou trimestriel, le suivre en dashboard.
Politique d’arrêt déploiement quand le budget est épuisé.
Post-mortems déclenchés automatiquement à chaque consommation > 25 % du budget en un seul incident.

6. Bonnes pratiques pour une observability efficace

L’observability n’apporte de valeur que si elle est mise en place tôt, mesure les bonnes choses, et se traduit en décisions opérationnelles. Trois axes structurent une démarche utile.

Instrumenter dès le départ. Ajouter une instrumentation OpenTelemetry sur un nouveau service prend généralement quelques dizaines de minutes (SDK intégré, traces et metrics exportés). Ajouter cette même instrumentation plusieurs années plus tard, sur un parc de plusieurs dizaines de microservices déjà en production, demande la coordination de toutes les équipes et s’étale sur plusieurs mois. Démarrer instrumenté coûte quelques minutes par service ; rétrofiter coûte des mois pour l’organisation. La règle pratique consiste donc à instrumenter au démarrage, même si la stack d’observabilité n’est pas encore complètement définie : les données seront disponibles le jour où l’on en a besoin.

Articuler SLO et error budget. Afficher des SLO sur des tableaux de bord sans en tirer de conséquence opérationnelle revient à les transformer en simple décor. La discipline SRE consiste à calculer l’error budget consommé sur chaque période, à le suivre dans le temps, et à mettre en place une politique d’arrêt des déploiements lorsque le budget est dépassé. Sans cette articulation, les SLO existent sur le papier mais ne pilotent rien. Avec cette articulation, ils deviennent un mécanisme de régulation entre vélocité de déploiement et fiabilité.

Privilégier les SLI utilisateur aux métriques d’infrastructure. Beaucoup de tableaux de bord affichent CPU, RAM et disque — utiles pour le diagnostic, mais ce ne sont pas ces métriques que l’utilisateur perçoit. L’utilisateur mesure la latence et le succès de ses requêtes. Construire d’abord les SLI orientés utilisateur (latence p95/p99, taux d’erreur, débit), puis ajouter les métriques d’infrastructure pour le diagnostic, donne un signal beaucoup plus fidèle de la qualité de service réelle.

Utiliser un standard ouvert pour rester portable. OpenTelemetry (CNCF) fournit une instrumentation vendor-neutral : le code applicatif reste indépendant du backend (Grafana, service natif d’un fournisseur, ou autre). Cette portabilité offre une option de sortie sans réinstrumenter, ce qui devient un critère important si l’on souhaite pouvoir changer de backend d’observabilité.

À retenir

Monitoring = répondre à des questions connues avec seuils. Observability = répondre à des questions inconnues avec télémétrie riche.
3 piliers : logs (événements textuels), metrics (mesures numériques), traces (requêtes distribuées).
La corrélation par trace ID entre les 3 piliers est ce qui rend l’observability vraiment puissante.
OpenTelemetry (CNCF) est le standard 2026 — instrumentation vendor-neutral, portable entre backends.
SLI / SLO / error budget est la discipline SRE qui transforme l’observability en levier opérationnel.
Bonnes pratiques : instrumenter dès le démarrage, mesurer des SLI orientés utilisateur, articuler SLO et error budget pour qu’ils pilotent réellement les décisions.

Prochaines étapes

Disponibilité vs durabilité (SLA) Le SLA contractuel vs SLO interne — articulation des deux.

Résilience cloud : HA, DR, chaos engineering L'observability est la fondation du chaos engineering.

Surveillance et détection des menaces L'application sécurité de l'observability cloud.

Synchrone, asynchrone, eventual consistency Pourquoi l'observability est obligatoire sur les architectures distribuées.