Vous voulez mettre en place une pile d'observabilité, mais face à la jungle des outils (Prometheus, Grafana, Loki, Tempo, OTel Collector, Vector, Jaeger, Mimir, VictoriaMetrics), vous ne savez pas par où commencer ni comment les assembler. Ce panorama classe chaque outil par fonction dans le pipeline d'observabilité, de l'application à l'astreinte, avec des fiches qui expliquent quand et pourquoi l'utiliser, pas seulement comment l'installer.
Dans la formation Observabilité, cette page de cinq minutes est facultative : elle donne la carte du terrain avant d'installer le lab. La formation elle-même ne parcourt qu'un seul chemin (Prometheus, Grafana, Alertmanager, Loki, puis OpenTelemetry et son Collector) ; le reste de la carte sert à comprendre où s'en écarter quand votre contexte diffère.
Comment les outils s'enchaînent-ils dans un pipeline d'observabilité ?
Section intitulée « Comment les outils s'enchaînent-ils dans un pipeline d'observabilité ? »Un outil d'observabilité remplit toujours l'une de ces fonctions, qui s'enchaînent de l'application à la personne d'astreinte. Comprendre cet enchaînement aide à choisir et à assembler une pile cohérente, plutôt que de collectionner des outils.
Le schéma suit le chemin des données : l'application instrumentée émet ses signaux, le collecteur les agrège et les route, les backends les stockent, puis Grafana les affiche pendant que les règles d'alerte déclenchent des notifications via Alertmanager. Le collecteur, mis en avant, est le point qui vous évite de reconfigurer chaque application quand vous changez de backend.
Le tableau précise, pour chaque étape, son rôle et les outils typiques. Les trois backends (métriques, logs, traces) sont distincts parce que chaque signal a un modèle de stockage et un langage de requête propres.
| Étape | Rôle | Outils typiques |
|---|---|---|
| Instrumentation | Générer les signaux (métriques, logs, traces) dans l'application | SDK OTel, bibliothèques de métriques |
| Collecte et pipeline | Agréger, filtrer, router les signaux | OTel Collector, Vector, Fluent Bit, Grafana Alloy |
| Backend métriques | Stocker et interroger les métriques | Prometheus, Mimir, VictoriaMetrics |
| Backend logs | Stocker et interroger les logs | Loki, OpenSearch, rsyslog |
| Backend traces | Stocker et interroger les traces | Tempo, Jaeger |
| Visualisation | Dashboards, exploration | Grafana |
| Alerting | Déclencher des notifications | Alertmanager, Grafana Alerting |
| Astreinte | Gérer les astreintes et les escalades | PagerDuty et services équivalents |
| Synthetics | Checks externes, tests de charge | Uptime Kuma, k6 |
Quel outil choisir selon votre besoin ?
Section intitulée « Quel outil choisir selon votre besoin ? »Six besoins reviennent presque toujours. Le tableau donne, pour chacun, le choix de départ raisonnable et la fiche où l'approfondir ; ce n'est pas un verdict, mais un point d'entrée que vous ajusterez avec vos contraintes.
| Votre besoin | Choix de départ | Fiche |
|---|---|---|
| Je débute, je veux une pile simple | Grafana + Prometheus + Loki, le trio éprouvé ; ajoutez Tempo si vous avez besoin de traces | Prometheus, Grafana, Loki |
| Je veux corréler logs, métriques et traces | OpenTelemetry unifie l'instrumentation ; le Collector sert de point central, puis route vers vos backends | OpenTelemetry Collector, corrélation |
| Je déploie sur Kubernetes | kube-state-metrics et node-exporter pour les métriques du cluster ; Grafana Alloy ou le Collector OTel pour les logs ; Tempo pour les traces | Observer Kubernetes, Inspektor Gadget |
| Je veux centraliser mes logs | Loki si vous utilisez déjà Grafana (léger, indexé par labels) ; OpenSearch (ex-ELK) pour le full-text avancé et les cas de conformité | Loki, Fluent Bit, Vector |
| Je veux du monitoring synthétique | Uptime Kuma pour les checks simples, auto-hébergé ; k6 pour les tests de charge et les scénarios complexes | Uptime Kuma, HertzBeat |
| Je veux gérer les astreintes | Alertmanager si vous êtes tout Prometheus ; un service d'astreinte dédié, comme PagerDuty, dès qu'il faut des escalades et des calendriers | Alertmanager, lab alerting |
Où trouver le détail de chaque fonction ?
Section intitulée « Où trouver le détail de chaque fonction ? »Trois fonctions ont une page qui compare les outils de leur catégorie ; les autres mènent directement aux fiches d'outil. Côté production des signaux, Instrumentation couvre les SDK et bibliothèques qui les génèrent dans vos applications, et Collecte et pipeline les agents et collecteurs qui les agrègent, les transforment et les routent.
Côté stockage, Métriques compare les bases de séries temporelles (TSDB), Loki stocke les journaux par labels, et trois backends gardent les traces distribuées : Tempo, Jaeger et Zipkin. Pour acheminer les logs, Fluent Bit, Fluentd, Vector et rsyslog ont chacun leur fiche.
Côté usage, Grafana construit les dashboards, Alertmanager route et regroupe les alertes, et Uptime Kuma, HertzBeat et Maintenant surveillent la disponibilité depuis l'extérieur.
Pour les astreintes, deux services ont quitté le marché : Grafana OnCall OSS, archivé le 24 mars 2026 au profit de Grafana Cloud IRM, et Opsgenie, qu'Atlassian ne vend plus depuis le 4 juin 2025 et dont le support s'arrête le 5 avril 2027. Sur Kubernetes, Inspektor Gadget observe les nœuds par eBPF.
Ces fiches disent quoi utiliser. Pour savoir comment bien l'utiliser, les fondamentaux de l'observabilité posent les concepts (signaux, SLI et SLO, méthodes RED et USE, corrélation) et les pratiques opérationnelles montrent comment concevoir des dashboards, des alertes et une observation de Kubernetes qui servent.
À retenir
Section intitulée « À retenir »- Choisissez vos outils par fonction dans le pipeline, pas par popularité
- Commencez simple (Prometheus + Grafana + Loki) puis ajoutez selon vos besoins
- L'instrumentation (OTel) est le fondement : sans données de qualité, les meilleurs outils sont inutiles
- Un collecteur central (OTel Collector, Vector) simplifie la gestion à grande échelle