« Si mon application tourne, c’est qu’elle va bien. Je verrai bien si ça casse. »
Tu le verras… quand un utilisateur se plaindra, ou trop tard. Sans supervision, tu es aveugle : tu ne sais ni que ça ralentit, ni pourquoi, ni depuis quand. L’observabilité transforme ton infrastructure en système qui te parle — et t’alerte avant la catastrophe.
À la fin de ce module, tu sauras…
- Distinguer supervision et observabilité
- Nommer les trois piliers : métriques, logs, alertes
- Comprendre à quelle question chaque pilier répond
- Situer la stack Prometheus / Grafana / Loki / Alertmanager
01Le problème des 3 h du matin
Pose-toi les vraies questions
Ton infrastructure tourne : le cluster K3s, SORIA Web, Harbor, Jenkins. Imagine qu’à 3 h du matin, le site devient lent, puis inaccessible. Sans rien de plus que ce que tu as aujourd’hui, réponds :
| Question | Peux-tu y répondre maintenant ? |
|---|---|
| Est-ce que ça a cassé ? Depuis quand ? | ❌ non |
| Quel composant est en cause ? | ❌ non |
| La RAM / le CPU étaient-ils saturés ? | ❌ non |
| Qu’a dit l’application juste avant ? | ❌ non |
| Qui a été prévenu ? | ❌ personne |
Comprends supervision vs observabilité
La supervision (monitoring) surveille des choses connues d’avance (« le CPU dépasse-t-il 90 % ? »). L’observabilité est plus large : rendre le système suffisamment instrumenté pour répondre à des questions qu’on ne s’était pas posées à l’avance (« pourquoi ce service est-il lent maintenant ? »). L’une répond à « est-ce que ça va ? », l’autre à « pourquoi ça ne va pas ? ». On construit les deux.
02Les trois piliers
| Pilier | Répond à… | Exemple | Outil (stack) |
|---|---|---|---|
| Métriques | « combien ? quelle tendance ? » | CPU à 85 %, 200 req/s | Prometheus |
| Logs | « que s’est-il passé exactement ? » | « erreur 500 sur /login » | Loki |
| Alertes | « qui prévenir, quand ? » | « RAM > 90 % depuis 5 min » | Alertmanager |
| Visualisation | « montre-moi tout ça » | tableaux de bord | Grafana |
Comprends métriques et logs, la complémentarité
Les métriques sont des nombres dans le temps (séries temporelles) : légères, parfaites pour les tendances et les seuils (« le CPU monte depuis 20 min »). Les logs sont des événements textuels : lourds mais précis (« voici l’erreur exacte, à la milliseconde »). Une métrique te dit qu’il y a un problème ; un log te dit lequel. Tu as besoin des deux : l’un repère, l’autre explique.
03La stack, et pourquoi celle-ci
Comprends qui fait quoi dans la stack
Prometheus collecte et stocke les métriques. Loki centralise les logs (pensé comme « Prometheus pour les logs »). Alertmanager reçoit les alertes de Prometheus et les route (email, etc.). Grafana visualise tout, en interrogeant Prometheus et Loki. C’est la stack open-source de référence — mais retiens surtout les rôles (collecte de métriques, agrégation de logs, alerting, visualisation) : sur une plateforme managée (Datadog, Grafana Cloud, CloudWatch…), les outils changent, les rôles restent. Tu apprends une architecture d’observabilité, pas quatre logiciels.
04Où superviser : le cluster comme cible
Comprends pourquoi Kubernetes et l’observabilité vont ensemble
Un cluster est dynamique : les Pods naissent, meurent, se déplacent (tu l’as vu en Phase 5). Surveiller ça « à la main » est impossible. L’observabilité y est donc vitale, et Kubernetes est conçu pour ça : il publie nativement des métriques que Prometheus sait découvrir automatiquement. C’est l’environnement idéal pour comprendre la supervision moderne.
✓Ce que tu retiens
Une infra sans supervision est muette : tu ignores quand, où et pourquoi ça casse. L’observabilité repose sur trois piliers — métriques (combien / tendance), logs (quoi exactement), alertes (prévenir), plus la visualisation. La stack Prometheus / Loki / Alertmanager / Grafana couvre ces rôles — et ce sont les rôles, pas les outils, que tu emporteras partout.
Cartographie tes angles morts
À faire
- Liste 5 pannes plausibles de ton infra (Pod qui crashe, disque plein, service lent…).
- Pour chacune, note quelle donnée te permettrait de la détecter : métrique, log, ou les deux ?
- Pour chacune, définis un seuil d’alerte raisonnable (« au-delà de X pendant Y »).
- Associe chaque besoin à l’outil de la stack qui le couvre.
- Documente dans BookStack : les 3 piliers et la question à laquelle chacun répond.
?Auto-évaluation
1. Quelle est la différence entre supervision et observabilité ?
La supervision surveille des indicateurs connus d’avance (« est-ce que ça va ? ») ; l’observabilité instrumente le système pour répondre à des questions imprévues (« pourquoi ça ne va pas ? »).
2. Quels sont les trois piliers, et à quoi répondent-ils ?
Métriques (combien / quelle tendance), logs (que s’est-il passé exactement), alertes (qui prévenir et quand).
3. Pourquoi retenir les rôles plutôt que les outils ?
Parce que les rôles (collecte de métriques, agrégation de logs, alerting, visualisation) sont universels : sur une autre plateforme, les outils changent mais l’architecture reste.