---
title: "L'Observabilité - Document Technique"
canonical: "https://blog.kaptus.net/space/BKAP/blog/965050371/L'Observabilit%C3%A9%20-%20Document%20Technique"
format: markdown
---
> Macro (toc)

# 1. Introduction

## 1.1. Définitions : observabilité vs monitoring

Le **monitoring** consiste à surveiller un ensemble prédéfini d'indicateurs pour détecter des états connus et anticipés. On instrumente le système en fonction des questions que l'on sait devoir poser : 

- la charge CPU dépasse-t-elle un seuil ?
- Le taux d'erreur HTTP est-il anormal ?
- Le disque est-il plein ?

Le monitoring répond efficacement aux *known-unknowns* — les modes de défaillance que l'on a su prévoir.

L'**observabilité** est une propriété du système, empruntée à la théorie du contrôle : c'est la capacité à inférer l'état interne d'un système à partir de ses seules sorties externes. Un système est observable lorsque ses signaux de télémétrie sont suffisamment riches pour permettre de répondre à des questions arbitraires sur son comportement, *sans avoir à déployer de nouveau code*. L'observabilité vise donc les *unknown-unknowns* — les défaillances émergentes que l'on n'avait pas anticipées, caractéristiques des architectures distribuées et des systèmes complexes.

La distinction n'est pas d'opposition mais de degré et de finalité. Le monitoring est une pratique ; l'observabilité est une capacité. Le premier vous alerte que quelque chose ne va pas ; la seconde vous permet de comprendre *pourquoi*. Un système correctement rendu observable rend le monitoring plus pertinent, car les tableaux de bord et les alertes deviennent des vues particulières sur une télémétrie fondamentalement plus riche et explorable.

## 1.2. Enjeux et objectifs

L'observabilité répond à des enjeux opérationnels, contractuels et économiques mesurables.

**Réduction du MTTR.** Le *Mean Time To Recovery* — et ses composantes de détection (MTTD) et de diagnostic — constitue le principal indicateur d'efficacité opérationnelle. Dans une architecture distribuée, la localisation d'une panne peut représenter l'essentiel du temps d'indisponibilité. Une télémétrie corrélée (métriques, logs, traces) permet de passer d'un symptôme à sa cause racine sans reconstruction manuelle du contexte, et fait basculer le diagnostic d'une exploration par hypothèses successives à une navigation guidée par les données.

