Observabilité — les trois piliers

Le concept en une phrase

L’observabilité, c’est la capacité à comprendre l’état interne d’un système à partir de ses signaux externes — métriques, logs, traces.

Une base australe fait tourner des dizaines de services critiques (énergie, télémétrie satellite, systèmes de vie) sur un lien qui peut tomber à tout moment. Personne n’a le temps d’ouvrir chaque machine pour savoir si elle va bien. L’observabilité, c’est faire parler les systèmes eux-mêmes : ils émettent des signaux, on les collecte, on les lit — et on comprend ce qui se passe à l’intérieur sans y être physiquement.

Les grands principes

1. Monitoring vs observabilité — surveiller le connu, comprendre l’inconnu

Les deux mots se confondent souvent, mais ils ne répondent pas à la même question.

Le monitoring surveille des indicateurs qu’on a déjà identifiés : « le CPU dépasse-t-il 90 % ? », « le service répond-il ? ». C’est efficace pour les pannes qu’on a déjà vues.
L’observabilité va plus loin : elle donne les moyens de poser une question qu’on n’avait pas anticipée — « pourquoi ce service ralentit-il seulement le mardi, seulement sur cette base ? » — et d’y répondre à partir des données déjà collectées, sans redéployer d’instrumentation.

Le monitoring répond aux questions connues à l’avance. L’observabilité permet de répondre aux questions qu’on découvre en cours d’incident.

2. Les trois piliers — chacun répond à une question différente

flowchart LR
    S[Système observé] --> M[Métriques]
    S --> L[Logs]
    S --> T[Traces]
    M -->|"Combien ?"| Q1[CPU, latence,\ndébit, erreurs/s]
    L -->|"Quoi, quand ?"| Q2[Événement précis,\nhorodaté, contextualisé]
    T -->|"Où, dans quel ordre ?"| Q3[Parcours d'une requête\nà travers la chaîne]

Métriques — combien ? Des séries numériques dans le temps (CPU, latence, débit). Légères, agrégeables, parfaites pour l’alerting et les tendances. Dans TAAF : Prometheus, en modèle pull — le serveur va lui-même interroger chaque cible à intervalle régulier, plutôt que d’attendre que les cibles poussent leurs données.
Logs — quoi, quand ? Des événements discrets et horodatés : une connexion, une erreur, une commande exécutée. C’est le détail que la métrique ne donne pas. Dans TAAF : Loki stocke, LogQL interroge.
Traces — où, dans quelle chaîne ? Le parcours d’une requête à travers plusieurs services, avec les temps passés à chaque étape. Utile dès qu’un système est distribué et qu’il faut savoir quel maillon a ralenti.

Les trois se complètent : une métrique dit qu’il y a un problème, un log dit ce qui s’est passé, une trace dit où dans la chaîne ça s’est passé.

3. Pourquoi centraliser — un SI en silos est aveugle

Sans centralisation, chaque service garde ses logs et ses métriques localement, sur sa propre machine. Le jour d’un incident, il faut se connecter service par service, machine par machine, pour reconstituer une chronologie — en pleine crise, sur un lien satellite qui peut couper à tout moment.

Centraliser les signaux dans une seule stack (Alloy → Loki/Prometheus → Grafana) change la donne : un seul endroit où chercher, une seule requête pour croiser plusieurs sources, une vue qui survit même si la machine d’origine est hors service. Un système d’information en silos est un système d’information aveugle — chaque silo voit midi à sa porte, personne ne voit l’ensemble.

4. La cardinalité — le coût caché

Un exporter Prometheus ou un flux de logs peut sembler gratuit à instrumenter. Le piège est ailleurs : chaque label (un tag comme pod, user_id, ip_source) multiplie le nombre de séries distinctes à stocker. Ajouter un label à haute cardinalité — un identifiant unique par requête, par exemple — peut faire exploser le volume de données de plusieurs ordres de grandeur, jusqu’à saturer le disque ou rendre les requêtes intenables.

Retenez : un label doit avoir un nombre de valeurs borné et raisonnable (un nom de service, un statut HTTP, une base). Jamais un identifiant unique par événement.

5. Voir avant de détecter — le prérequis du SIEM

L’observabilité n’est pas une fin en soi dans TAAF : c’est la fondation de la détection. La même stack qui sert à surveiller la santé des systèmes (Acte 1) devient, sans rien changer d’infrastructure, la sentinelle qui détecte une attaque (Acte 2). Les logs collectés par Alloy dans Loki sont exactement ceux que les règles Sigma, traduites en requêtes LogQL, viendront interroger pour repérer un comportement malveillant.

C’est le pont entre les deux actes : on ne peut pas détecter ce qu’on ne voit pas. Construire une observabilité solide, c’est déjà construire la moitié du SOC.

Où ça sert dans TAAF

Introduction de l’Acte 1 — Monitoring — le module qui déploie la stack Prometheus/Grafana/Loki sur les bases australes.
TP1 — Rendre la vue au SOC — premier dashboard Grafana, les métriques appliquées à la supervision des conteneurs de Port-aux-Français.
TP3 — Loki Integration — intégrer Loki pour corréler logs et métriques, le pilier « logs » en pratique.
Acte 2 — SIEM — la suite logique : la même stack Grafana-native devient le cœur de la détection.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Observabilité.

Prometheus — documentation officielle : le modèle pull et PromQL expliqués à la source.
Grafana Loki — documentation officielle : l’agrégation de logs et LogQL en détail.

À chercher par vous-même : « monitoring vs observability », « the three pillars of observability », « Prometheus cardinality explosion », « pull vs push metrics ».