L'observabilité est la capacité à comprendre ce que fait un système en production à partir de ce qu'il émet : métriques, journaux et traces. Cette page ouvre la formation Observabilité, une formation courte et ciblée qui vous fait rendre un service observable sur un cluster Kubernetes local, de la métrique Prometheus au pipeline OpenTelemetry. Elle s'adresse aux ops, SRE et Platform Engineers débutants à intermédiaires qui savent manipuler un terminal et lire du YAML. Vous y trouverez le programme module par module, les prérequis, la façon dont vos acquis sont validés, et ce que la formation laisse volontairement de côté.
Autour de la formation, la section garde ses pages de référence : des guides de bonnes pratiques pour une stack déjà en place, et la fiche de chaque outil, de Prometheus à Loki. Une partie de ces pages entre au parcours comme leçons facultatives qui approfondissent un module ; le reste se consulte à la demande.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Collecter les métriques d'un service et en contrôler la qualité
- Interroger ces métriques en PromQL pour répondre à une question d'exploitation
- Construire un tableau de bord Grafana provisionné comme du code
- Définir une alerte actionnable et la router sans bruit avec Alertmanager
- Centraliser et interroger les journaux d'un service avec Loki
- Instrumenter un service avec OpenTelemetry et acheminer sa télémétrie par un Collector
L'observabilité dans la démarche DevOps et SRE
Section intitulée « L'observabilité dans la démarche DevOps et SRE »L'observabilité n'est pas un outil de plus à installer, c'est un pilier fondamental des pratiques DevOps et SRE modernes.
DevOps : accélérer les boucles de feedback
Section intitulée « DevOps : accélérer les boucles de feedback »En DevOps, l'objectif est de réduire le temps entre une modification de code et son impact en production. L'observabilité rend ce cycle possible :
- Déploiement continu : les métriques et traces permettent de valider automatiquement qu'un déploiement n'a pas dégradé les performances
- Feature flags : les logs et métriques mesurent l'adoption et les erreurs d'une nouvelle fonctionnalité
- Rollback rapide : la corrélation des signaux détecte une régression en minutes, pas en heures
Sans observabilité, le « you build it, you run it » reste une promesse vide, les équipes ne peuvent pas assumer la responsabilité de ce qu'elles ne peuvent pas voir.
SRE : mesurer et garantir la fiabilité
Section intitulée « SRE : mesurer et garantir la fiabilité »Le Site Reliability Engineering repose sur des objectifs mesurables. L'observabilité fournit les données pour :
| Concept SRE | Rôle de l'observabilité |
|---|---|
| SLI (Service Level Indicator) | Métriques qui quantifient la qualité perçue par les utilisateurs |
| SLO (Service Level Objective) | Seuils définis sur les SLI (ex: 99.9% de disponibilité) |
| Error Budget | Marge de manœuvre calculée à partir des SLI/SLO pour décider quand ralentir les déploiements |
| Incident Response | Traces et logs pour diagnostiquer rapidement la cause racine |
| Post-mortem | Données factuelles pour analyser les incidents sans blâme |
L'observabilité transforme les discussions subjectives (« le site est lent ») en données actionnables (« le P99 du checkout dépasse 800 ms depuis 14 h »).
En résumé
Section intitulée « En résumé »Ce qui change concrètement, ce n'est pas la quantité de graphiques affichés, c'est la formulation des constats. À gauche, des phrases invérifiables qui mènent à des arbitrages au jugé ; à droite, des mesures datées et chiffrées sur lesquelles une équipe peut décider. Lisez chaque ligne comme une paire : même situation, deux niveaux de preuve disponibles.
| Sans observabilité | Avec observabilité |
|---|---|
| « Ça marche sur ma machine » | « Le déploiement a augmenté la latence de 15 % » |
| « On a eu une panne hier » | « L'incident a duré 23 min, impactant 2,3 % des requêtes » |
| « Il faut plus de serveurs » | « Le service X consomme 40 % du CPU pour 5 % du trafic » |
| Réaction aux plaintes utilisateurs | Détection proactive avant impact visible |
Comment la formation est-elle organisée ?
Section intitulée « Comment la formation est-elle organisée ? »La formation suit le trajet d'un signal, dans un ordre imposé par les dépendances techniques : sans Prometheus en place, Alertmanager n'a rien à router, et sans métriques collectées, un tableau de bord n'a rien à montrer. Cinq modules de pratique se succèdent, chacun avec un cœur à suivre et, parfois, des leçons facultatives d'approfondissement. Deux modules facultatifs en entier viennent ensuite : les fondamentaux, puis les pratiques d'exploitation. Le programme détaillé, avec votre progression leçon par leçon, est sur la page Mon parcours.
La dernière colonne du tableau compte les leçons du cœur, puis les leçons facultatives du module.
| Module | Ce que vous y faites | Leçons |
|---|---|---|
| Comprendre et préparer | Le lab local, observabilité ou monitoring, cluster Minikube, application OpenTelemetry Demo | 4, plus 1 facultative |
| Métriques | Prometheus sur Kubernetes, exporters, PromQL, Pushgateway pour un job batch | 4, plus 3 facultatives |
| Visualiser et alerter | Tableaux de bord Grafana, alertes avec Alertmanager | 2, plus 3 facultatives |
| Journaux | Loki sur le cluster, Loki hors Kubernetes avec Alloy | 2 |
| Instrumenter et acheminer | Instrumentation OpenTelemetry, Collector, diagnostic d'un pipeline | 3, plus 3 facultatives |
| Approfondir : les fondamentaux (facultatif) | Concepts : signaux, SLO, OpenTelemetry, corrélation, gouvernance | 9 facultatives |
| Approfondir : les pratiques d'exploitation (facultatif) | Tableaux de bord, alertes, observabilité de Kubernetes, AIOps | 5 facultatives |
Comprendre et préparer
Section intitulée « Comprendre et préparer »Le premier module commence par la présentation du lab Kubernetes local : son dépôt Git, la machine qu'il demande et les interfaces qu'il expose. Il pose ensuite le modèle mental avant les outils, ce qui sépare l'observabilité de la simple supervision. Il installe enfin le cluster Minikube, Helm et kubectl, puis déploie l'application à observer, l'OpenTelemetry Demo, avec le Collector qui rendra ses métriques lisibles par Prometheus. Un panorama des outils, facultatif, situe les familles d'outils avant de se lancer.
Métriques
Section intitulée « Métriques »C'est le plus long des modules de pratique, et le plus rentable : PromQL sert ensuite dans chaque tableau de bord et chaque règle d'alerte. Le lab installe Prometheus sur le cluster et fait écrire des requêtes sur de vraies données ; la leçon sur les exporters montre comment exposer les métriques d'un composant qu'on ne peut pas modifier, et la leçon PromQL reprend le langage en profondeur, jusqu'au vector matching. Le cœur se termine par le Pushgateway, qui fait superviser un job batch trop court pour être scrapé : la métrique survit au job, et seules une alerte sur l'âge du dernier succès et une alerte d'absence révèlent un job qui ne tourne plus. Trois leçons facultatives complètent le cœur : le modèle pull et les types de métriques, la configuration de Prometheus (découverte, relabeling, règles), et le choix d'un backend de métriques.
Visualiser et alerter
Section intitulée « Visualiser et alerter »Une métrique que personne ne regarde ne sert à rien. Ce module construit un
tableau de bord Grafana panneau par panneau, le rend dynamique avec des
variables, puis le provisionne comme du code. Il pose ensuite des règles
d'alerte dans Prometheus, les teste avec promtool avant de les déployer, et
configure Alertmanager : routage, silences, inhibitions, et le principe qui
décide de tout, alerter sur les symptômes.
Trois fiches Grafana facultatives approfondissent le choix des
visualisations, les variables et le provisionnement.
Journaux
Section intitulée « Journaux »Les métriques disent qu'un problème existe, les journaux disent pourquoi. Le lab centralise les logs du cluster dans Loki et les interroge en LogQL ; la leçon suivante reprend Loki hors Kubernetes, avec Grafana Alloy, l'agent qui remplace Promtail, et le piège qui fait tomber la plupart des installations : la cardinalité des labels.
Instrumenter et acheminer
Section intitulée « Instrumenter et acheminer »Le dernier module de pratique remonte à la source. Il montre comment instrumenter un service avec OpenTelemetry, en automatique puis avec des spans métier, et comment le configurer pour la production. Il passe ensuite au Collector, qui reçoit la télémétrie en OTLP et l'achemine vers les backends : un pipeline joué de bout en bout jusqu'à Jaeger. Son cœur se termine par le diagnostic d'un pipeline qui ne livre rien, lu dans les métriques internes du Collector, puisque son health check reste vert pendant la panne. Trois leçons facultatives élargissent le cœur : les couches et architectures d'instrumentation, l'instrumentation d'une application JVM avec Micrometer et le choix d'un collecteur de télémétrie.
Approfondir : les fondamentaux (facultatif)
Section intitulée « Approfondir : les fondamentaux (facultatif) »Ce module se lit après la pratique, et vous pouvez le sauter sans perdre le fil de la formation. Il rassemble les concepts qui valent quel que soit l'outil : métriques, logs et traces, modèles de mesure (Golden Signals, RED, USE), SLI, SLO et budget d'erreur, architecture d'OpenTelemetry, corrélation et gouvernance. Ce sont des leçons de lecture, sans lab, qui généralisent les gestes déjà faits.
Approfondir : les pratiques d'exploitation (facultatif)
Section intitulée « Approfondir : les pratiques d'exploitation (facultatif) »Le dernier module se lit après les fondamentaux, dont il applique les modèles de mesure (RED, USE) et le budget d'erreur, et il se saute aussi sans perdre le fil. Il s'adresse à qui a déjà une stack et veut l'améliorer : concevoir des tableaux de bord qui servent au diagnostic, des alertes qui réveillent pour les bonnes raisons, observer un cluster Kubernetes (signaux clés et pièges), et situer l'AIOps. Ce sont, là encore, des leçons de lecture, sans lab. Elles s'ouvrent sur la page des pratiques.
Ce que la formation laisse de côté
Section intitulée « Ce que la formation laisse de côté »La formation est courte et ciblée : elle vise les gestes qu'un SRE ou un Platform Engineer doit savoir faire seul, pas l'ensemble du domaine. Trois sujets restent hors périmètre, et ce choix est délibéré.
- Le stockage des traces dans Tempo, l'analyse et la corrélation des signaux en conditions réelles, et la mise en production de la stack (haute disponibilité, rétention longue, RBAC) : la formation n'en fait pas de lab. Elle joue en revanche un pipeline de traces jusqu'à Jaeger, et ses concepts sont dans le module facultatif des fondamentaux.
- Les comparatifs d'outils : la formation enseigne à choisir un backend de métriques et un collecteur de télémétrie, et à choisir une architecture d'instrumentation : trois leçons facultatives avec quiz. Les autres comparatifs (APM, agents propriétaires) restent de la référence, tout comme l'AIOps, simplement située dans une leçon facultative des pratiques d'exploitation. Les concepts de gouvernance des coûts sont, eux, dans les fondamentaux.
- Les certifications : aucune n'est visée.
À qui s'adresse cette formation ?
Section intitulée « À qui s'adresse cette formation ? »Elle est conçue pour les ops, SRE et Platform Engineers qui doivent rendre un service observable, et pour les développeurs qui veulent savoir ce que leur application émet. Aucune connaissance préalable d'un outil d'observabilité n'est requise ; quelques bases le sont.
| Prérequis | Niveau requis | Notes |
|---|---|---|
| Linux / Terminal | Basique | Savoir naviguer, éditer des fichiers, lire des logs |
| Docker | Basique | Lancer un conteneur et lire ses logs (docker run, docker logs, docker compose up) : plusieurs leçons jouent leur lab en conteneurs hors du cluster |
| Kubernetes | Notions | Savoir ce qu'est un pod, un service, un namespace ; la leçon facultative sur l'observabilité de Kubernetes ajoute la lecture des requests et limits d'un pod |
| YAML | Basique | Savoir lire et modifier des fichiers YAML |
| Python | Lecture | Pour le module « Instrumenter et acheminer » seulement : installer un paquet avec pip, lancer un programme et modifier une fonction existante |
Le module d'instrumentation ajoute des spans dans le code d'une application, d'où la dernière ligne : lire et modifier un programme suffit, sans savoir en écrire un. Si ce n'est pas encore votre cas, la leçon Lire et modifier un script Python de la formation Développer pour les Ops couvre ce niveau. Les autres modules n'en ont pas besoin, et la leçon facultative Micrometer suppose plutôt de lire du Java et un projet Spring Boot.
Le lab fait tourner une vingtaine de microservices et toute la stack d'observabilité sur votre poste : comptez 8 Go de RAM au minimum. La configuration matérielle complète est détaillée dans la présentation du lab local, première leçon du parcours.
Ce que cette formation défend
Section intitulée « Ce que cette formation défend »Trois choix structurent la formation, et je les assume : ils viennent de ce qui fait échouer une plateforme d'observabilité bien plus souvent que le choix d'un outil.
- PromQL avant les tableaux de bord. Un dashboard n'est qu'une requête mise en forme : qui ne sait pas écrire la requête copie des panneaux qu'il ne sait pas lire. C'est pourquoi le module métriques est le plus long des modules de pratique.
- Le symptôme avant la cause. On alerte sur ce que vit l'utilisateur, latence et erreurs, pas sur un CPU à 80 % qui peut être parfaitement normal. Chaque alerte doit dire quoi faire.
- Tout comme du code, tout épinglé. Dashboards provisionnés, règles dans les values Helm, images épinglées par digest : ce qui n'est pas dans le dépôt n'existe pas, et ce qui n'est pas épinglé changera sans prévenir.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »Deux erreurs se commettent dès la première installation et coûtent cher bien avant de se voir : je vous demande de ne jamais les laisser passer en revue.
- Un identifiant unique en label. Un
user_idou untrace_iden label, dans Prometheus comme dans Loki, crée une série ou un stream par valeur : la cardinalité explose, avec la mémoire et la facture. - Sauter une étape du lab. Chaque leçon installe ce que la suivante interroge : une erreur laissée en place se propage et réapparaît trois leçons plus loin sous une forme méconnaissable.
Valider vos acquis
Section intitulée « Valider vos acquis »Chaque leçon de pratique du cœur se termine par un quiz tiré de la banque de la formation, et vos scores alimentent les compétences d'observabilité des métiers SRE et Platform Engineer. Les leçons facultatives approfondissent sans conditionner cette validation : les compétences reposent sur le cœur de la formation. Les labs sont guidés : chacun se vérifie par sa section de validation, que vous contrôlez vous-même. La compétence est donc évaluée par les quiz, sans lab noté automatiquement.
L'observabilité est aussi un pilier des certifications Kubernetes, que la formation ne vise pas : le CKA et le CKS incluent des compétences de monitoring et de diagnostic.
Explorer cette section
Section intitulée « Explorer cette section »La section ne se limite pas au cœur de la formation. Les fondamentaux et les pratiques en sont les deux modules facultatifs : les premiers posent le vocabulaire et les modèles, les secondes servent à qui a déjà une stack et veut l'améliorer (tableaux de bord, alerting, observabilité Kubernetes). Les runbooks d'incident restent une page de référence, hors de ce parcours. Le catalogue des outils sert quand vous cherchez une option de configuration précise, et plusieurs de ses fiches sont aussi des leçons facultatives.
L'écosystème d'outils open source
Section intitulée « L'écosystème d'outils open source »Les outils ci-dessous reviennent dans tous les guides de la section. Ils se répartissent en trois couches successives : instrumenter la source, collecter et stocker le signal, puis visualiser et alerter. Un trou dans une couche rend les deux autres inutiles, ce qui explique pourquoi une stack d'observabilité s'assemble rarement outil par outil.
Collecte et stockage
Section intitulée « Collecte et stockage »C'est la couche qui coûte le plus cher à exploiter, parce que c'est elle qui écrit sur disque. La colonne Signal est la plus importante à lire : chaque moteur est spécialisé sur un type de donnée et les mélanger dans un seul backend finit toujours par un problème de rétention. L'OpenTelemetry Collector fait exception, il ne stocke rien mais oriente les trois signaux vers le bon destinataire.
| Outil | Signal | Rôle | Guide |
|---|---|---|---|
| Prometheus | Métriques | Collecte, stockage, requêtes (PromQL) | Installation |
| Loki | Logs | Agrégation de logs, requêtes (LogQL) | Guide Loki |
| Tempo | Traces | Stockage de traces distribuées | Guide Tempo |
| OpenTelemetry Collector | Tous | Pipeline de collecte unifié | Guide OTel Collector |
Visualisation et alerting
Section intitulée « Visualisation et alerting »Ces deux outils sont souvent confondus alors qu'ils traitent des moments différents. Grafana sert quand un humain regarde déjà l'écran ; Alertmanager sert quand personne ne regarde et qu'il faut décider qui réveiller. Une plateforme qui n'a que Grafana ne détecte rien la nuit, une plateforme qui n'a qu'Alertmanager ne permet pas de comprendre ce qui a été détecté.
| Outil | Rôle | Guide |
|---|---|---|
| Grafana | Dashboards, exploration, corrélation | Guide Grafana |
| Alertmanager | Routing des alertes, silences, notifications | Guide Alertmanager |
Instrumentation
Section intitulée « Instrumentation »L'instrumentation est l'étape que les équipes repoussent le plus, et c'est pourtant elle qui détermine la qualité de tout le reste : un backend ne peut rien montrer que la source n'a pas émis. Les exporters Prometheus couvrent ce que vous n'avez pas écrit vous-même (base de données, système, broker), le SDK OpenTelemetry couvre votre propre code.
| Outil | Rôle | Guide |
|---|---|---|
| OpenTelemetry SDK | Instrumentation des applications | OpenTelemetry |
| Exporters Prometheus | Exposition des métriques (Node, MySQL, Redis...) | Exporters |
Alternatives selon vos besoins
Section intitulée « Alternatives selon vos besoins »Le choix entre open source et SaaS ne se joue pas sur les fonctionnalités, qui se recouvrent largement, mais sur le coût d'exploitation que vous acceptez d'internaliser. Un backend auto-hébergé demande du stockage, de la rétention et une astreinte ; un service managé facture au volume ingéré, ce qui pousse à filtrer à la source. Retenez surtout que les colonnes ne sont pas exclusives : l'instrumentation OpenTelemetry reste la même des deux côtés, ce qui permet de changer de destination sans retoucher le code applicatif.
| Besoin | Open source | SaaS managé |
|---|---|---|
| Métriques | Prometheus, VictoriaMetrics, Mimir | Datadog, New Relic, Grafana Cloud |
| Logs | Loki, OpenSearch, Elasticsearch | Datadog, Splunk, Grafana Cloud |
| Traces | Tempo, Jaeger, Zipkin | Datadog, Honeycomb, Grafana Cloud |
| APM complet | SigNoz (open source) | Datadog, New Relic, Dynatrace |
Par où commencer ?
Section intitulée « Par où commencer ? »Le piège classique consiste à démarrer par l'installation d'un outil avant d'avoir posé la question à laquelle il doit répondre. Repérez d'abord votre ligne dans le tableau, puis suivez le parcours correspondant sans sauter d'étape : chaque leçon de pratique installe ce que la suivante interroge, et les concepts se relisent après coup dans les modules facultatifs.
| Votre situation | Parcours recommandé |
|---|---|
| Je découvre l'observabilité | La formation dans l'ordre, du lab local au Collector, puis les modules facultatifs Fondamentaux et Pratiques |
| Je connais les concepts, je veux pratiquer | Le lab local et son installation, puis les modules de pratique |
| J'ai déjà une stack, je veux améliorer | Les pratiques d'exploitation (tableaux de bord, alerting, Kubernetes), sans refaire le lab |
| Je cherche la doc d'un outil précis | Outils |
À retenir
Section intitulée « À retenir »- L'observabilité repose sur trois signaux : métriques, journaux et traces
- La formation suit le trajet d'un signal : métriques, tableaux de bord et alertes, journaux, puis instrumentation
- PromQL passe avant les tableaux de bord, et une alerte se pose sur un symptôme, pas sur une cause
- La cardinalité des labels est le piège commun à toute la stack
- Le stockage des traces, l'analyse des signaux corrélés et la production restent hors périmètre ; leurs concepts sont dans le module facultatif des fondamentaux
- Deux modules sont facultatifs en entier, les fondamentaux et les pratiques d'exploitation ; les autres ont un cœur à suivre, et la plupart y ajoutent des leçons d'approfondissement facultatives
- Les acquis sont évalués par un quiz par leçon de pratique du cœur, et les labs guidés se vérifient par leur section de validation