**Pilotage par les SLO/SLA.** Les ***Service Level Objectives*** définissent des cibles internes de qualité de service (disponibilité, latence, taux d'erreur), généralement plus strictes que les engagements contractuels des ***Service Level Agreements*** opposables au client. L'observabilité fournit la mesure fiable des ***Service Level Indicators*** sur lesquels reposent ces objectifs, et permet le suivi des *error budgets* qui arbitrent l'équilibre entre vélocité de livraison et stabilité.

**Gestion de la capacité.** L'analyse des tendances de consommation de ressources sous-tend le dimensionnement, la planification de croissance et la maîtrise des coûts d'infrastructure. L'observabilité alimente aussi bien la réaction immédiate (autoscaling) que la planification à moyen terme.

**Maîtrise des coûts de la donnée elle-même.** La télémétrie a un coût de collecte, de transport, de stockage et de requêtage qui croît avec le volume et la cardinalité. Un objectif transversal du document est d'articuler richesse de la donnée et soutenabilité économique.

## 1.3. Périmètre du document

Ce document traite de l'observabilité des systèmes et applications côté infrastructure et *backend*. Il couvre les fondements conceptuels, les trois piliers de la télémétrie (métriques, logs, traces), le standard OpenTelemetry, les stratégies de corrélation et d'exploitation, ainsi qu'une architecture de référence assortie de bonnes pratiques.

Le propos privilégie les solutions *open source* et les standards ouverts, cohérents avec un déploiement auto-hébergé sur infrastructure maîtrisée. Les exemples s'appuient sur l'écosystème Prometheus / Grafana / OpenTelemetry.

Sont hors périmètre : l'observabilité *front-end* et *Real User Monitoring* (RUM), l'*Application Performance Monitoring* propriétaire des suites commerciales, ainsi que les aspects spécifiques aux plateformes *serverless* et *mobiles*, qui ne sont évoqués que lorsqu'ils éclairent un principe général.

---

# 2. Fondamentaux

## 2.1. Les trois piliers : métriques, logs, traces

La télémétrie d'un système observable repose classiquement sur trois types de signaux, dont la complémentarité tient à des compromis distincts entre coût, granularité et portée.

Les **métriques** sont des mesures numériques agrégées, échantillonnées à intervalle régulier et associées à un instant. Une métrique occupe un volume constant et faible quelle que soit l'activité sous-jacente : son coût est décorrélé du débit de requêtes. Elle se prête à l'agrégation, au calcul de tendances et au déclenchement d'alertes sur de longues fenêtres temporelles. Sa limite tient à sa nature agrégée : une métrique indique *qu'un* problème existe, rarement *lequel* précisément, car le détail individuel des événements est perdu au profit de la synthèse statistique.

Les **logs** sont des enregistrements discrets et horodatés d'événements. Ils portent le détail contextuel — le message, l'identifiant de l'entité concernée, la pile d'appel d'une erreur. Leur granularité est maximale, mais leur volume croît linéairement avec l'activité, ce qui en fait le pilier le plus coûteux à collecter, indexer et conserver. Le log répond à la question « que s'est-il exactement passé sur cet événement précis ? ».

Les **traces** reconstruisent le cheminement complet d'une requête à travers les composants d'un système distribué. Elles portent la dimension causale et temporelle : quel service a appelé quel autre, dans quel ordre, avec quelle latence à chaque étape. La trace est l'outil de diagnostic des architectures réparties, là où une vue par service isolé ne permet pas de reconstituer le parcours transverse.

Le modèle des « trois piliers » est un point d'entrée pédagogique commode, mais il a été critiqué à juste titre : traités en silos, ces trois signaux imposent à l'opérateur de corréler manuellement trois outils distincts. L'approche moderne — développée dans les paragraphes 6 et 7 — vise au contraire une télémétrie unifiée où les signaux partagent un contexte commun et se naviguent de l'un à l'autre.

## 2.2. Les signaux complémentaires : événements, profiling

Aux trois piliers historiques s'ajoutent deux signaux dont l'usage s'est généralisé.

Les **événements** sont des enregistrements structurés marquant un changement d'état significatif : 

- un déploiement,
- un *scaling*,
- un changement de configuration,
- une bascule de leader.

Distincts du log applicatif par leur portée systémique, ils fournissent le contexte de corrélation indispensable à l'analyse — une dégradation de latence coïncidant avec un déploiement se diagnostique immédiatement dès lors que l'événement est disponible sur la même échelle de temps que les métriques.

Le **profiling continu** échantillonne en production l'usage des ressources au niveau du code : consommation CPU, allocations mémoire, attente sur verrous, agrégées par fonction ou pile d'appel. Il comble le dernier fossé du diagnostic : là où la trace localise la latence *dans un service*, le profil la localise *dans le code* de ce service. Son adoption a été favorisée par des techniques d'échantillonnage à faible surcoût (eBPF notamment).

## 2.3. Cardinalité, dimensions et labels

Un signal de télémétrie n'est pleinement exploitable que s'il porte des **dimensions** — des paires clé/valeur, appelées *labels* ou *tags*, qui qualifient la mesure : nom du service, méthode HTTP, code de statut, instance, région. Ces dimensions permettent le filtrage, le regroupement et l'agrégation *a posteriori*.

La **cardinalité** désigne le nombre de combinaisons distinctes de valeurs de labels pour une métrique donnée. Elle est le produit du nombre de valeurs possibles de chaque dimension : une métrique portant 10 services × 20 routes × 5 codes de statut engendre 1 000 séries temporelles distinctes. La cardinalité croît multiplicativement, non additivement — c'est le point de vigilance central de toute conception de télémétrie.

Le danger provient des dimensions à cardinalité non bornée : 

- identifiant utilisateur,
- adresse IP,
- identifiant de requête,
- horodatage.

Placées en label de métrique, elles provoquent une explosion combinatoire (*cardinality explosion*) qui sature la mémoire et l'index du système de stockage, dégrade les performances de requêtage et peut conduire à l'indisponibilité de la plateforme d'observabilité elle-même. La règle est que ces dimensions à haute cardinalité relèvent des logs et des traces — où chaque enregistrement est indépendant — et non des métriques, dont l'économie repose précisément sur la borne du nombre de séries.

## 2.4. Push vs Pull

Les modèles de collecte se répartissent en deux paradigmes.

Dans le modèle **pull**, le système de collecte interroge périodiquement les cibles sur un point d'exposition qu'elles publient (le *scraping* de Prometheus en est l'archétype). L'initiative appartient au collecteur, qui maîtrise ainsi la fréquence d'échantillonnage et dispose nativement d'un signal de disponibilité : une cible injoignable est immédiatement détectée. La découverte de cibles (*service discovery*) et l'accessibilité réseau des points d'exposition en sont les contraintes principales.

Dans le modèle **push**, les sources émettent spontanément leur télémétrie vers un point de collecte. Il s'impose lorsque la cible est éphémère ou non joignable en continu — traitements *batch*, fonctions *serverless*, agents derrière un NAT — et lorsque la nature événementielle du signal (logs, traces) exclut tout échantillonnage périodique. Il déplace la maîtrise du débit vers la source et requiert des mécanismes de *backpressure* et de mise en tampon pour absorber les pics.

En pratique, les deux modèles coexistent : le pull domine la collecte de métriques d'infrastructure, le push s'impose pour les logs, les traces et les charges éphémères. Le Collector OpenTelemetry, étudié en section 6, sait recevoir selon les deux modèles et sert précisément de point de médiation entre eux.

---

# 3. Métriques

## 3.1. Types (counter, gauge, histogram, summary)

Quatre types de métriques couvrent l'essentiel des besoins d'instrumentation.

Le **counter** est un compteur cumulatif monotone croissant, remis à zéro seulement au redémarrage du processus. Il compte des occurrences : 

- requêtes traitées,
- erreurs,
- octets émis.

Sa valeur absolue importe peu ; c'est sa dérivée temporelle qui est exploitée — le taux par seconde obtenu via `rate()`. La monotonie permet au système de requêtage de détecter et corriger automatiquement les remises à zéro.

La **gauge** est une valeur instantanée qui monte et descend librement : température, occupation mémoire, nombre de connexions actives, profondeur d'une file. Contrairement au counter, sa valeur courante est directement significative. On lui applique des agrégations instantanées (min, max, moyenne) plutôt que des taux.

L'**histogram** échantillonne des observations (typiquement des durées ou des tailles) et les répartit dans des tranches (*buckets*) aux bornes prédéfinies. Il expose des counters cumulatifs par tranche, la somme et le nombre total d'observations. L'agrégation des tranches est réalisée côté serveur, ce qui permet de calculer des quantiles *après* collecte et surtout de les agréger correctement à travers plusieurs instances — propriété essentielle en environnement distribué. Le choix des bornes est déterminant : mal calibrées, elles rendent les quantiles imprécis. Les *histograms natifs* (à tranches exponentielles auto-adaptatives) lèvent en partie cette contrainte.

Le **summary** calcule les quantiles côté client, au moment de l'observation. Il évite le choix des bornes et offre une précision maîtrisée sur les quantiles ciblés, mais présente deux limites majeures : les quantiles pré-calculés ne sont **pas agrégeables** entre instances (la moyenne de deux médianes n'est pas une médiane), et le coût de calcul est reporté sur l'application. En contexte distribué, l'histogram est presque toujours préférable.

## 3.2. Méthodologies : RED, USE, Four Golden Signals

Trois méthodologies structurent le choix des métriques à instrumenter, chacune adaptée à un point de vue.

La méthode **USE** (*Utilization, Saturation, Errors*), due à Brendan Gregg, s'applique aux **ressources** — CPU, mémoire, disque, interfaces réseau. Pour chaque ressource : son taux d'utilisation, sa saturation (le travail en attente qu'elle ne peut absorber, typiquement une longueur de file), et son taux d'erreurs. Elle adopte le point de vue de l'infrastructure et excelle au diagnostic des goulots d'étranglement.

La méthode **RED** (*Rate, Errors, Duration*), due à Tom Wilkie, s'applique aux **services** orientés requêtes : le débit de requêtes, le taux de requêtes en erreur, la distribution des durées de traitement. Elle adopte le point de vue de l'utilisateur du service et convient à l'instrumentation homogène d'une architecture microservices.

Les **Four Golden Signals** du *Site Reliability Engineering* de Google — latence, trafic, erreurs, saturation — constituent une synthèse : ils reprennent la triade RED (latence, trafic, erreurs) et y adjoignent la saturation, empruntée à USE, comme indicateur avancé de dégradation à venir.

USE et RED ne s'opposent pas : elles se complètent selon que l'on observe une ressource ou un service. Une pratique courante consiste à instrumenter les services en RED et l'infrastructure sous-jacente en USE, la corrélation des deux vues accélérant le diagnostic.

## 3.3. Collecte (Prometheus, OpenTelemetry, exporters)

Dans l'écosystème Prometheus, la collecte suit le modèle *pull* : le serveur *scrape* périodiquement un point d'exposition HTTP (`/metrics`) où chaque cible publie ses métriques au format texte OpenMetrics.

Trois voies produisent ce point d'exposition. L'**instrumentation directe** intègre une bibliothèque client dans le code applicatif, qui expose les métriques métier propres à l'application. Les **exporters** traduisent en format Prometheus les métriques de systèmes tiers non nativement instrumentés : *node_exporter* pour les métriques système Linux, *mysqld_exporter* pour MariaDB/MySQL, *blackbox_exporter* pour les sondes réseau externes. Le **Pushgateway**, enfin, sert de tampon pour les traitements *batch* trop éphémères pour être *scrapés*, sans être détourné de ce rôle strict.

La découverte de cibles (*service discovery*) automatise l'inventaire des points à *scraper* — fichiers statiques, DNS, ou intégrations avec l'orchestrateur — évitant toute reconfiguration manuelle lors des changements de topologie.

## 3.4. Stockage TSDB et rétention

Une base de données temporelle (*Time Series Database*) est optimisée pour l'écriture massive en append de couples (horodatage, valeur) indexés par un jeu de labels, et pour la lecture par plages temporelles. Les techniques de compression exploitent la régularité des horodatages (*delta-of-delta*) et la faible variation des valeurs successives (*XOR*) pour atteindre des ratios de l'ordre de quelques bits par point.

La **TSDB locale de Prometheus** organise les données en blocs immuables de deux heures, compactés progressivement en blocs plus larges, précédés d'un journal d'écriture anticipée (*WAL*) qui garantit la durabilité. Cette conception est performante mais volontairement mono-nœud : elle ne gère nativement ni la haute disponibilité, ni le stockage long terme, ni la vue globale sur plusieurs serveurs.

Ces limites motivent les solutions de **stockage long terme** :

- **Thanos** adjoint à chaque Prometheus un *sidecar* qui verse les blocs vers un stockage objet (S3), et fédère les instances via une couche de requêtage globale avec dédoublonnage.
- **Mimir** reprend une architecture horizontalement scalable dérivée de Cortex, conçue pour de très gros volumes multi-tenant.
- **VictoriaMetrics** propose une alternative réputée pour son efficacité mémoire et sa compression, disponible en mono-nœud ou en cluster.

La politique de **rétention** applique généralement une dégradation par âge : la donnée récente est conservée à pleine résolution pour le diagnostic fin, puis sous-échantillonnée (*downsampling*) pour l'analyse de tendance à long terme, arbitrant ainsi entre coût de stockage et profondeur d'historique.

## 3.5. Requêtage (PromQL)

**PromQL** est un langage fonctionnel dédié à l'interrogation des séries temporelles. Son unité fondamentale est le sélecteur, qui filtre les séries par nom de métrique et par labels :

```plaintext
http_requests_total{job="api", status=~"5.."}
```

Il distingue deux natures de données. Un ***instant vector*** est l'ensemble des valeurs de chaque série à un instant donné ; un ***range vector*** est l'ensemble des valeurs sur une fenêtre temporelle, dénotée par un crochet (`[5m]`), et sert d'entrée aux fonctions de taux.

La fonction `rate()` calcule le taux moyen d'accroissement par seconde d'un counter sur la fenêtre indiquée :

```plaintext
rate(http_requests_total{job="api"}[5m])
```

Les opérateurs d'agrégation réduisent la dimensionnalité en regroupant les séries selon les labels conservés :

```
sum by (status) (rate(http_requests_total[5m]))
```

Le calcul de quantile s'appuie sur les tranches d'un histogram :

```plaintext
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Deux familles de fonctions sont propres au caractère cumulatif des counters : `rate()` et `irate()` pour le taux moyen ou instantané, `increase()` pour l'accroissement absolu sur une fenêtre. Toutes gèrent nativement les remises à zéro. Ces expressions constituent aussi bien la matière des tableaux de bord que la base des règles d'enregistrement (*recording rules*) et d'alerte, étudiées en section 7.

---

# 4. Logs

## 4.1. Logs structurés vs non structurés

Un log **non structuré** est une ligne de texte libre destinée à la lecture humaine :

```
2026-09-14 10:23:41 ERROR Connexion refusée pour user 4821 depuis 10.0.0.5
```

Exploitable à l'œil sur un fichier, il devient coûteux à traiter en masse : chaque champ doit être extrait par expression régulière ou *grok pattern*, opération fragile qui se casse au moindre changement de format et qui pèse lourdement sur la chaîne d'ingestion.

Un log **structuré** encode l'événement sous forme de paires clé/valeur, typiquement en JSON :

```json
{"ts":"2026-09-14T10:23:41Z","level":"error","msg":"connexion refusée","user_id":4821,"src_ip":"10.0.0.5"}
```

Les champs sont directement adressables, sans *parsing* ambigu. Le filtrage, l'agrégation et la corrélation deviennent des opérations sur des champs typés. La structuration est le prérequis d'une exploitation industrielle des logs : elle transforme un flux de texte en un flux de données interrogeables.

## 4.2. Niveaux, corrélation et enrichissement

Les **niveaux de sévérité** (`TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `FATAL`) hiérarchisent les événements et pilotent le filtrage à l'émission comme à l'exploitation. Leur discipline conditionne le rapport signal/bruit : un usage laxiste — erreurs classées en `WARN`, information de débogage laissée en `INFO` en production — ruine la pertinence du filtrage et gonfle inutilement le volume.

La **corrélation** est la fonction qui fait passer le log de l'îlot au réseau. En propageant dans chaque log les identifiants de contexte — `trace_id`, `span_id`, identifiant de requête — on rattache l'événement discret au parcours distribué dont il fait partie. C'est ce champ partagé qui autorise la navigation d'une trace vers ses logs et réciproquement (section 7.1). Sans lui, les trois piliers restent trois silos.

L'**enrichissement** ajoute au log des dimensions issues de son environnement d'exécution : nom et version du service, instance, région, *tenant*. Réalisé le plus souvent à la collecte plutôt que dans le code applicatif, il découple la donnée métier du contexte de déploiement et garantit l'homogénéité des labels sur l'ensemble du parc.

## 4.3. Collecte et agrégation (Fluent Bit, Vector, Promtail)

Un **agent de collecte** s'exécute au plus près de la source, lit les logs (fichiers, *stdout*, *journald*, socket), les met en tampon, les transforme et les achemine vers le stockage. Ses fonctions caractéristiques sont l'analyse et la structuration, le filtrage, l'enrichissement par labels et la gestion de la *backpressure* — mise en tampon disque ou mémoire pour absorber l'indisponibilité momentanée de la destination sans perte.

- **Fluent Bit** est un agent léger, écrit en C, à faible empreinte, adapté au déploiement massif en périphérie comme collecteur de premier niveau.
- **Vector**, écrit en Rust, se distingue par un langage de transformation expressif (VRL) et un modèle unifié traitant logs, métriques et événements dans un même *pipeline*.
- **Promtail** est l'agent historiquement associé à Loki, spécialisé dans la découverte de cibles et l'étiquetage cohérent avec l'écosystème Prometheus. Sa maintenance est aujourd'hui reprise par l'*Alloy* de Grafana, distribution du Collector OpenTelemetry.

Une architecture à deux étages est fréquente : des agents légers en périphérie relaient vers un ou plusieurs collecteurs d'agrégation centraux, qui concentrent les transformations lourdes et régulent le débit vers le stockage.

## 4.4. Stockage et indexation (Loki, Elasticsearch/OpenSearch)

Deux philosophies de stockage s'opposent sur l'arbitrage entre coût d'ingestion et rapidité de requêtage.

**Elasticsearch / OpenSearch** indexent l'intégralité du contenu des logs au moyen d'un index inversé. La recherche plein texte y est immédiate et puissante, au prix d'un coût d'ingestion, d'un volume d'index et d'une empreinte mémoire élevés — l'index pouvant dépasser la taille de la donnée brute. Ce modèle convient lorsque la recherche textuelle arbitraire et rapide sur de larges historiques est le besoin dominant.

**Loki** procède à l'inverse : il n'indexe *que les labels*, pas le contenu des logs, qu'il conserve compressé en blocs sur stockage objet. L'ingestion est peu coûteuse et le stockage économique ; la requête procède par sélection d'un flux via ses labels puis balayage (*brute-force*) du contenu sur la fenêtre retenue. Ce compromis assume une recherche plein texte plus lente en échange d'un coût d'exploitation nettement inférieur, et s'aligne sur le modèle de labels de Prometheus — d'où sa cohérence dans une stack Grafana. La maîtrise de la cardinalité des labels y est aussi critique que pour les métriques : un label à haute cardinalité y fragmente les flux et dégrade les performances.

## 4.5. Requêtage (LogQL)

**LogQL** est le langage de requête de Loki, calqué sur PromQL pour l'homogénéité de l'écosystème. Une requête procède en deux temps : un **sélecteur de flux** par labels, puis un **filtre** sur le contenu des lignes.

```
{job="api", level="error"} |= "connexion refusée"
```

Le sélecteur `{job="api", level="error"}` restreint aux flux pertinents ; l'opérateur `|=` filtre les lignes contenant la sous-chaîne (`!=` pour l'exclusion, `|~` et `!~` pour les expressions régulières).

