Fondamentaux de l'observabilité : les concepts derrière les outils

Vous avez collecté des métriques, construit un tableau de bord, posé des alertes, centralisé des journaux et instrumenté un service : ce module prend du recul sur ces gestes. Il pose les concepts qui restent valables quel que soit l'outil, pour que vous sachiez justifier un choix devant une autre pile que celle du lab. Il est facultatif et ne contient aucun lab : huit leçons de concepts, chacune vérifiée par son propre quiz, qui vont des trois signaux aux objectifs de fiabilité, au standard OpenTelemetry, à la corrélation et à la gouvernance.

Que couvre ce module ?

Le module s'ouvre sur les trois signaux, une leçon chacun. Les métriques expliquent les quatre types (counter, gauge, histogram, summary), le rôle des labels, le piège de la cardinalité, les conventions de nommage et le choix entre collecte pull ou push. Les logs montrent ce qui rend un journal interrogeable : format structuré, niveaux de sévérité, champs indispensables, données interdites et coût de stockage. Les traces décrivent le span, la propagation du contexte par l'en-tête traceparent et les deux familles d'échantillonnage.

Deux leçons transforment ensuite ces signaux en décisions. Golden Signals, RED et USE répond à la question « quoi mesurer ? » selon le type de composant : un service qui répond à des requêtes ne se surveille pas comme un disque. SLI, SLO et budget d'erreur fait passer de la mesure à l'objectif : écrire un indicateur en ratio, fixer un niveau de fiabilité, en déduire un budget d'erreur et calculer la vitesse à laquelle il se consomme, le burn rate.

Les trois dernières leçons relient le tout. OpenTelemetry détaille l'architecture du standard : API, SDK, protocole OTLP et Collector. La corrélation explique comment un même trace_id et les exemplars permettent de passer d'une alerte à la cause en suivant le fil d'un signal à l'autre. La gouvernance traite enfin ce qui rend l'ensemble durable : coûts, rétention, budget de cardinalité, masquage des données sensibles et conventions communes.

Pourquoi ce module vient-il après la pratique ?

Aucune de ces leçons n'est un prérequis des leçons pratiques. Le lab Prometheus enseigne lui-même les types de métriques et la cardinalité au moment où vous en avez besoin, et la leçon Instrumenter un service avec OpenTelemetry fait émettre des spans et propager leur contexte. Placer ces concepts avant aurait ajouté plusieurs heures de lecture avant la première métrique collectée.

Lu après, le module joue un autre rôle : il généralise ce que vous avez fait avec un outil précis. Vous avez écrit un rate() sur un compteur dans le lab : la leçon sur les métriques explique pourquoi un counter ne se lit jamais brut, quel que soit le système qui le stocke. Vous avez posé une alerte dans le lab Alertmanager : la leçon sur les SLO montre comment la rendre actionnable en alertant sur la vitesse de consommation d'un budget plutôt que sur un seuil.

Trois de ces leçons, la corrélation, les SLO et la gouvernance, relèvent surtout de la production, que les labs de la formation ne couvrent pas encore en pratique. Les lire vous prépare aux questions qu'une équipe d'exploitation pose avant d'ouvrir un service à ses utilisateurs : combien de temps garder les données, qui peut les voir, et quel niveau de fiabilité promettre.

Dans quel ordre lire les leçons ?

L'ordre du plan suit les dépendances entre les notions. Les logs se comprennent mieux une fois la métrique posée, parce que la leçon les compare point par point ; les traces s'appuient sur les deux. La leçon sur les modèles mentaux emploie le taux d'un compteur et le percentile d'un histogramme, vus avec les métriques. Celle sur les SLO écrit un indicateur comme un ratio de compteurs, choisi avec la méthode RED.

La seconde moitié du module suit la même logique. OpenTelemetry réutilise le vocabulaire des traces : span, propagation, échantillonnage. La corrélation suppose les trois signaux et le SDK qui injecte le trace_id. La gouvernance vient en dernier parce qu'elle touche tout à la fois : la cardinalité des métriques, le volume des logs, l'échantillonnage des traces et le masquage dans le Collector.

Si une leçon vous manque pour un besoin précis, vous pouvez la lire seule : chacune redéfinit ses termes à leur première occurrence et renvoie vers la leçon qui détaille une notion qu'elle ne fait que citer. La leçon Observabilité ou monitoring, au début de la formation, reste le meilleur point d'entrée si vous arrivez directement ici : elle pose la différence entre surveiller l'attendu et diagnostiquer l'imprévu.

Ce que ce module ne fait pas

Ce module explique et fait calculer, il ne fait rien exécuter. Vous y calculerez un budget d'erreur, un burn rate ou le nombre de séries qu'un label va créer, mais aucune leçon ne vous fait écrire un SLO dans un outil ni configurer un pipeline de corrélation. Les gestes correspondants sont dans les modules pratiques de la formation, ou n'y sont pas encore.

Les leçons citent des produits pour illustrer un concept : Prometheus pour la collecte pull, Grafana pour l'affichage des exemplars, Loki pour l'indexation par labels. Le concept reste le sujet, le produit n'est qu'un exemple, et les quiz de chaque leçon le respectent : ils se réussissent avec n'importe quelle pile, sans connaître la syntaxe propre d'un outil.

À retenir

• Ce module est facultatif : il éclaire les gestes des modules précédents sans en ajouter, et aucune compétence de la formation ne l'exige
• Il couvre les trois signaux, le choix de quoi mesurer, les SLO, OpenTelemetry, la corrélation et la gouvernance
• Les leçons se lisent dans l'ordre du plan, qui suit les dépendances entre notions, ou une à une selon le besoin
• Chaque leçon porte son quiz, conçu pour être réussi quelle que soit la pile d'outils utilisée

×

📖 Voir la documentation →