Grafana dans le stack LGTM
Grafana ne stocke rien — il interroge, corrèle et affiche les données de tes backends.
Grafana n'est pas une base de données. C'est une interface de visualisation qui se connecte aux sources de données existantes pour transformer des chiffres bruts en tableaux de bord lisibles. La donnée reste dans les backends — Grafana se contente de l'interroger et de l'afficher.
Il reçoit une requête (PromQL, LogQL, SQL…), l'envoie au backend concerné, reçoit les séries temporelles ou les lignes de log, et les rend dans un panel. Zéro stockage propre (hors état interne : dashboards, utilisateurs, alertes).
Dans le stack LGTM, chaque outil a une spécialité précise :
| Outil | Spécialité | Langage de requête |
|---|---|---|
| Loki | Logs (index léger par labels) | LogQL |
| Grafana | Visualisation unifiée | — |
| Tempo | Traces distribuées | TraceQL |
| Mimir / Prometheus | Métriques en séries temporelles | PromQL |
Grafana agit comme un hub d'observabilité : tu configures une datasource par backend, et tous les dashboards partagent ces connexions. Si tu migres Prometheus vers une nouvelle instance, tu touches un seul endroit — tous les dashboards suivent.
L'interface se découpe en quatre espaces principaux :
- Dashboards : panels sauvegardés, partageables, avec variables de template
- Explore : requêtes ad-hoc pour investiguer sans sauvegarder
- Alerting : règles centralisées, indépendantes des dashboards
- Connections : configuration des datasources et des plugins
Trois types de panels mis à jour en direct — time series, stat et gauge. En production, chaque panel configure sa propre fréquence de rafraîchissement (de 1 s à 1 h).
Les datasources — Grafana ne stocke rien
Chaque backend a son plugin. Un seul changement de configuration propage à tous les dashboards.
Une datasource est un connecteur nommé vers un backend de données. Grafana ne parle pas directement à Prometheus ou à PostgreSQL — c'est le plugin datasource qui fait la traduction : il expose un éditeur de requêtes adapté et envoie les appels HTTP au bon format.
Chaque type (Prometheus, Loki, Tempo, PostgreSQL, Elasticsearch…) est un plugin qui implémente deux interfaces : un éditeur de requête et un runner. Grafana en embarque une vingtaine en core ; des centaines existent en communauté.
La configuration est minimale : une URL, une méthode d'authentification (token Bearer, basic auth, TLS client cert), et quelques options propres au type. Une fois configurée, la datasource est disponible pour tous les dashboards et toutes les règles d'alerte.
/etc/grafana/provisioning/datasources/lgtm.yaml. Elles sont versionnées, reproductibles, et apparaissent automatiquement au démarrage — sans passer par l'UI.
Sélectionne une datasource pour voir son langage de requête et un exemple.
Un seul changement d'URL dans la datasource Prometheus met à jour l'ensemble des dashboards qui l'utilisent. Ce découplage est ce qui rend Grafana maintenable à grande échelle.
Un panel peut utiliser la datasource "Mixed" : chaque requête du panel cible une datasource différente. Utile pour superposer des métriques Prometheus et des annotations depuis une base SQL sur le même graphique.
Dashboards et panels
Un dashboard = une grille de panels. Un panel = une requête + un type de visualisation.
Un dashboard est un ensemble de panels sauvegardés dans Grafana. Chaque panel est une visualisation autonome — il a sa propre requête, son propre type d'affichage, ses propres seuils. Le dashboard les organise en grille, avec une plage de temps et une fréquence de rafraîchissement communes.
Unité de base d'un dashboard. Un panel = une datasource + une requête + un type de visualisation + des options d'affichage (couleurs, seuils, légendes). Un dashboard peut en contenir de 1 à plusieurs dizaines.
La plage de temps est l'un des concepts les plus puissants : tu peux explorer le passé (hier, il y a 7 jours, avant un incident) ou regarder les données en temps réel avec un rafraîchissement automatique. Tous les panels du dashboard respectent cette plage — c'est ce qui permet la corrélation visuelle entre métriques, logs et traces.
Sept types de panels disponibles en core. Sélectionne-en un pour voir sa description et son cas d'usage typique.
/etc/grafana/provisioning/dashboards/.
Les dashboards peuvent être organisés en dossiers (par équipe, par environnement, par service) et les permissions d'accès se configurent au niveau du dossier. Une bonne nomenclature dès le départ évite le "dashboard sprawl" — la prolifération de copies non maintenues.
Variables de template — des dashboards dynamiques
Remplace les dashboards dupliqués par une seule variable $service — Grafana fait le reste.
Les variables de template transforment un dashboard statique en un dashboard dynamique. Au lieu de dupliquer un dashboard pour chaque service, tu paramétres les requêtes avec une variable $service et tu choisis la valeur depuis un menu déroulant en haut du dashboard.
Une variable est un placeholder dont la valeur est choisie à l'exécution. Dans une requête PromQL,
$service est remplacé par la valeur sélectionnée avant l'envoi au backend. Grafana rafraîchit automatiquement tous les panels concernés.
Exemple : au lieu d'un dashboard dédié à api-gateway et d'un autre pour auth-service, tu écris une seule requête :
rate(http_requests_total{service="$service", status=~"5.."}[5m])Il existe quatre types de variables :
| Type | Source des valeurs | Exemple |
|---|---|---|
| Query | Requête vers une datasource | Labels Prometheus label_values(up, job) |
| Custom | Liste fixe saisie manuellement | prod,staging,dev |
| Constant | Valeur fixe, non affichée | Préfixe métrique commun |
| Interval | Fenêtre de temps | $__rate_interval pour PromQL |
Tu peux chaîner les variables : la variable
$namespace filtre ses valeurs selon $cluster, et $pod filtre selon $namespace. Chaque sélection raffine automatiquement les choix suivants.
Sélectionne un service — la variable $service est injectée dans la requête PromQL.
Alerting — être notifié avant tes utilisateurs
Le paramètre `for` évite les faux positifs. La machine à états NORMAL→PENDING→FIRING→RESOLVED est la clé.
Grafana Alerting (unifié depuis Grafana 8) centralise toutes les règles d'alerte dans une seule interface, indépendamment des dashboards. Tu peux créer une alerte sur n'importe quelle datasource, la tester en direct avec Explore, et la lier à un contact point pour les notifications.
Une règle d'alerte définit : une requête (ce qu'on mesure), une condition (le seuil de déclenchement), une période d'évaluation (toutes les X secondes) et un paramètre
for (combien de temps la condition doit rester vraie avant de déclencher).
Le paramètre for est fondamental. Sans lui, une métrique qui dépasse brièvement un seuil — spike de 2 secondes — déclencherait une alerte et créerait du bruit. Avec for: 5m, la condition doit rester vraie pendant 5 minutes avant de passer en état FIRING.
La machine à états d'une alerte :
Simulation automatique : la métrique fluctue, franchit le seuil, attend la période for, déclenche, puis se résout.
Les contact points définissent où envoyer les notifications (Slack, PagerDuty, email, webhook…). La notification policy est une arborescence de règles qui fait correspondre les labels d'une alerte (severity=critical, team=backend) au bon contact point. Ce découplage permet une gestion centralisée des escalades sans modifier les règles elles-mêmes.
Explore et corrélations — enquêter sans dashboard
Métrique → logs → trace en trois clics. C'est ce qui réduit le MTTR.
Explore est le mode investigation de Grafana : tu lances des requêtes ad-hoc sans créer de dashboard ni sauvegarder quoi que ce soit. C'est l'équivalent d'un terminal pour tes données — rapide, direct, éphémère.
Accessible depuis le menu latéral, Explore affiche un éditeur de requête pour la datasource de ton choix. Il supporte le split view : deux datasources côte à côte, idéal pour comparer métriques et logs sur la même plage de temps.
L'usage le plus puissant d'Explore est la corrélation. Quand une métrique montre un pic, tu passes instantanément aux logs correspondants. Quand un log contient un trace_id, tu l'ouvres directement dans Tempo. Ce workflow de "sauter d'un signal à l'autre" est la clé pour réduire le temps de diagnostic (MTTR).
Tu peux configurer Loki pour extraire automatiquement un
trace_id depuis les logs via une regex, et créer un lien cliquable vers Tempo. La corrélation devient alors un simple clic sans configuration manuelle à chaque fois.
Simulation du workflow de corrélation : clique sur le pic de métriques → apparition des logs → clique sur un trace_id → apparition de la trace.
Synthèse — le stack LGTM au complet
Métriques, logs, traces — trois signaux, une interface. La corrélation est la valeur ajoutée.
Grafana est le point d'entrée unifié du stack LGTM. Plutôt que d'alterner entre une UI Prometheus, un viewer Loki et un explorateur Tempo, tu as une seule interface pour interroger les trois, construire des dashboards et recevoir les alertes.
| Signal | Stocké dans | Requêté via | Panel typique |
|---|---|---|---|
| Métriques | Prometheus / Mimir | PromQL | Time series, Stat, Gauge |
| Logs | Loki | LogQL | Logs panel |
| Traces | Tempo | TraceQL | Traces panel |
Méthodes RED et USE dans Grafana
Deux méthodes structurent la construction des dashboards :
- Rate — requêtes par seconde
- Errors — taux d'erreur
- Duration — latence (P50/P95/P99)
- Utilisation — % d'occupation
- Saturation — file d'attente / backlog
- Erreurs — erreurs de la ressource
Un dashboard de service typique combine RED pour la vue externe (est-ce que les utilisateurs souffrent ?) et USE pour la vue interne (pourquoi ?). Les variables de template ($service, $env) rendent ce dashboard réutilisable pour toute la flotte.
- Exposer les métriques RED via l'instrumentation (OpenTelemetry / Prometheus client)
- Configurer Promtail / OpenTelemetry Collector pour envoyer les logs à Loki avec les bons labels (
service,env) - Instrumenter les traces et les envoyer à Tempo via OTLP
- Ajouter les champs dérivés Loki pour lier
trace_id→ Tempo - Créer ou réutiliser un dashboard avec les variables
$serviceet$env - Définir les règles d'alerte sur les SLOs (ex: error rate > 1% pendant 5 min)
Niveau 1 : logs applicatifs structurés. Niveau 2 : métriques RED + dashboards. Niveau 3 : traces distribuées + corrélation automatique. La corrélation Grafana devient vraiment puissante au niveau 3, quand les trois signaux partagent les mêmes labels (
service, trace_id, env).
Le stack LGTM n'est pas une fin en soi — c'est l'infrastructure qui te permet de poser les questions importantes pendant un incident, sans chercher dans quelle interface regarder. La valeur est dans la corrélation instantanée, pas dans les outils pris séparément.