LogQL sait analyser des logs structurés à la volée et filtrer sur les champs extraits :

```
{job="api"} | json | status >= 500 | user_id="4821"
```

Ici `| json` décode le JSON de chaque ligne et expose ses champs, sur lesquels portent les filtres suivants.

Enfin, LogQL produit des métriques à partir des logs — c'est le pont des logs vers le monde des séries temporelles :

```
sum by (status) (rate({job="api"} | json [5m]))
```

Cette expression calcule un débit de logs par statut, directement traçable et exploitable en alerte au même titre qu'une métrique native, sans qu'il ait fallu instrumenter l'application d'un counter dédié.

---

# 5. Traces distribuées

## 5.1. Concepts : trace, span, contexte de propagation

Une **trace** représente le cheminement complet d'une requête à travers l'ensemble des composants qu'elle traverse. Elle est identifiée par un `trace_id` unique, propagé de bout en bout, et se compose d'un arbre de spans.

Un **span** est l'unité élémentaire de travail : une opération individuelle et bornée dans le temps — un appel HTTP, une requête SQL, un traitement interne. Chaque span porte un identifiant (`span_id`), une référence à son parent (`parent_span_id`), un nom d'opération, un horodatage de début et une durée. La relation parent/enfant reconstitue l'arborescence causale : le span racine correspond à l'entrée de la requête dans le système, ses descendants aux opérations qu'elle déclenche en cascade.

Un span porte en outre des **attributs** — paires clé/valeur qualifiant l'opération (méthode HTTP, code de statut, instruction SQL, *tenant*) — et des **événements**, marqueurs horodatés à l'intérieur du span (une exception, une étape notable). Cette richesse fait du span le signal à la fois le plus contextuel et le plus volumineux.

Le **contexte de propagation** (*context propagation*) est le mécanisme qui transporte `trace_id` et `span_id` d'un service à l'autre, généralement via des en-têtes de requête. Sans lui, chaque service produirait des spans isolés, impossibles à raccrocher à une trace commune. La propagation est la condition sine qua non de la traçabilité distribuée : c'est elle qui coud ensemble les fragments observés indépendamment par chaque service.

## 5.2. Standards (OpenTelemetry, W3C Trace Context)

L'interopérabilité de la propagation entre services hétérogènes suppose un format d'en-tête normalisé.

