Vous déployez votre application sur Kubernetes, les pods redémarrent sans raison apparente, et votre collègue vous dit “on n’a pas d’observabilité”. Mais par où commencer ? Installer Prometheus ? Ajouter des logs ? Acheter un SaaS ? Avant de choisir un outil, il faut comprendre les concepts. Cette section vous donne les modèles mentaux durables qui restent valables quel que soit l’outil que vous choisirez ensuite — Grafana, Datadog, Elastic ou autre.
Prérequis
Section intitulée « Prérequis »Cette section ne nécessite pas de compétences avancées, mais vous tirerez davantage des guides si vous avez :
- Déjà déployé une application (même simple) — un container Docker, un service sur un serveur, un site web
- Des notions de HTTP — savoir ce qu’est un code 200 ou 500, une requête GET/POST
- Lu des logs — avoir déjà regardé la sortie d’un
docker logsou d’unjournalctl - Des bases Linux — naviguer dans un terminal, lire un fichier de configuration
Si ces notions vous sont familières, vous êtes prêt.
Par où commencer selon votre situation
Section intitulée « Par où commencer selon votre situation »Parcours guidé
Section intitulée « Parcours guidé »Étape 1 — Comprendre la distinction fondamentale
Section intitulée « Étape 1 — Comprendre la distinction fondamentale »Tout commence par une question simple : quelle est la différence entre surveiller un système et le rendre observable ? Le monitoring détecte les problèmes que vous aviez anticipés (le CPU dépasse 90 %, le disque est plein). L’observabilité vous permet de diagnostiquer les problèmes que vous n’aviez pas prévus — la requête qui prend 8 secondes sur un chemin que personne n’avait testé, le micro-service qui bloque silencieusement parce qu’un pool de connexions est saturé.
La distinction repose sur un modèle issu de la théorie du contrôle : les known unknowns vs les unknown unknowns. Les deux approches sont complémentaires — jamais le monitoring ne remplace l’observabilité, et inversement.
Étape 2 — Savoir quoi mesurer
Section intitulée « Étape 2 — Savoir quoi mesurer »Vous savez maintenant que l’observabilité repose sur des signaux. Mais lesquels collecter en premier ? Sans cadre, les équipes mesurent ce qui est facile (CPU, RAM) plutôt que ce qui compte pour l’utilisateur (latence, erreurs). Trois frameworks donnent des réponses concrètes :
- Golden Signals (Google SRE) : latence, trafic, erreurs, saturation — la vision globale d’un service
- RED (Tom Wilkie) : rate, errors, duration — le focus API et microservices
- USE (Brendan Gregg) : utilization, saturation, errors — le focus infrastructure
En pratique, on combine souvent RED pour les services et USE pour l’infrastructure.
Étape 3 — Transformer les mesures en objectifs
Section intitulée « Étape 3 — Transformer les mesures en objectifs »Collecter des métriques ne suffit pas si personne ne s’accorde sur “assez fiable”. Les SLI (Service Level Indicators), SLO (Service Level Objectives) et error budgets transforment la question subjective “est-ce que ça marche ?” en décisions mesurables. Quand il reste 60 % du budget d’erreur, on peut déployer. Quand il est à 8 %, on gèle et on stabilise. C’est le mécanisme central du SRE qui arbitre entre vélocité et fiabilité, et c’est le langage commun entre les équipes techniques et le métier.
Glossaire express
Section intitulée « Glossaire express »Avant d’aller plus loin, voici les termes que vous croiserez dans tous les guides. Chaque page les définit en détail, mais ce résumé vous évite de décrocher dès la première lecture.
| Terme | Définition en une phrase |
|---|---|
| SLI (Service Level Indicator) | La métrique qui mesure la fiabilité vue par l’utilisateur (ex : % de requêtes < 300 ms) |
| SLO (Service Level Objective) | L’objectif que vous vous fixez sur un SLI (ex : 99.5 % de requêtes rapides sur 30 jours) |
| SLA (Service Level Agreement) | L’engagement contractuel envers un client, avec pénalités si non tenu |
| Error budget | La marge d’erreur tolérée par le SLO — tant qu’il en reste, on déploie ; quand il est épuisé, on stabilise |
| Burn rate | La vitesse à laquelle le budget d’erreur est consommé — un burn rate de 10× signifie qu’il sera épuisé 10 fois plus vite que prévu |
| Cardinalité | Le nombre de séries temporelles distinctes — explose quand un label a trop de valeurs (user_id, request_id) |
| Sampling | Garder un échantillon des traces au lieu de toutes les conserver — head-based (décision au départ) ou tail-based (décision après collecte) |
| Span | Une étape dans une trace distribuée — porte un nom, une durée, des attributs et un statut |
| Exemplar | Un lien entre un point de métrique et une trace précise — le losange cliquable dans Grafana |
| OTLP | OpenTelemetry Protocol — le format de transport standard entre les SDKs et le Collector |
Étape 4 — Comprendre les trois signaux en profondeur
Section intitulée « Étape 4 — Comprendre les trois signaux en profondeur »Les trois piliers de l’observabilité — logs, métriques, traces — ne sont pas interchangeables. Chacun a ses forces, son coût et ses conventions propres.
Les logs sont le signal le plus riche : chaque événement porte un contexte complet (qui, quoi, quand, pourquoi). Mais c’est aussi le signal le plus volumineux et le plus cher. La clé : les structurer en JSON avec des champs normalisés pour qu’ils deviennent interrogeables, et maîtriser leurs niveaux de sévérité (DEBUG → INFO → WARN → ERROR → FATAL).
Les métriques sont le signal le plus compact : un counter, un gauge ou un histogram résume des milliers d’événements en une seule valeur numérique. C’est le signal de premier recours pour l’alerting et les dashboards. Le piège : la cardinalité — un seul label à valeurs non bornées (user_id, request_id) peut multiplier les séries temporelles par des milliers et faire tomber Prometheus.
Les traces reconstituent le parcours complet d’une requête à travers tous
vos services. Chaque étape (span) porte sa durée, ses attributs et son status.
Le contexte se propage entre services via le header W3C Trace Context
(traceparent). Le sampling (head-based ou tail-based) contrôle le volume.
Étape 5 — Relier les signaux entre eux
Section intitulée « Étape 5 — Relier les signaux entre eux »Avoir des logs, des métriques et des traces, c’est bien. Pouvoir naviguer de
l’un à l’autre en un clic, c’est ce qui fait la différence en production. La
corrélation repose sur un principe simple : injecter le même trace_id dans
les trois signaux. Les exemplars relient une métrique à une trace précise (le
losange cliquable dans Grafana). Les data links créent des raccourcis entre
dashboards et Explore. Le résultat : vous passez de l’alerte à la cause racine
en quelques clics au lieu de quelques dizaines de minutes.
Étape 6 — Instrumenter avec un standard ouvert
Section intitulée « Étape 6 — Instrumenter avec un standard ouvert »OpenTelemetry (OTel) est le projet CNCF qui résout le problème du vendor lock-in : vous instrumentez vos applications une seule fois avec l’API OTel, et vous envoyez les données vers n’importe quel backend via le Collector. Le guide couvre les quatre composants (API, SDK, Collector, OTLP), les patterns de déploiement (sidecar, agent DaemonSet, gateway), la matrice de maturité par signal et les conventions sémantiques qui garantissent des noms d’attributs cohérents entre tous vos services.
Étape 7 — Gouverner pour durer
Section intitulée « Étape 7 — Gouverner pour durer »L’observabilité sans gouvernance est un poste de coûts qui croît plus vite que votre infrastructure. La dernière étape aborde les quatre leviers de durabilité : rétention adaptée (15 jours de résolution fine pour les métriques, 7-30 jours pour les logs, 7-15 jours pour les traces), cardinalité sous contrôle (relabeling, normalisation des chemins dynamiques), sécurité des données (masquage des PII et secrets avant stockage, conformité RGPD), et conventions partagées (nommage des métriques, labels obligatoires, niveaux de log standardisés). C’est le socle invisible qui rend tout le reste viable à l’échelle.
Les stacks d’observabilité
Section intitulée « Les stacks d’observabilité »Les concepts de cette section sont indépendants de l’outil choisi. Pour fixer les idées, voici les deux familles de stacks les plus courantes :
| Composant | Stack OSS typique | Stack SaaS typique |
|---|---|---|
| Métriques | Prometheus (collecte + stockage) | Datadog, New Relic, Dynatrace |
| Logs | Loki (stockage) + Alloy ou Fluentbit (collecte) | Datadog Logs, Elastic Cloud, Splunk |
| Traces | Tempo (stockage) + OTel Collector (collecte) | Datadog APM, New Relic, Honeycomb |
| Dashboards | Grafana | Intégré à chaque SaaS |
| Instrumentation | OpenTelemetry (API + SDK + Collector) | SDKs propriétaires ou OTel |
L’essentiel : les concepts (RED, USE, SLO, corrélation, cardinalité) restent identiques quelle que soit la stack. Les guides de cette section vous préparent à utiliser n’importe laquelle.
Les pièges classiques de l’observabilité
Section intitulée « Les pièges classiques de l’observabilité »Avant de plonger dans les guides, voici les cinq erreurs que les équipes font le plus souvent. Les reconnaître maintenant vous évitera de les reproduire :
| Piège | Pourquoi c’est un problème | Le guide qui en parle |
|---|---|---|
| Alerter sur CPU/RAM au lieu des signaux utilisateur | Vous êtes réveillé pour un CPU à 92 % qui n’impacte personne, et vous ratez la latence à 5 s qui impacte tout le monde | Modèles mentaux (RED/USE) |
| Tout logger en DEBUG en production | Volume × 10, coûts × 10, et le signal utile est noyé dans le bruit | Logs |
| Instrumenter sans conventions (labels chaotiques) | Impossible de corréler les services entre eux, dashboards incompatibles | Gouvernance |
| Confondre monitoring et observabilité | On empile des dashboards “au cas où” au lieu de construire la capacité à diagnostiquer l’imprévu | Obs vs monitoring |
| Croire qu’un outil = une stratégie | On installe Prometheus et Grafana, on déclare “on a l’observabilité” — mais personne ne sait quoi mesurer ni pourquoi | SLI, SLO |
Niveaux de maturité
Section intitulée « Niveaux de maturité »Où en êtes-vous aujourd’hui ? Ce modèle simple vous aide à situer votre organisation et à identifier la prochaine étape :
| Niveau | Ce que vous avez | Ce qui manque | Guides prioritaires |
|---|---|---|---|
| 1 — Réactif | Logs de base + métriques infra (CPU, RAM, disque) | Pas de signaux utilisateur, pas de corrélation | Modèles mentaux, Logs, Métriques |
| 2 — Structuré | RED/USE en place + alerting basique | Alertes bruyantes, pas d’objectifs formalisés | SLI/SLO, Traces |
| 3 — Proactif | SLO définis + traces distribuées + corrélation | Pas de standard d’instrumentation, vendor lock-in possible | OpenTelemetry, Corrélation |
| 4 — Gouverné | OTel + multi-tenant + conventions partagées + budgets cardinalité | Optimisation continue, policy-as-code | Gouvernance |
La plupart des organisations sont au niveau 1 ou 2. Les fondamentaux de cette section vous amènent au niveau 3 ; la page gouvernance vous donne les outils du niveau 4.
Vue d’ensemble
Section intitulée « Vue d’ensemble »| Guide | Question centrale | Ce que vous en retirez | Temps | Niveau |
|---|---|---|---|---|
| Observabilité vs monitoring | Quelle est la différence ? | Un modèle mental (known vs unknown unknowns) | 10 min | Débutant |
| Golden Signals, RED, USE | Quoi mesurer ? | Un arbre de décision par type de composant | 12 min | Débutant |
| SLI, SLO, Error Budget | C’est assez fiable ? | Un langage commun ops/métier + burn rate alerting | 15 min | Débutant → Intermédiaire |
| Logs | Que s’est-il passé ? | Format structuré, niveaux, pipeline, coûts | 20 min | Débutant |
| Métriques | Quel est l’état du système ? | 4 types, labels, cardinalité, conventions | 20 min | Débutant → Intermédiaire |
| Traces | Où est le goulet d’étranglement ? | Spans, propagation W3C, sampling | 18 min | Intermédiaire |
| Corrélation | Comment relier les signaux ? | trace_id, exemplars, workflow diagnostic | 15 min | Intermédiaire |
| OpenTelemetry | Comment instrumenter sans lock-in ? | API, SDK, Collector, OTLP, conventions sémantiques | 20 min | Intermédiaire |
| Gouvernance | Comment maîtriser les coûts ? | Rétention, cardinalité, RBAC, conventions | 25 min | Intermédiaire |