Le **W3C Trace Context** est la recommandation qui standardise ce transport via deux en-têtes HTTP. `traceparent` porte, sous une forme compacte, la version, le `trace_id`, le `span_id` du parent et les *flags* (dont la décision d'échantillonnage). `tracestate` véhicule des informations complémentaires propres aux fournisseurs. Cette normalisation a mis fin à la fragmentation antérieure des formats propriétaires (B3 de Zipkin, en-têtes Jaeger), qui empêchait la traçabilité de traverser des systèmes instrumentés par des outils différents.

**OpenTelemetry** (OTel), projet de la CNCF issu de la fusion d'OpenTracing et OpenCensus, s'est imposé comme le standard d'instrumentation et de télémétrie. Il définit un modèle de données commun aux trois signaux, des API et SDK par langage, un protocole d'échange (OTLP) et le Collector. Adopter W3C Trace Context pour la propagation et OTLP pour le transport garantit l'indépendance vis-à-vis des *backends* : l'instrumentation est découplée du choix de l'outil de stockage et d'analyse. OpenTelemetry fait l'objet de la section 6.

## 5.3. Instrumentation (auto vs manuelle)

L'**instrumentation automatique** produit les spans sans modification du code applicatif, en interceptant les bibliothèques standard — clients et serveurs HTTP, pilotes de base de données, clients de messagerie. Selon les langages, elle s'appuie sur un agent (injection d'octets en Java via un `-javaagent`), sur le *monkey-patching* (Python, Node.js) ou sur des intergiciels (*middlewares*). Elle offre une couverture immédiate et homogène des points d'entrée et de sortie de chaque service, pour un effort minimal.

L'**instrumentation manuelle** enrichit ce socle de spans métier propres au domaine applicatif, que l'automatique ignore : une étape de calcul significative, une règle de gestion, un découpage fonctionnel interne. Elle ajoute aussi les attributs métier qui donnent leur sens aux traces (identifiant de commande, type d'opération).

En pratique, les deux se combinent : l'instrumentation automatique fournit la couverture structurelle des frontières de service, l'instrumentation manuelle apporte la profondeur sémantique métier. C'est leur conjonction qui rend les traces exploitables au diagnostic fin.

## 5.4. Échantillonnage (head-based, tail-based)

Tracer l'intégralité du trafic d'un système à fort débit est généralement prohibitif en volume et en coût. L'**échantillonnage** ne conserve qu'une fraction représentative des traces, selon deux stratégies opposées par le moment de la décision.

L'**échantillonnage à la tête** (*head-based*) décide de conserver ou non une trace *dès son span racine*, avant tout traitement, et propage cette décision à tous les services via les *flags* de `traceparent`. Il est simple, peu coûteux et cohérent — une trace est retenue en totalité ou pas du tout — mais aveugle : la décision précédant le déroulement de la requête, on ne peut privilégier les traces qui se révéleront intéressantes (erreurs, latences anormales), toutes ayant la même probabilité d'être retenues.

L'**échantillonnage à la queue** (*tail-based*) diffère la décision *après* la complétion de la trace entière, ce qui permet de la fonder sur son contenu observé : conserver systématiquement les traces en erreur ou de latence élevée, n'échantillonner que les traces nominales. Nettement plus pertinent au diagnostic, il est aussi plus coûteux : il impose de mettre en tampon l'ensemble des spans d'une trace jusqu'à sa fin, ce qui requiert un composant dédié (typiquement un processeur du Collector) et pose la difficulté de regrouper au même endroit tous les spans d'une même trace en environnement distribué.

## 5.5. Backends (Tempo, Jaeger)

Un *backend* de traces reçoit les spans, les assemble par `trace_id`, les stocke et offre leur exploration.

**Jaeger**, projet historique de la CNCF, fournit une chaîne complète de collecte, stockage et interface d'analyse, avec visualisation des traces en cascade (*flame graph*) et des dépendances entre services. Il s'appuie sur un stockage externe (Cassandra, Elasticsearch) et supporte nativement OTLP.

**Tempo**, de Grafana, adopte le parti d'un stockage exclusivement sur objet (S3) sans index autre que le `trace_id`, ce qui réduit drastiquement le coût d'exploitation — sur le même principe économique que Loki pour les logs. La recherche de traces par attribut s'appuie sur son langage TraceQL, et l'exploration s'intègre à Grafana au sein de la même interface que métriques et logs.

Le choix relève du même arbitrage que pour les logs : richesse d'indexation et de recherche autonome (Jaeger sur Elasticsearch) contre coût de stockage minimal et intégration à une stack unifiée (Tempo). Dans une architecture Grafana / OpenTelemetry, Tempo s'impose naturellement par sa cohérence avec Loki et Prometheus, prolongée par les mécanismes de corrélation de la section 7.

---

# 6. OpenTelemetry

## 6.1. Architecture (SDK, API, Collector)

OpenTelemetry sépare volontairement trois responsabilités, ce qui fonde son indépendance vis-à-vis des *backends*.

L'**API** définit les interfaces d'instrumentation manipulées par le code applicatif et les bibliothèques : créer un span, incrémenter un compteur, émettre un log. Elle est conçue pour être stable et sans effet par défaut — une application instrumentée contre l'API mais dépourvue de SDK actif n'émet aucune télémétrie et n'en subit aucun surcoût. Cette propriété est cruciale pour les auteurs de bibliothèques, qui peuvent instrumenter leur code sans imposer de dépendance de télémétrie à leurs utilisateurs.

Le **SDK** est l'implémentation concrète de l'API : il matérialise la production effective des signaux, applique l'échantillonnage, le traitement par lots (*batching*) et l'export. C'est le SDK que l'on configure et active dans l'application.

Le **Collector** est un service autonome, distinct de l'application, qui reçoit, transforme et réachemine la télémétrie. Il découple les applications des *backends* : celles-ci exportent en OTLP vers le Collector, lequel concentre la logique d'acheminement et de transformation. On peut ainsi changer de *backend*, ajouter un traitement ou dédoubler un flux sans toucher ni redéployer les applications.

Le protocole **OTLP** (*OpenTelemetry Protocol*) est le format d'échange commun aux trois signaux, transporté sur gRPC ou HTTP. Il est le langage véhiculaire de toute la chaîne, de l'application au Collector et du Collector aux *backends*.

## 6.2. Pipelines : receivers, processors, exporters

Le Collector s'organise en *pipelines*, un par type de signal (traces, métriques, logs), chacun composé de trois étages configurables.

Les **receivers** sont les points d'entrée : ils reçoivent la télémétrie selon un protocole donné. Le receiver OTLP est le plus courant, mais le Collector sait aussi *scraper* des cibles Prometheus, lire des logs ou ingérer d'autres formats — ce qui en fait un point de médiation entre paradigmes de collecte (section 2.4) et un outil de migration depuis des chaînes préexistantes.

Les **processors** transforment les données en transit : traitement par lots (essentiel à l'efficacité du transport), enrichissement d'attributs, filtrage, suppression de champs sensibles, limitation mémoire, ou échantillonnage à la queue. Ils s'exécutent dans l'ordre déclaré et constituent le cœur de la valeur ajoutée du Collector.

Les **exporters** sont les points de sortie vers les *backends* : OTLP vers Tempo, *remote write* vers Prometheus ou un stockage compatible, export vers Loki. Un même pipeline peut comporter plusieurs exporters, dédoublant un flux vers plusieurs destinations.

La composition se déclare en YAML — receivers, processors et exporters définis puis assemblés en *pipelines* nommés :

```yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
exporters:
  otlp/tempo:
    endpoint: tempo:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
```

## 6.3. Déploiement du Collector (agent, gateway)

Deux patrons de déploiement, souvent combinés, structurent l'usage du Collector.

En mode **agent**, une instance de Collector s'exécute au plus près de chaque source — en processus d'accompagnement sur l'hôte ou aux côtés de l'application. Elle décharge l'application des tâches d'export, met en tampon localement, et réalise l'enrichissement par le contexte local (identité de l'hôte, du nœud). La latence d'export vue par l'application est minimale.

En mode **gateway**, un ou plusieurs Collectors centralisés, mutualisés et mis à l'échelle indépendamment, reçoivent le flux des agents. Ils concentrent les traitements lourds ou nécessitant une vue d'ensemble — l'échantillonnage à la queue requiert précisément de regrouper tous les spans d'une trace, ce que seul un point de convergence permet — ainsi que la gestion centralisée des *quotas*, du multi-tenant et de l'acheminement.

L'architecture recommandée combine les deux : des agents en périphérie pour la proximité et la résilience locale, relayant vers une *gateway* pour la mutualisation et les traitements globaux. Ce schéma prolonge à la télémétrie l'architecture à deux étages déjà rencontrée pour les logs (section 4.3).

## 6.4. Migration et interopérabilité

La conception d'OpenTelemetry facilite une adoption progressive, sans rupture ni réinstrumentation massive.

Côté réception, le Collector accepte les formats préexistants : il *scrape* les cibles Prometheus, reçoit les traces au format Jaeger ou Zipkin, ingère divers formats de logs. Une chaîne d'observabilité en place peut donc placer un Collector en coupure et migrer les *backends* en aval sans toucher aux sources en amont.

Côté émission, les exporters ciblent aussi bien les *backends* natifs OTLP que les systèmes existants, autorisant une bascule graduelle destination par destination. La **compatibilité Prometheus** est à cet égard déterminante : le Collector expose et consomme le format Prometheus et le *remote write*, ce qui l'insère sans friction dans un écosystème métriques déjà bâti autour de Prometheus.

La stratégie de migration type consiste ainsi à introduire d'abord le Collector comme simple relais transparent, à normaliser progressivement l'instrumentation vers l'API OpenTelemetry, puis à unifier le transport sur OTLP — chaque étape apportant une valeur propre sans dépendre de l'achèvement des suivantes.

---

# 7. Corrélation et exploitation

## 7.1. Corrélation métriques ↔ logs ↔ traces

La valeur d'une plateforme d'observabilité tient moins à la richesse de chaque signal pris isolément qu'à la capacité de naviguer de l'un à l'autre sans rupture. C'est cette navigation qui transforme trois silos en un système observable, et qui matérialise le dépassement du modèle des « trois piliers » évoqué en section 2.1.

Le **fil conducteur** de la corrélation est un jeu d'identifiants partagés. Le `trace_id` propagé de bout en bout (section 5.1) doit être injecté dans les logs (section 4.2) : un log portant son `trace_id` se rattache immédiatement à la trace dont il est issu. Les labels communs — `service`, `instance`, `namespace` — doivent quant à eux être homogènes entre métriques, logs et traces, faute de quoi la corrélation par dimension devient impraticable. L'homogénéité du nommage, traitée en section 9.1, est ici la condition technique de l'exploitation.

Les **exemplars** constituent le pont canonique de la métrique vers la trace. Un exemplar est une référence à un `trace_id` attachée à une observation d'histogram : le point de latence anormalement élevé sur un graphe porte l'identifiant d'une trace concrète qui a produit cette valeur. L'opérateur passe alors, d'un clic, de la constatation agrégée (« le p99 se dégrade ») à un exemple singulier et complet de ce que recouvre cette dégradation.

Le **parcours de diagnostic** type enchaîne les trois signaux : une alerte sur une métrique signale l'anomalie et son ampleur ; un exemplar mène à une trace représentative qui localise l'étape fautive dans le parcours distribué ; les logs corrélés à cette trace, via son `trace_id`, en livrent le détail circonstancié. On descend ainsi de l'agrégat au cas particulier, du *quoi* au *pourquoi*, sans reconstruction manuelle de contexte — la réduction du MTTD et du temps de diagnostic visée en section 1.2.

## 7.2. Dashboards (Grafana)

**Grafana** est l'interface de visualisation unifiée de l'écosystème : une même console interroge Prometheus, Loki et Tempo via des sources de données déclarées, et présente les trois signaux dans un cadre commun.

Un **tableau de bord** se compose de panneaux, chacun adossé à une requête (PromQL, LogQL, TraceQL). Les **variables de tableau de bord** paramètrent ces requêtes — sélection d'un service, d'une instance, d'un environnement — et rendent un même tableau réutilisable sur tout le parc plutôt que dupliqué par cible.

La corrélation de la section 7.1 se matérialise dans Grafana par les **liens de données** (*data links*) : un exemplar sur un panneau de métriques ouvre la trace correspondante dans Tempo ; un champ `trace_id` d'un panneau de logs mène à la même trace. La navigation inter-signaux devient une propriété de l'interface, non un raccordement manuel entre outils disjoints.

Un principe de conception s'impose : un tableau de bord répond à une question, selon un point de vue explicite. On distingue les vues de haut niveau, orientées SLO et destinées au pilotage, des vues de diagnostic, denses et destinées à l'investigation. La méthodologie de la section 3.2 y guide directement la structure — un tableau RED par service, un tableau USE par classe de ressource.

## 7.3. Alerting (Alertmanager, règles, routage)

L'alerte transforme l'observation passive en notification active. Dans l'écosystème Prometheus, deux composants se répartissent la fonction.

Les **règles d'alerte** sont des expressions PromQL évaluées périodiquement par Prometheus. Une règle se déclenche lorsque son expression retourne un résultat sur une durée soutenue (`for`), ce qui filtre les franchissements transitoires. Elle porte des labels — servant au routage et à la classification de sévérité — et des annotations, qui composent le message lisible :

```yaml
groups:
  - name: api
    rules:
      - alert: HautTauxErreur5xx
        expr: sum(rate(http_requests_total{status=~"5.."}[5m]))
              / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Taux d'erreur 5xx supérieur à 5% sur l'API"
```

Les **recording rules**, complémentaires, pré-calculent et matérialisent des expressions coûteuses ou fréquemment réutilisées en nouvelles séries, allégeant d'autant le coût des tableaux de bord et des règles d'alerte.

**Alertmanager** reçoit les alertes émises par Prometheus et gère leur cycle de vie *après* déclenchement. Ses fonctions essentielles sont le **regroupement** (*grouping*) d'alertes connexes en une notification unique, la **mise en sourdine** (*inhibition*) d'alertes subordonnées à une cause commune — taire les alertes de service lorsqu'un nœud entier est tombé —, la **suppression temporaire** (*silences*) pendant une maintenance planifiée, et le **routage** vers les canaux appropriés selon les labels (astreinte, messagerie d'équipe, courriel).

Une discipline gouverne l'ensemble : toute alerte doit être **actionnable**. Une alerte qui ne requiert aucune action, ou dont l'action est ambiguë, dégrade par accoutumance la réactivité aux alertes légitimes (*alert fatigue*). L'alerte sur symptôme perçu par l'utilisateur — la dégradation de SLO — est généralement préférable à l'alerte sur cause potentielle, dont la corrélation au diagnostic relève des tableaux de bord.

## 7.4. SLO, error budgets, burn rate

La démarche SLO fournit le cadre qui subordonne l'alerte à l'impact réel sur le service rendu, plutôt qu'à des seuils de ressources arbitraires.

Un **SLI** (*Service Level Indicator*) est une mesure quantifiée d'un aspect de la qualité de service, exprimée comme le rapport d'événements conformes sur événements totaux : proportion de requêtes servies sous un seuil de latence, proportion de requêtes sans erreur. Le **SLO** (*Service Level Objective*) est la cible que ce SLI doit atteindre sur une fenêtre donnée — par exemple 99,9 % de requêtes conformes sur 30 jours glissants.

L'**error budget** est le complément du SLO : un objectif de 99,9 % autorise 0,1 % de requêtes non conformes sur la fenêtre. Ce budget d'erreur est une quantité pilotable — il mesure la marge de défaillance restante et arbitre explicitement l'équilibre entre vélocité de livraison et stabilité (section 1.2). Budget épuisé, la priorité bascule vers la fiabilisation ; budget préservé, la prise de risque en livraison reste soutenable.

Le **burn rate** est la vitesse de consommation de ce budget. Un *burn rate* de 1 consomme exactement le budget sur toute la fenêtre ; une valeur de 10 l'épuise dix fois plus vite. Il fonde une stratégie d'alerte SLO à plusieurs fenêtres (*multi-window, multi-burn-rate*) : une consommation très rapide sur une fenêtre courte déclenche une alerte urgente d'astreinte, tandis qu'une dérive lente sur une fenêtre longue produit une alerte de moindre priorité. Cette approche concilie deux exigences habituellement antagonistes — réactivité aux incidents aigus et détection des dégradations insidieuses — tout en maintenant le lien direct entre l'alerte et l'impact effectivement subi par l'utilisateur.

---

# 8. Stack complète (exemple)

![archi_observabilite.png](media://6f773fc4-c3af-4ccd-a422-978109e35335)


L'assemblage des composants étudiés aux sections précédentes forme une chaîne cohérente, entièrement *open source* et auto-hébergeable, articulée autour d'OpenTelemetry pour l'instrumentation et de Grafana pour l'exploitation.

Le flux se décompose en quatre étages. À la **source**, les applications sont instrumentées via les SDK OpenTelemetry et exportent en OTLP ; l'infrastructure et les services tiers sont couverts par des exporters Prometheus (*node_exporter*, *mysqld_exporter*). À la **collecte**, un Collector OpenTelemetry en mode agent s'exécute au plus près des sources, met en tampon et enrichit du contexte local. À l'**agrégation**, une *gateway* de Collectors mutualise les traitements globaux — traitement par lots, échantillonnage à la queue, acheminement — et ventile chaque signal vers son stockage. Au **stockage et à l'exploitation**, enfin, chaque signal rejoint son *backend* spécialisé, tous interrogés depuis une console Grafana unique.

| **Étage** | **Composant** | **Rôle** |
| --- | --- | --- |
| Instrumentation | SDK OpenTelemetry | Production des signaux applicatifs (OTLP) |
| Métriques infra | node_exporter, mysqld_exporter | Exposition Prometheus des ressources et services tiers |
| Collecte | Collector OTel (agent) | Tampon, enrichissement local, export |
| Agrégation | Collector OTel (gateway) | Batch, tail-sampling, routage, multi-tenant |
| Stockage métriques | Prometheus + stockage long terme | TSDB, requêtage PromQL |
| Stockage logs | Loki | Indexation par labels, requêtage LogQL |
| Stockage traces | Tempo | Stockage objet, requêtage TraceQL |
| Alerte | Alertmanager | Regroupement, inhibition, routage |
| Visualisation | Grafana | Tableaux de bord et corrélation inter-signaux |

Cette combinaison n'est pas la seule possible, mais sa cohérence tient à trois choix structurants : OTLP comme protocole véhiculaire unique, le modèle de labels Prometheus partagé par les trois *backends* (condition de la corrélation, section 7.1), et le stockage objet comme socle économique commun à Loki et Tempo.

## 8.1. Dimensionnement et haute disponibilité

Le dimensionnement d'une plateforme d'observabilité procède de trois grandeurs primaires : le nombre de séries temporelles actives pour les métriques, le débit d'ingestion en volume par unité de temps pour les logs, et le débit de spans pour les traces. La cardinalité (section 2.3) est le facteur dominant du dimensionnement des métriques : c'est le nombre de séries actives, non la fréquence d'échantillonnage, qui détermine l'empreinte mémoire de la TSDB.

La **haute disponibilité** obéit à des principes distincts selon l'étage. Le chemin d'ingestion — Collectors — doit être redondé et sans état, la mise en tampon locale des agents absorbant les indisponibilités transitoires de l'aval sans perte. Le stockage exige une stratégie propre : la TSDB locale de Prometheus étant mono-nœud (section 3.4), sa haute disponibilité passe soit par des instances redondantes *scrapant* les mêmes cibles avec dédoublonnage à la lecture (Thanos), soit par une architecture nativement distribuée et répliquée (Mimir, VictoriaMetrics cluster). Pour les logs et les traces, la durabilité repose sur le stockage objet sous-jacent, dont la réplication est déléguée à l'infrastructure de stockage.

Un principe cardinal encadre l'ensemble : **la plateforme d'observabilité doit être plus disponible que les systèmes qu'elle observe**, et surtout indépendante d'eux dans ses défaillances. Une plateforme qui partage ses dépendances avec le système observé s'aveugle précisément au moment où elle est le plus nécessaire — lors d'une panne commune. L'isolation des chemins critiques (réseau, stockage, alimentation) entre observé et observant n'est donc pas un raffinement mais une exigence de conception.

## 8.2. Coûts et rétention

Le coût d'une plateforme d'observabilité se ventile en collecte, transport, stockage et requêtage, et il croît avec deux grandeurs : le volume de données et leur cardinalité. Laissé sans gouvernance, il tend à croître plus vite que le système observé lui-même, au point que le coût de l'observabilité puisse rivaliser avec celui de la production.

Trois leviers principaux le maîtrisent. La **rétention différenciée par âge** (section 3.4) conserve la donnée récente à pleine résolution pour le diagnostic et sous-échantillonne la donnée ancienne pour l'analyse de tendance, réduisant le volume sans sacrifier l'historique. La **maîtrise de la cardinalité** — écarter les dimensions non bornées des métriques (section 2.3) — agit à la racine, en amont du stockage. L'**échantillonnage des traces** (section 5.4), à la queue de préférence, conserve la valeur diagnostique en réduisant drastiquement le volume conservé.

Le choix des *backends* participe directement de cet arbitrage : le parti pris de Loki et Tempo — n'indexer que les labels, stocker le contenu compressé sur objet — répond précisément à l'objectif de soutenabilité économique posé en section 1.2, au prix d'une recherche plein texte plus lente. La conception d'une plateforme d'observabilité est ainsi, de bout en bout, un exercice d'équilibre entre richesse de la donnée et coût de sa détention.

---

# 9. Bonnes pratiques

## 9.1. Conventions de nommage et labels

L'homogénéité du nommage n'est pas cosmétique : elle est la condition technique de la corrélation inter-signaux (section 7.1). Des labels divergents entre métriques, logs et traces — `svc` ici, `service` là, `service_name` ailleurs — rendent impraticable tout regroupement transverse et ruinent la navigation d'un signal à l'autre.

Les **conventions sémantiques** d'OpenTelemetry fournissent un vocabulaire normalisé d'attributs (`service.name`, `http.request.method`, `db.system`, `net.peer.name`) qu'il convient d'adopter plutôt que de réinventer. Elles garantissent que l'instrumentation, les *backends* et les tableaux de bord partagent la même terminologie, y compris entre équipes et entre services hétérogènes.

Pour les métriques Prometheus, quelques règles structurent le nommage : un préfixe de domaine (`http_`, `db_`), un suffixe d'unité au singulier explicite (`_seconds`, `_bytes`, `_total` pour les counters), et l'unité de base du Système international — secondes et octets, jamais millisecondes ou mébioctets. Cette discipline rend les métriques auto-descriptives et interopérables avec les fonctions du langage, qui présument ces conventions.

## 9.2. Maîtrise de la cardinalité

La cardinalité (section 2.3) est le principal facteur de coût et le principal risque d'indisponibilité d'une plateforme de métriques. Sa maîtrise procède d'une règle de partition : **les dimensions à cardinalité bornée relèvent des labels de métriques ; les dimensions à cardinalité non bornée relèvent des logs et des traces.** Identifiant utilisateur, identifiant de requête, adresse IP, URL complète avec paramètres n'ont jamais leur place en label de métrique.

En pratique, plusieurs mesures encadrent le risque. On borne les dimensions ouvertes en amont — normaliser une route paramétrée `/user/4821` en gabarit `/user/{id}` avant d'en faire un label. On surveille la cardinalité elle-même comme une métrique de la plateforme, et l'on détecte les séries à croissance anormale. On peut enfin imposer des limites strictes à l'ingestion (*limits* par tenant, `sample_limit` au *scrape*) pour qu'une instrumentation défaillante ne puisse saturer le stockage — un garde-fou d'exploitation, non un substitut à la conception.

## 9.3. Sécurité et multi-tenant

La télémétrie transporte des informations sensibles et constitue elle-même une surface d'attaque et un vecteur de fuite. Trois exigences la gouvernent.

La **protection des données** impose d'exclure de la télémétrie les secrets et données personnelles : jetons, mots de passe, données à caractère personnel ne doivent figurer ni dans les attributs de spans, ni dans les logs. Le Collector offre le point d'application idéal de cette expurgation, via des processors de suppression ou de masquage d'attributs appliqués avant export — défense centralisée qui ne dépend pas de la discipline de chaque source.

Le **cloisonnement des flux** protège la chaîne elle-même : chiffrement en transit (TLS sur OTLP), authentification des sources auprès des collecteurs, et isolation réseau de la plateforme d'observabilité vis-à-vis des systèmes observés — laquelle rejoint l'exigence d'indépendance des défaillances de la section 8.2.

Le **multi-tenant** partitionne la donnée par locataire (équipe, application, environnement) au sein d'une plateforme mutualisée. Loki, Tempo et Mimir le supportent nativement via un identifiant de tenant propagé de la *gateway* au stockage, garantissant l'étanchéité des données à la lecture comme à l'écriture, et permettant d'appliquer *quotas* et rétention différenciés par locataire.

## 9.4. Anti-patterns

Certains écueils récurrents méritent d'être nommés, car ils annulent la valeur de la démarche.

L'**explosion de cardinalité** est le plus grave : placer une dimension non bornée en label de métrique sature la plateforme et peut la rendre indisponible — au moment précis où elle est requise (section 9.2).

La **fatigue d'alerte** procède d'alertes non actionnables ou trop nombreuses : à force de bruit, les alertes légitimes se noient et cessent d'être traitées (section 7.3). Alerter sur les causes plutôt que sur les symptômes perçus par l'utilisateur en est une cause fréquente.

Les **logs non structurés** en volume reportent sur la chaîne d'ingestion un coût de *parsing* fragile et transforment une donnée potentiellement exploitable en texte difficilement interrogeable (section 4.1).

Le **surdimensionnement de la donnée** — tout tracer sans échantillonnage, tout conserver à pleine résolution sans rétention différenciée — fait croître le coût plus vite que le système observé, jusqu'à rendre l'observabilité économiquement insoutenable (section 8.3).

L'**instrumentation en silos**, enfin, néglige la propagation du contexte et l'homogénéité des labels : les trois signaux existent mais ne se corrèlent pas, et l'on retombe sur les trois piliers isolés que l'approche unifiée visait précisément à dépasser (sections 2.1 et 7.1).

---

Au-delà de tes trois axes, j'en ajoute trois qui structurent le sujet en 2026 : la **corrélation et l'analyse de cause racine (RCA)**, les **interfaces en langage naturel**, et — angle miroir souvent oublié — **l'observabilité de l'IA elle-même**. Je propose d'en faire une section à part entière, à insérer avant les annexes (qui deviendraient la section 12).

---

# 10. L'intelligence artificielle dans l'observabilité

Le rapprochement de l'IA et de l'observabilité n'est pas nouveau — il porte le nom d'**AIOps** depuis 2017 — mais sa nature a changé. La première génération se limitait pour l'essentiel à la réduction du bruit d'alerte et à une détection d'anomalies statistique, dont le résultat opérationnel restait modeste. La bascule récente tient à l'irruption des grands modèles de langage et des architectures agentiques : on passe d'un outillage qui réduisait le bruit à un système qui lit la tempête d'alertes, la corrèle aux déploiements récents et à la topologie, rédige une hypothèse de cause racine et propose une étape de remédiation. Le marché reflète cette maturation : réductions de MTTR de 30 à 70 % dans les déploiements les plus automatisés, et diminution du bruit d'alerte supérieure à 95 % chez les plateformes de tête. La section distingue ce qui est aujourd'hui éprouvé de ce qui relève encore de la perspective.

## 10.1. Détection des anomalies

La détection d'anomalies substitue à des seuils statiques — dont la calibration est fastidieuse et vite obsolète — un modèle du comportement normal appris sur l'historique, qui signale les écarts significatifs. Techniquement, elle combine plusieurs familles : décomposition saisonnière et prévision (ARIMA, Prophet, Holt-Winters) pour les séries à forte périodicité ; méthodes non supervisées (isolation forest, clustering, autoencodeurs) pour les écarts multivariés ; détection de changement de régime pour les ruptures brutales.

Son intérêt central est de capter des anomalies *contextuelles* qu'un seuil fixe manque structurellement : une charge de 80 % de CPU est normale à l'heure de pointe et anormale la nuit ; un seuil unique ne peut distinguer les deux, un modèle saisonnier le fait nativement. Sa difficulté symétrique est le taux de faux positifs : une détection trop sensible régénère précisément la fatigue d'alerte (section 9.4) qu'elle prétendait résoudre. La détection d'anomalies n'a donc de valeur qu'adossée à une couche de corrélation et de priorisation (section 11.3) qui transforme un signal statistique en alerte actionnable.

## 10.2. Apprentissage des environnements et des usages

Un modèle d'anomalie n'est pertinent que s'il connaît le système qu'il observe. Cette phase d'apprentissage recouvre trois dimensions.

L'**établissement de références** (*baselining*) apprend la forme normale de chaque signal — tendance, saisonnalité journalière et hebdomadaire, variance — pour situer toute observation par rapport à sa distribution attendue plutôt qu'à une constante.

La **découverte de topologie** reconstruit automatiquement le graphe de dépendances entre services à partir des traces et des flux réseau. C'est elle qui fonde le raisonnement causal : évaluer les dépendances de topologie pour remonter à une cause racine unique plutôt qu'à une liste de symptômes corrélés. Sans modèle de topologie, l'IA ne distingue pas la cause de ses conséquences en cascade.

L'**apprentissage des usages** caractérise les profils de trafic, les cohortes d'utilisateurs et les rythmes d'exploitation — déploiements, traitements *batch*, pics prévisibles — afin que le système ne confonde pas un événement planifié avec une défaillance. La qualité de cet apprentissage dépend directement de l'homogénéité des labels et de la richesse du contexte (sections 7.1 et 9.1) : une IA n'infère bien que sur une télémétrie déjà bien structurée.

## 10.3. Corrélation et analyse de cause racine (RCA)

La corrélation est aujourd'hui la capacité la plus mûre et la plus éprouvée en production. Face à un incident qui déclenche simultanément des dizaines de symptômes sur autant de surfaces, l'IA regroupe les signaux liés en un incident unique, réduit le bruit et hiérarchise. L'analyse de cause racine va plus loin : corrélation automatique des signaux entre logs, métriques et traces, analyse causale remontant du symptôme à son origine, conscience de la topologie et du rayon d'impact, et production d'étapes actionnables plutôt que d'une liste de suspects.

Deux approches coexistent. L'**IA causale** (*causal AI*), déterministe, exploite le graphe de dépendances pour désigner une cause racine unique et explicable — approche privilégiée en environnement critique, où la traçabilité de la décision importe autant que la décision. Les **LLM**, eux, excellent à la synthèse contextuelle : agréger l'historique de déploiement, les tickets et la télémétrie en un récit d'incident lisible. Leur combinaison — le graphe causal pour la rigueur, le LLM pour la restitution — définit l'état de l'art.

## 10.4. Décision et automatisation de l'intervention

C'est le point le plus sensible, car il engage une action sur le système de production. On y distingue une gradation d'autonomie croissante : suggérer (proposer un *runbook*), assister (préparer l'action, l'humain valide), puis agir (exécuter sans intervention). La pratique responsable en 2026 place le curseur sur l'assistance : l'agent génère des causes racines suspectées, un résumé d'impact étayé et un plan de remédiation qu'un humain vérifie — le schéma *human-in-the-loop*.

La remédiation pleinement autonome reste circonscrite. Elle est admise pour des actions à faible risque et réversibles — redémarrage, mise à l'échelle, bascule sur une instance saine, retour arrière d'un déploiement — encadrées par des garde-fous stricts et un journal d'audit. Pour le reste, la corrélation d'alertes et la restitution de connaissance sont les capacités les mieux validées en production, tandis que la remédiation entièrement autonome demeure largement prospective. La prudence tient à la nature de l'erreur : une action erronée déclenchée automatiquement peut aggraver l'incident qu'elle prétendait résoudre.

## 10.5. Interfaces en langage naturel et requêtage assisté

Les LLM abaissent la barrière d'accès à la télémétrie en traduisant une question en langage naturel vers PromQL, LogQL ou TraceQL, et en restituant une réponse synthétique. L'opérateur interroge (« pourquoi le paiement est-il lent ? ») sans maîtriser la syntaxe de chaque langage, ce qui ouvre l'exploration au-delà du cercle des experts. La limite est connue — sensibilité à la formulation, risque de réponse plausible mais fausse — ce qui réserve pour l'instant cet usage à l'investigation exploratoire plutôt qu'à l'alerte automatisée.

## 10.6. L'observabilité de l'IA elle-même

L'angle inverse devient incontournable à mesure que les applications intègrent des LLM et des agents autonomes : il faut désormais *observer l'IA en production*. Les signaux classiques n'y suffisent pas ; s'y ajoutent la trace des *prompts* et des réponses, le coût par jetons, la latence des appels de modèle, et surtout des indicateurs propres — taux d'hallucination, dérive de qualité, respect des politiques. Sans observabilité, un agent autonome peut dériver, halluciner ou surconsommer sans détection, créant une exposition métier et réglementaire ; une posture OpenTelemetry-first en est le socle. C'est la catégorie que reflètent des outils comme Langfuse et OpenLLMetry (section 10.3), et elle prolonge naturellement le modèle des spans et des traces au monde des chaînes d'inférence.

## 10.7. Demain : perspectives et limites

La trajectoire annoncée est celle de l'**observabilité agentique** : des agents qui détectent, investiguent, corrèlent et corrigent en boucle fermée, l'humain passant de l'exécution à la supervision. Plusieurs conditions en gouverneront l'adoption réelle.

L'**explicabilité** est la première : une décision d'intervention automatique n'est acceptable que si elle est traçable et justifiable — d'où l'avantage durable des approches causales déterministes sur les seules inférences statistiques. La **confiance** est la deuxième : elle se construit par paliers d'autonomie, en cantonnant d'abord l'automatisation aux actions réversibles à faible enjeu. Le **coût et la qualité de la donnée** forment la troisième : une IA d'observabilité n'est bonne que sur une télémétrie bien structurée, bien étiquetée et économiquement soutenable — les fondamentaux des sections précédentes ne sont pas rendus caducs par l'IA, ils en deviennent le prérequis. La quatrième, transversale, est l'exigence de garder l'humain responsable en dernier ressort : l'IA déplace le travail de diagnostic, elle ne transfère pas la responsabilité de l'exploitation.

En somme, l'IA ne remplace pas l'architecture d'observabilité décrite dans ce document : elle en exploite la matière. Une télémétrie pauvre ou mal gouvernée produit une IA d'observabilité peu fiable ; c'est la qualité des piliers, des standards et de la corrélation qui conditionne la valeur de la couche intelligente qui s'y ajoute.

---

Bien vu de vouloir un exemple concret. Un point d'actualité qui oriente un choix : **Grafana OnCall (OSS) a été archivé le 24 mars 2026** — ce n'est donc plus une brique open source retenable pour du neuf. Je m'en sers pour illustrer le « pas que » : collecte et stockage en open source, mais gestion d'astreinte (IRM) déléguée à un service managé, là où faire tourner soi-même l'infra de rotation n'a pas de sens pour une petite équipe.

Je bâtis l'exemple sur un profil de SI cohérent avec ce type de PME (Proxmox/Debian, K3s, MariaDB, apps Java), puis deux schémas.

Je génère d'abord les schémas.Schéma 1 correct. Je génère le second (chaîne de télémétrie et arbitrage auto-hébergé / managé).Voici la section. Je la conçois comme la déclinaison concrète de la section 8 (architecture de référence) — à placer juste après elle.

---

# 11. Étude de cas — Observabilité du SI de KAPTUS (PME)

> 📝 ***La société KAPTUS est ma structure, mais les données ci-dessous sont fictives et sont prises à titre d’exemple.***

## 11.1. Contexte et contraintes

KAPTUS est une PME d'environ 80 personnes dont le système d'information est majoritairement auto-hébergé. Le parc se compose d'un cluster **Proxmox VE** hébergeant environ 25 VMs **Debian 13**, d'un petit cluster **K3s** (3 nœuds) portant les microservices métier, de bases de données **MariaDB** (grappe Galera à 3 nœuds) et **PostgreSQL**, d'applications **Java/JEE** (Tomcat, Spring Boot), d'un **Nextcloud** et d'un reverse-proxy **Caddy**, le tout derrière un pare-feu **OPNsense**. Une empreinte cloud réduite (quelques VMs et un stockage objet S3) sert de site de repli.

> 📝 Deux contraintes structurent tous les choix. D'une part, l'**équipe d'exploitation est réduite** (2 à 3 personnes) : la simplicité opérationnelle prime sur l'exhaustivité fonctionnelle. D'autre part, la **maîtrise des coûts** est un objectif de premier rang. Ces deux contraintes justifient une orientation open source dominante, mais assumée non exclusive là où l'auto-hébergement ferait peser une charge disproportionnée sur une petite équipe.

## 11.2. Principes directeurs

Quatre principes guident la conception. **Open source d'abord**, pour la maîtrise et le coût. **Standards ouverts systématiques** : instrumentation OpenTelemetry et OTLP comme protocole véhiculaire, afin de découpler l'instrumentation du choix des *backends* (section 6) et de préserver toute bascule ultérieure. **Isolation de la plateforme** vis-à-vis du domaine de production, conformément à l'exigence d'indépendance des défaillances (section 8.2). **Recours pragmatique au managé** enfin, réservé aux fonctions dont l'exploitation autonome n'a pas de sens à cette échelle — au premier chef la gestion d'astreinte (IRM), d'autant que Grafana OnCall (OSS) a été archivé le 24 mars 2026 et n'est plus une brique retenable pour du neuf.

## 11.3. Inventaire instrumenté et points de collecte

Le **schéma 1** ci-dessous situe chaque source et son point de collecte. Un agent **Grafana Alloy** — distribution du Collector OpenTelemetry — s'exécute par VM et en DaemonSet sur K3s ; il relaie vers une *gateway* Alloy unique portée par la VM d'observabilité.

![kaptus_topo_v.png](media://3269d32e-da17-4bd5-b60a-27807e427138)

| **Domaine** | **Source** |  |
| --- | --- | --- |
| Applications Java | Tomcat, Spring Boot |  |
| Microservices K3s | Services métier |  |
| Système | Toutes les VMs |  |
| Conteneurs | Nœuds K3s |  |
| Base de données | MariaDB Galera |  |
| Base de données | PostgreSQL |  |
| Ingress / proxy | Traefik, Caddy |  |
| Réseau | OPNsense |  |
| Disponibilité | Sondes internes |  |

## 11.4. Pile retenue

| **Rôle** | **Composant** | **Open source** | **Justification** |
| --- | --- | --- | --- |
| Collecte / agent | Grafana Alloy | Oui | Distribution OTel Collector unifiée ; remplace Promtail (déprécié). |
| Agrégation / gateway | Alloy (gateway) | Oui | Tail-sampling et routage centralisés (section 6.3). |
| Métriques | VictoriaMetrics (mono-nœud) | Oui | Efficacité mémoire et compression ; plus léger que Thanos/Mimir à l'échelle PME. |
| Logs | Loki | Oui | Indexation par labels, coût de stockage minimal (section 4.4). |
| Traces | Tempo | Oui | Stockage objet, cohérent avec la stack Grafana (section 5.5). |
| Stockage objet | Garage (local) | Oui | Socle S3 commun à Loki et Tempo, auto-hébergé. |
| Visualisation | Grafana | Oui | Corrélation inter-signaux (section 7.2). |
| Alerte | Alertmanager / Grafana Alerting | Oui | Règles, regroupement, routage (section 7.3). |
| Astreinte / IRM | Grafana Cloud IRM · Opsgenie · PagerDuty | **Non** | Rotations, escalade, push mobile — non pertinent à auto-héberger pour 3 personnes. |
| Supervision externe | Better Stack · Uptime Kuma (si auto-hébergé) | Mixte | Point de vue externe + page de statut publique. |
| Repli / DR | Stockage objet cloud S3 | **Non** | Réplication hors-site des blocs MinIO. |
| Déploiement / config | Ansible | Oui | Cohérent avec l'exploitation existante ; tout en configuration versionnée. |

> 📝 ***MinIO*** a longtemps été la référence du stockage objet S3 auto-hébergé, mais son édition communautaire a été placée en *maintenance mode* fin 2025 — dépôt archivé, arrêt de la publication des binaires et des images Docker, interface d'administration réduite à un simple navigateur d'objets — et n'est donc plus un socle retenable pour un nouveau déploiement, malgré une licence toujours AGPLv3. Nous lui préférons ***[Garage](https://garagehq.deuxfleurs.fr/)***, développé par l'association Deuxfleurs sous licence AGPLv3, pleinement open source et activement maintenu. Léger, distribué en binaire unique et pensé pour l'auto-hébergement à petite et moyenne échelle, il correspond exactement au besoin de la VM d'observabilité de KAPTUS. Son API S3 étant compatible, la substitution est transparente pour Loki et Tempo, qui n'exigent aucune modification : seule la cible de stockage change.

## 11.5. Arbitrage de stockage : auto-hébergé ou managé

![kaptus_pipe_v.png](media://429b560a-fb7d-4284-9890-5d6108051ebe)

Le **schéma 2** oppose les deux options que permet le découplage par OTLP, la source restant identique dans les deux cas. En **option A**, entièrement open source, la VM d'observabilité porte VictoriaMetrics, Loki, Tempo et MinIO : coût logiciel nul, maîtrise totale, mais charge d'exploitation (mises à jour, HA du stockage, gestion de la rétention) portée par l'équipe. En **option B**, la même *gateway* Alloy exporte en OTLP vers **Grafana Cloud** (Mimir/Loki/Tempo managés) : la disponibilité, la rétention et les mises à jour sont déléguées, au prix d'un coût à l'usage et d'un envoi de télémétrie hors des murs.

Pour KAPTUS, la recommandation est de **démarrer en option A** — le volume reste modeste et la compétence Linux/DBA est présente — tout en gardant l'option B comme trajectoire de repli si la charge d'exploitation devenait excessive : le basculement se réduit à changer la cible d'export de la *gateway*, sans retoucher l'instrumentation.

## 11.6. Dimensionnement indicatif

Les ordres de grandeur ci-dessous sont des estimations de départ, à affiner par mesure réelle de la cardinalité et du débit (sections 2.3 et 8.2).

| **Grandeur** | **Hypothèse** | **Conséquence** |
| --- | --- | --- |
| Séries de métriques actives | ~150 à 300 k | Un nœud VictoriaMetrics suffit largement. |
| Volume de logs | ~20 à 50 Go/jour | Rétention 30 j pleine résolution sur MinIO. |
| Traces | Échantillonnage à la queue : 100 % des erreurs, ~10 % du nominal | Volume conservé fortement réduit. |
| VM d'observabilité | 8 vCPU / 32 Go RAM / SSD NVMe + volume MinIO | Départ mono-VM ; passage à 2 VMs pour la HA ultérieurement. |

### 11.6.1. Déploiement et exploitation

L'ensemble est décrit en rôles **Ansible** versionnés : 

- déploiement des agents Alloy,
- déploiement des exporters,
- déploiement de la *gateway*,
- déploiement de la VM d'observabilité,
- configuration des tableaux de bord et des règles d'alerte en *configuration-as-code*.

La VM d'observabilité est isolée sur un hôte Proxmox et un segment réseau distincts du domaine de production, afin de rester disponible lors d'une panne commune. Les alertes, définies en RED par service et USE par ressource (section 3.2), sont routées par Alertmanager vers le service d'astreinte managé, qui porte seul les rotations et l'escalade. Un point de vue externe (supervision synthétique) complète le dispositif pour détecter les pannes que la plateforme interne, si elle tombe avec le SI, ne verrait pas.

### 11.6.2. Approche initiale — rétention uniforme

Le premier dimensionnement retient une hypothèse volontairement naïve : chaque signal est conservé à pleine résolution pendant toute la durée de l'horizon considéré. Les métriques reposent sur environ 200 000 séries actives échantillonnées toutes les 15 secondes ; à raison d'environ 0,7 octet par point après compression de VictoriaMetrics, elles produisent près de 0,8 Go par jour. Les logs, ingérés à hauteur d'environ 35 Go par jour et compressés d'un facteur voisin de dix par Loki, pèsent quelque 3,5 Go par jour stockés. Les traces, après un échantillonnage à la queue conservant la totalité des erreurs et environ 10 % du trafic nominal, ajoutent près de 2 Go par jour. L'ensemble s'établit autour de 6,3 Go nets par jour, dont l'accumulation linéaire conduit à environ 0,57 To à trois mois, 1,13 To à six mois et 2,30 To à douze mois. Cette trajectoire met en évidence deux faits structurants : le volume est dominé non par les métriques mais par les logs et les traces, qui en représentent près de 90 % à douze mois ; et une rétention uniforme sur un tel horizon est économiquement injustifiable, puisqu'elle fait porter l'essentiel du stockage sur des données de faible valeur diagnostique passé quelques semaines. Elle sert ici de référence, non de cible

| **Signal** | **Débit stocké** | **3 mois** | **6 mois** | **12 mois** | **24 mois** |
| --- | --- | --- | --- | --- | --- |
| Métriques (VictoriaMetrics) | ~0,8 Go/j | 72 Go | 144 Go | 292 Go | 584 Go |
| Logs (Loki) | ~3,5 Go/j | 315 Go | 630 Go | 1 280 Go | 2 555 Go |
| Traces (Tempo) | ~2,0 Go/j | 180 Go | 360 Go | 730 Go | 1 460 Go |
| **Total net** | ~6,3 Go/j | **≈ 0,57 To** | **≈ 1,13 To** | **≈ 2,30 To** | **≈ 4,60 To** |

### 11.6.3. Approche optimisée — rétention différenciée et agrégation

La configuration retenue applique à chaque signal la stratégie de rétention et d'agrégation adaptée à sa valeur dans le temps. Pour les métriques, un schéma à deux instances de VictoriaMetrics est mis en œuvre : une instance « brute » à pleine résolution et à rétention courte (15 jours) pour le diagnostic fin, et une instance « agrégée » à rétention longue (12 mois), alimentée par *stream aggregation* — ramenant le pas d'échantillonnage de 15 à 60 secondes et pré-agrégeant les dimensions utiles — complétée d'un *relabeling* supprimant avant écriture les séries jamais requêtées, qui représentent couramment la majeure partie du volume émis par les exporters. Les métriques agrégées ne pèsent alors plus qu'environ 0,15 Go par jour. Les logs sont soumis à une rétention de 90 jours et à un filtrage réalisé au niveau de l'agent Alloy avant stockage, ce qui abaisse le débit stocké à environ 2,1 Go par jour. Les traces sont conservées 30 jours après un échantillonnage à la queue plus sélectif, soit environ 1 Go par jour, la valeur de long terme étant préservée sous forme de métriques RED dérivées par le *metrics-generator* de Tempo plutôt que par la conservation des traces brutes. Des règles d'expiration (*lifecycle*) appliquées sur les *buckets* Garage font respecter ces rétentions automatiquement. Sous ce régime, les logs et les traces atteignent un plateau dès leur horizon de rétention franchi ; seules les métriques agrégées continuent de croître lentement. L'empreinte nette se stabilise ainsi autour de 0,25 To à trois mois, 0,26 To à six mois et 0,29 To à douze mois — un facteur de réduction proche de huit par rapport aux 2,30 To de l'approche uniforme, pour une valeur diagnostique équivalente.

| **Signal** | **Rétention** | **Débit stocké** | **3 mois** | **6 mois** | **12 mois** |
| --- | --- | --- | --- | --- | --- |
| Métriques — brutes | 15 j | ~0,8 Go/j | 12 Go | 12 Go | 12 Go |
| Métriques — agrégées | 12 mois | ~0,15 Go/j | 14 Go | 27 Go | 55 Go |
| Logs (Loki) | 90 j | ~2,1 Go/j | 190 Go | 190 Go | 190 Go |
| Traces (Tempo) | 30 j | ~1,0 Go/j | 30 Go | 30 Go | 30 Go |
| **Total net** | — | — | **≈ 0,25 To** | **≈ 0,26 To** | **≈ 0,29 To** |

### 11.6.4. Conclusion — arbitrage entre les deux approches

L'approche à rétention uniforme a pour seul avantage sa simplicité : une politique unique, aucune règle par signal ni par flux, et une donnée intégralement disponible à pleine résolution sur tout l'horizon, ce qui autorise n'importe quelle investigation rétrospective sans angle mort. Ses inconvénients sont toutefois rédhibitoires à moyen terme : un coût de stockage qui croît linéairement et sans borne, dominé par des logs et des traces dont la valeur diagnostique s'effondre après quelques semaines, et une charge croissante sur l'indexation et le requêtage. Elle ne reste défendable que sur des horizons courts ou lorsqu'une contrainte réglementaire impose la conservation intégrale.

L'approche optimisée inverse ce bilan. Elle réduit l'empreinte d'un facteur proche de huit à douze mois, stabilise le stockage sur un plateau prévisible — donc un provisionnement maîtrisé — et préserve la valeur de long terme là où elle compte réellement, sous forme de métriques agrégées et de signaux RED dérivés des traces. Son prix est une complexité accrue : schéma à deux instances pour les métriques, règles de rétention et de filtrage par signal et par flux, calibrage du *tail-sampling* et de l'agrégation, et surtout des choix irréversibles — une trace non échantillonnée ou un log filtré à la source sont définitivement perdus, ce qui exige de bien identifier au préalable les dimensions et les événements à conserver.

En pratique, le choix n'est pas binaire : la bonne cible est l'approche optimisée, dont l'approche uniforme constitue le point de départ conceptuel. On déploie généralement d'abord une rétention simple pour observer les usages réels — quelles séries, quels logs, quelles traces sont effectivement requêtés — puis on resserre progressivement les politiques une fois ces usages connus. Pour KAPTUS, c'est cette trajectoire qui est retenue : démarrage en rétention généreuse durant les premières semaines d'exploitation, puis bascule vers le régime différencié décrit ci-dessus.

# 12. Annexes

## 12.1. Glossaire

| **Terme** | **Définition** |
| --- | --- |
| **Cardinalité** | Nombre de combinaisons distinctes de valeurs de labels pour une métrique. Croît multiplicativement avec le nombre de dimensions et de leurs valeurs possibles. |
| **Counter** | Métrique cumulative monotone croissante, remise à zéro au seul redémarrage ; exploitée par sa dérivée temporelle (`rate`). |
| **Error budget** | Marge de non-conformité autorisée par un SLO ; complément à 100 % de la cible (0,1 % pour un SLO de 99,9 %). |
| **Exemplar** | Référence à un `trace_id` attachée à une observation d'histogram ; pont de la métrique vers une trace concrète. |
| **Exporter** | (1) Agent traduisant les métriques d'un système tiers au format Prometheus ; (2) étage de sortie d'un pipeline de Collector OTel. |
| **Gauge** | Métrique instantanée montant et descendant librement ; sa valeur courante est directement significative. |
| **Head-based sampling** | Échantillonnage décidé au span racine, avant déroulement de la requête. |
| **Histogram** | Métrique répartissant des observations en tranches (*buckets*) ; permet le calcul de quantiles agrégeables côté serveur. |
| **MTTR / MTTD** | *Mean Time To Recovery / To Detect* ; indicateurs d'efficacité opérationnelle. |
| **OTLP** | *OpenTelemetry Protocol* ; format d'échange commun aux trois signaux, sur gRPC ou HTTP. |
| **Pull / Push** | Modèles de collecte : le collecteur interroge les cibles (*pull*, Prometheus) ou les sources émettent spontanément (*push*, logs et traces). |
| **RED** | *Rate, Errors, Duration* ; méthodologie d'instrumentation orientée services. |
| **Recording rule** | Expression PromQL pré-calculée et matérialisée en nouvelle série, allégeant tableaux de bord et alertes. |
| **SLI / SLO / SLA** | *Service Level Indicator / Objective / Agreement* ; mesure de qualité de service, cible interne, engagement contractuel. |
| **Span** | Unité élémentaire de travail dans une trace : opération bornée, dotée d'un `span_id`, d'un parent, d'attributs et d'événements. |
| **Tail-based sampling** | Échantillonnage décidé après complétion de la trace, permettant de conserver préférentiellement erreurs et latences anormales. |
| **Trace / trace_id** | Cheminement complet d'une requête à travers les composants ; identifiant unique propagé de bout en bout. |
| **TSDB** | *Time Series Database* ; base optimisée pour l'écriture en append et la lecture par plages temporelles de couples (horodatage, valeur). |
| **USE** | *Utilization, Saturation, Errors* ; méthodologie d'instrumentation orientée ressources. |

## 12.2. Liens utiles incontournables

| **Catégorie** | **Ressource** | **Lien** | **OpenSource** | **Commentaire** |
| --- | --- | --- | --- | --- |
| **Standards & spécifications** | OpenTelemetry | [opentelemetry.io](https://opentelemetry.io/) | Oui | Standard de fait pour l'instrumentation ; API, SDK, OTLP, conventions sémantiques. Le point de départ obligé. |
| W3C Trace Context | [w3.org/TR/trace-context](https://www.w3.org/TR/trace-context) | — | Norme de propagation du contexte de trace entre services (`traceparent`). |
| OpenMetrics | [openmetrics.io](https://openmetrics.io/) | — | Format d'exposition des métriques, issu de Prometheus. |
| CNCF Landscape | [landscape.cncf.io](https://landscape.cncf.io/) | — | Cartographie de référence de tout l'écosystème *cloud native*, dont l'observabilité. |
| **Produits open source** | Prometheus | [prometheus.io](https://prometheus.io/) | Oui | Standard de collecte et de stockage de métriques ; socle de l'écosystème. |
| Grafana + stack LGTM | [grafana.com/oss](https://grafana.com/oss) | Oui | Visualisation (Grafana) et *backends* Loki / Tempo / Mimir ; la stack composable de référence. |
| OpenTelemetry Collector | [github.com/open-telemetry/opentelemetry-collector](https://github.com/open-telemetry/opentelemetry-collector) | Oui | Pièce centrale de collecte/transformation/routage de la télémétrie. |
| Jaeger | [jaegertracing.io](https://www.jaegertracing.io/) | Oui | *Backend* de traçage distribué historique de la CNCF. |
| VictoriaMetrics | [victoriametrics.com](https://victoriametrics.com/) | Oui | Alternative Prometheus réputée pour son efficacité mémoire et sa compression. |
| SigNoz | [signoz.io](https://signoz.io/) | Oui | Plateforme unifiée OTel-native (ClickHouse) ; alternative *all-in-one* à assembler soi-même. |
| OpenObserve | [openobserve.ai](https://openobserve.ai/) | Oui | Plateforme unifiée en binaire unique, stockage objet ; positionnée sur le coût de rétention. |
| Perses | [perses.dev](https://perses.dev/) | Oui | Outil de *dashboards-as-code*, natif Kubernetes ; projet CNCF émergent. |
| **Produits leaders du marché** | Datadog | [datadoghq.com](https://www.datadoghq.com/) | Non | Leader généraliste ; plateforme unifiée observabilité + sécurité, très large catalogue d'intégrations. |
| Dynatrace | [dynatrace.com](https://www.dynatrace.com/) | Non | Leader APM, forte automatisation et analyse de cause racine assistée par IA. |
| Grafana Cloud | [grafana.com/products/cloud](https://grafana.com/products/cloud) | Non | Offre managée de la stack LGTM ; ancrage open source et standards ouverts. |
| Elastic Observability | [elastic.co/observability](https://www.elastic.co/observability) | Non | Adossé à Elasticsearch ; recherche plein texte puissante sur la télémétrie. |
| New Relic | [newrelic.com](https://newrelic.com/) | Non | APM historique, tarification à l'usage centrée sur le volume ingéré. |
| Chronosphere | [chronosphere.io](https://chronosphere.io/) | Non | Spécialiste du contrôle de coût et de cardinalité à grande échelle (origine M3). |
| Coralogix | [coralogix.com](https://coralogix.com/) | Non | Traitement de la télémétrie « en flux » avant indexation, pour maîtriser les coûts. |
| Splunk (Cisco) | [splunk.com](https://www.splunk.com/) | Non | Plateforme d'analyse de logs à grande échelle ; intégrée à Cisco. |
| **Profiling & eBPF** | Grafana Pyroscope | [grafana.com/oss/pyroscope](https://grafana.com/oss/pyroscope) | Oui | Profiling continu open source ; 4ᵉ signal aux côtés de métriques/logs/traces. |
| Parca | [parca.dev](https://www.parca.dev/) | Oui | Profiling continu par eBPF, faible surcoût, à l'échelle du parc. |
| Coroot | [coroot.com](https://coroot.com/) | Oui | Observabilité *zero-instrumentation* par eBPF, avec cartographie de services automatique. |
| **Observabilité IA / LLM** | Langfuse | [langfuse.com](https://langfuse.com/) | Oui | Observabilité open source des applications LLM (traces de prompts, coûts, évaluations). |
| OpenLLMetry | [github.com/traceloop/openllmetry](https://github.com/traceloop/openllmetry) | Oui | Extensions OpenTelemetry pour instrumenter les charges LLM sur les standards existants. |
| **Méthodologie & apprentissage** | Google SRE Books | [sre.google/books](https://sre.google/books) | — | Références fondatrices : SLO, error budgets, alerte multi-*burn-rate*. |
| Brendan Gregg | [brendangregg.com](https://www.brendangregg.com/) | — | Méthode USE et ressources de référence sur la performance système et eBPF. |

> 📝 ***— = non applicable (spécification ou ressource, pas un logiciel).***

## 12.3. Références

**Standards et spécifications**

- OpenTelemetry — spécification, conventions sémantiques et documentation : `opentelemetry.io/docs`
- W3C Trace Context — recommandation sur la propagation de contexte : `www.w3.org/TR/trace-context`
- OpenMetrics — format d'exposition des métriques : `openmetrics.io`

**Projets (documentation officielle)**

- Prometheus (TSDB, PromQL, Alertmanager) : `prometheus.io/docs`
- Grafana Loki (logs, LogQL) : `grafana.com/docs/loki`
- Grafana Tempo (traces, TraceQL) : `grafana.com/docs/tempo`
- Grafana (visualisation, corrélation) : `grafana.com/docs/grafana`
- Thanos : `thanos.io` — Mimir : `grafana.com/docs/mimir` — VictoriaMetrics : `docs.victoriametrics.com`
- Collecteurs : Fluent Bit `docs.fluentbit.io`, Vector `vector.dev/docs`

**Ouvrages et méthodologies de référence**

- Google, *Site Reliability Engineering* et *The SRE Workbook* — SLO, error budgets, alerte multi-burn-rate : `sre.google/books`
- B. Gregg — méthode USE : `brendangregg.com/usemethod.html`
- T. Wilkie — méthode RED (origine du concept)
- C. Majors, L. Fong-Jones, G. Miranda, *Observability Engineering*, O'Reilly