Dashboards utiles : concevoir des tableaux de bord qui servent au diagnostic

Un dashboard utile répond à une question en moins de 5 secondes. Pourtant, la plupart des dashboards qu'on rencontre dans les organisations sont des murs de graphes : 40 panneaux, pas de hiérarchie, pas de contexte, ouverts une fois puis oubliés. Le problème n'est pas l'outil, c'est l'absence de méthode. Ce guide vous apprend à construire des dashboards structurés autour de deux frameworks éprouvés (RED pour les services, USE pour l'infrastructure) et à éviter les erreurs qui transforment un outil de diagnostic en source de bruit.

TL;DR

Un bon dashboard = une audience + une question + 5 à 10 panneaux maximum. Utilisez la méthode RED (Rate, Errors, Duration) pour les dashboards service et la méthode USE (Utilization, Saturation, Errors) pour l'infrastructure. Ajoutez des annotations pour superposer les déploiements et les incidents. Pré-calculez vos requêtes coûteuses avec des recording rules. Tout le reste est du bruit.

Ce que vous allez apprendre

• La philosophie : pourquoi la plupart des dashboards échouent et ce qui fait la différence
• Le dashboard service (RED) : les panneaux essentiels pour une API ou un microservice, avec les requêtes PromQL prod-safe
• Le dashboard infrastructure (USE) : CPU, mémoire, disque, réseau, organisés pour le diagnostic, avec des filtres adaptés à Kubernetes
• Le dashboard overview : la vue d'ensemble qui relie services et infra
• Le dashboard SLO : les 3 panneaux pour suivre vos objectifs métier
• Les recording rules : pré-calculer les requêtes pour accélérer vos dashboards et réduire la charge
• Les annotations : comment superposer déploiements et incidents sur vos graphes pour corréler cause et effet
• Les variables et la navigation : templates Grafana pour un dashboard réutilisable
• Les conventions : nommage, unités, seuils, la charte qui évite l'effet "un dashboard différent par équipe"
• Les anti-patterns : les erreurs classiques qui rendent un dashboard inutile, et comment les corriger

Pourquoi la plupart des dashboards sont inutiles

Un dashboard mal conçu a trois symptômes caractéristiques :

1. Personne ne l'ouvre, il a été créé "au cas où", sans audience définie
2. Tout le monde le regarde mais personne ne comprend, trop de panneaux, pas de hiérarchie, pas de contexte
3. Il ralentit le diagnostic, au lieu de guider l'investigation, il noie l'opérateur sous les données

La cause est toujours la même : le dashboard a été construit par addition (on ajoute des panneaux quand on y pense) au lieu d'être construit par soustraction (on ne garde que ce qui répond à une question précise).

La règle des trois questions

Avant de créer ou refondre un dashboard, répondez à ces trois questions :

1. Qui va le consulter ? Un développeur, un SRE, un manager ?
2. Quelle question essaie-t-il de résoudre ? "Mon service est-il dégradé ?" ou "Ai-je assez de CPU pour absorber le trafic de demain ?"
3. Quelle action peut-il déclencher ? Si la réponse est "aucune", le dashboard ne sert à rien

Un dashboard doit mener à une décision : scaler, rollback, investiguer les logs, créer un ticket, ou constater que tout va bien.

Dashboard de diagnostic vs dashboard de reporting

Deux usages, deux designs différents. Un dashboard de diagnostic est consulté en temps réel pendant un incident : fenêtre courte (1 h–6 h), drill-down, contexte riche (annotations, logs). Un dashboard de reporting est consulté en comité hebdomadaire ou mensuel : tendance longue (7–30 j), données agrégées (downsampled), graphes de synthèse. Ne mélangez pas les deux dans le même dashboard, vous aurez un outil qui ne sert ni pour l'un ni pour l'autre.

Niveaux de maturité Grafana

La documentation Grafana identifie quatre niveaux de maturité pour la gestion des dashboards : (1) dashboards ad hoc par personne, (2) dashboards partagés par équipe, (3) dashboards méthodiques selon une stratégie d'observabilité, (4) dashboards optimisés avec templating, variables et conventions. Ce guide vous amène directement au niveau 3. Pour l'installation et la prise en main de l'outil, voir le guide Grafana.

Le dashboard service (méthode RED)

La méthode RED (Rate, Errors, Duration) a été formalisée par Tom Wilkie (Grafana) pour les services orientés requêtes : APIs, microservices, workers. Elle se concentre sur l'expérience vue par l'appelant, pas sur la santé interne du serveur.

Les trois panneaux essentiels

Ces trois indicateurs ne se lisent jamais isolément, c'est leur combinaison qui porte le diagnostic. Une chute du Rate sans hausse des Errors signale un problème en amont, chez l'appelant ou dans le routage, pas dans votre service. À l'inverse, une Duration qui grimpe pendant que le Rate reste stable indique une dépendance lente, base de données ou API tierce. Le pire cas est la combinaison Rate qui chute et Errors qui explose : le service refuse du trafic.

Panneau	Question	Ce qu'il montre
Rate	"Combien de requêtes mon service traite-t-il ?"	Débit (req/s), ventilé par endpoint si utile
Errors	"Quelle proportion de requêtes échoue ?"	Taux d'erreur (%), codes 5xx, exceptions
Duration	"Combien de temps prend une requête ?"	Latence p50, p90, p99

Glissez pour voir

Requêtes PromQL pour un dashboard RED

Le point de départ est la métrique http_requests_total (ou équivalent dans votre instrumentation). Voici les requêtes pour un service nommé payment-api. Toutes utilisent $__rate_interval au lieu d'un intervalle fixe, Grafana ajuste automatiquement cet intervalle au pas de temps du dashboard.

Rate, requêtes par seconde :

sum(rate(http_requests_total{service="$service"}[$__rate_interval]))

Cette requête calcule le nombre moyen de requêtes par seconde. Utilisez sum by (method) pour ventiler par méthode HTTP (GET, POST, etc.).

Error rate, pourcentage d'erreurs :

sum(rate(http_requests_total{service="$service", status=~"5.."}[$__rate_interval]))
/
sum(rate(http_requests_total{service="$service"}[$__rate_interval]))
* 100

Le status=~"5.." est une expression régulière qui capture tous les codes HTTP 5xx. Le résultat est un pourcentage : 0.5 = 0.5 % d'erreurs.

Duration, latence par percentile (global) :

histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{service="$service"}[$__rate_interval]))
  by (le)
)

Cette requête exploite un histogram pour calculer le 99e percentile (p99) de la latence. Le le (less than or equal) est le label interne des buckets d'histogram dans Prometheus. Pour afficher p50 et p90 sur le même graphe, ajoutez des requêtes identiques avec 0.50 et 0.90.

p99 global ≠ p99 par endpoint

La requête ci-dessus calcule le p99 global du service, elle mélange toutes les routes. Si un endpoint /healthz répond en 1 ms et un endpoint /search en 500 ms, le p99 global sera entre les deux et ne reflétera aucune réalité utilisateur. Pour un diagnostic fin, affichez le p99 par route (si vos métriques portent un label route ou path normalisé) :

topk(5,
  histogram_quantile(0.99,
    sum by (le, route) (
      rate(http_request_duration_seconds_bucket{service="$service"}[$__rate_interval])
    )
  )
)

Ce panneau "Top 5 routes les plus lentes" est un excellent complément au p99 global.

Pourquoi les percentiles et pas la moyenne ?

La moyenne masque les problèmes. Si 99 requêtes prennent 10 ms et une requête prend 10 s, la moyenne est de 110 ms, ce qui semble acceptable. Le p99 (10 s) révèle que certains utilisateurs vivent une expérience dégradée. Affichez toujours p50 (la médiane, l'expérience typique) et p99 (le pire cas réaliste).

Organisation du dashboard service

Un dashboard RED complet pour un service contient 5 à 8 panneaux, pas plus :

Position	Panneau	Type de visualisation
Ligne 1 (statuts)	Taux de requêtes (req/s)	Stat (grand chiffre)
Ligne 1	Taux d'erreur (%)	Stat (grand chiffre, rouge si > seuil)
Ligne 1	Latence p99	Stat (grand chiffre)
Ligne 2 (tendances)	Rate dans le temps	Time series (graphe)
Ligne 2	Error rate dans le temps	Time series (graphe)
Ligne 3 (détails)	Latence p50 / p90 / p99	Time series (3 courbes)
Ligne 3	Top 5 endpoints les plus lents	Table
Ligne 4 (contexte)	Logs récents (erreurs)	Logs panel (Loki)

Glissez pour voir

La première ligne donne la réponse immédiate : vert = tout va bien, rouge = quelque chose ne va pas. Les lignes suivantes permettent d'investiguer.

Un dashboard par service

Évitez les dashboards "tous les services". Chaque service a ses propres seuils, ses propres endpoints critiques, ses propres patterns de trafic. Un dashboard par service, avec une variable $service pour la navigation, est plus utile qu'un dashboard unique illisible.

Le dashboard infrastructure (méthode USE)

La méthode USE (Utilization, Saturation, Errors) a été créée par Brendan Gregg pour diagnostiquer les problèmes de performance des ressources matérielles : CPU, mémoire, disque, réseau.

Les quatre ressources à surveiller

La colonne qui déclenche l'action est Saturation, pas Utilization. Une ressource utilisée à 95 % sans file d'attente fonctionne parfaitement ; la même ressource à 60 % avec une file d'attente qui s'allonge est déjà en souffrance. C'est particulièrement vrai pour le disque, où la latence des entrées-sorties révèle un problème bien avant que le taux d'occupation ne bouge. Lisez donc chaque ligne de gauche à droite, mais alertez sur la colonne du milieu.

Ressource	Utilization	Saturation	Errors
CPU	% de temps CPU occupé	Load average / run queue	sans objet
Mémoire	% de RAM utilisée	Pages swappées / OOM kills	ECC errors (rare)
Disque	% d'espace utilisé, IOPS	I/O queue depth, latence I/O	Erreurs disque (SMART)
Réseau	Bande passante utilisée (%)	Paquets droppés, retransmissions TCP	Erreurs d'interface

Glissez pour voir

Requêtes PromQL pour un dashboard USE

Ces requêtes utilisent les métriques exportées par node_exporter (Prometheus). Toutes les requêtes retournent un ratio entre 0 et 1, dans Grafana, configurez l'unité du panneau en "Percent (0.0-1.0)" pour afficher le résultat en pourcentage lisible.

CPU, utilisation (ratio 0..1) :

1 - avg by (instance) (
  rate(node_cpu_seconds_total{mode="idle", instance=~"$instance"}[$__rate_interval])
)

node_cpu_seconds_total est un counter qui cumule les secondes CPU par mode (idle, user, system, etc.). rate() le transforme en ratio par seconde. On soustrait le mode idle de 1 pour obtenir l'utilisation.

Mémoire, utilisation (ratio 0..1) :

1 - (
  node_memory_MemAvailable_bytes{instance=~"$instance"}
  / node_memory_MemTotal_bytes{instance=~"$instance"}
)

MemAvailable (et non MemFree) est la bonne métrique car elle inclut les buffers et le cache récupérables par le système.

Disque, espace utilisé (ratio 0..1, filtré pour Kubernetes) :

1 - (
  node_filesystem_avail_bytes{mountpoint="/", fstype!~"tmpfs|overlay|squashfs"}
  /
  node_filesystem_size_bytes{mountpoint="/", fstype!~"tmpfs|overlay|squashfs"}
)

Le filtre fstype!~"tmpfs|overlay|squashfs" exclut les systèmes de fichiers virtuels, indispensable sur Kubernetes où overlay (layers de conteneurs), tmpfs (emptyDir) et squashfs (snaps) polluent les graphes. Un seuil d'alerte classique est 85 % d'utilisation.

Réseau, trafic entrant (bits/s, interfaces réelles) :

sum by (instance) (
  rate(node_network_receive_bytes_total{device!~"lo|veth.*|cni.*|docker.*|br-.*", instance=~"$instance"}[$__rate_interval])
) * 8

Le * 8 convertit les octets en bits (pour afficher en Mbps). Le filtre device!~"lo|veth.*|cni.*|docker.*|br-.*" exclut le loopback et les interfaces virtuelles (veth de conteneurs, bridges Docker, interfaces CNI). Le nom de l'interface physique varie (eth0, ens3, enp0s3…), un filtre d'exclusion est plus robuste qu'un filtre d'inclusion.

Adaptez les filtres à votre environnement

Les filtres fstype et device ci-dessus conviennent à la majorité des environnements. Sur un cluster avec Calico, ajoutez cali.* à l'exclusion réseau. Sur un nœud avec du bonding, ajoutez bond.* à l'inclusion. Testez vos filtres avec node_filesystem_size_bytes et node_network_info dans l'explorer Grafana avant de les finaliser.

Organisation du dashboard infrastructure

Cette disposition suit le trajet d'un diagnostic réel : on regarde d'abord si une ressource est contrainte, puis on descend vers le sous-système concerné. Notez que la saturation est reléguée en ligne 4 alors qu'elle est le signal le plus important. Ce n'est pas une contradiction : le load average et le swap ne servent qu'à confirmer un soupçon né des trois premières lignes, les consulter en premier ne dit pas quelle ressource regarder ensuite.

Position	Panneau	Type
Ligne 1 (vue d'ensemble)	CPU utilisation par nœud	Time series
Ligne 1	Mémoire disponible par nœud	Time series
Ligne 2 (stockage)	Espace disque (%) par mount	Gauge ou Bar gauge
Ligne 2	IOPS lecture/écriture	Time series
Ligne 3 (réseau)	Trafic réseau in/out	Time series
Ligne 3	Erreurs réseau / drops	Time series
Ligne 4 (saturation)	Load average (1m, 5m, 15m)	Time series
Ligne 4	Swap utilisé	Stat

Glissez pour voir

CPU à 90 % ≠ problème

Un CPU à 90 % d'utilisation n'est pas forcément un problème, c'est peut-être simplement une bonne utilisation de vos ressources. Ce qui compte, c'est la saturation : si le load average dépasse le nombre de cœurs CPU, des processus attendent leur tour et les performances se dégradent. Affichez toujours utilisation et saturation côte à côte.

Le dashboard overview

Au-dessus des dashboards service et infra, créez un dashboard overview, la page d'accueil que le SRE ouvre en premier quand une alerte se déclenche.

Ce qu'il contient

Les quatre premiers panneaux répondent à « quoi », le cinquième répond à « pourquoi maintenant ». C'est ce dernier qui fait gagner le plus de temps en incident : une dégradation qui démarre trois minutes après un déploiement change complètement la conduite à tenir, et la question du rollback se pose immédiatement au lieu d'être envisagée après vingt minutes d'investigation.

Panneau	Source	Objectif
Statut des services (vert/rouge)	Taux d'erreur par service	Identifier quel service est impacté
Error rate global	Somme des erreurs tous services	Voir la tendance générale
Latence p99 par service	Histograms agrégés	Comparer les services entre eux
Alertes actives	Alertmanager API	Voir les alertes en cours sans quitter le dashboard
Annotations : derniers déploiements	CI/CD → Grafana API	Corréler un déploiement récent avec une dégradation

Glissez pour voir

Ce dashboard ne doit jamais dépasser 10 panneaux. Son rôle est de diriger vers le bon dashboard service ou infra, pas de tout montrer.

Navigation par drill-down

Le workflow de diagnostic suit une logique descendante :

Overview (quel service ?)
    → Dashboard service RED (quel symptôme ?)
        → Dashboard infra USE (quelle ressource ?)
            → Logs / Traces (quelle requête, quel span ?)

Dans Grafana, utilisez les data links pour connecter les panneaux entre eux : un clic sur un service dans l'overview ouvre son dashboard RED. Un clic sur un nœud dans le dashboard RED ouvre le dashboard infra USE filtré sur ce nœud.

Data links dans Grafana

Pour créer un drill-down, ajoutez un data link sur un panneau : Panel → Edit → Data links → Add. L'URL utilise les variables Grafana : /d/service-red?var-service=${__field.labels.service}. Le lecteur clique sur un graphe et arrive directement sur le dashboard détaillé, préfiltré.

Le dashboard SLO

Si vous avez défini des SLO (Service Level Objectives), un dashboard dédié donne la vision métier de votre fiabilité. Ce n'est pas un remplacement du dashboard RED, c'est la vue que le product owner et le management consultent pour savoir si le service tient ses promesses.

Les trois panneaux essentiels

Panneau	Requête PromQL (exemple)	Ce qu'il montre
Disponibilité (% succès sur 30 j)	sum(rate(http_requests_total{service="$service", status!~"5.."}[$__rate_interval])) / sum(rate(http_requests_total{service="$service"}[$__rate_interval]))	Ratio de requêtes réussies, comparer au SLO (ex: 99.9 %)
Latence SLO (% < seuil)	sum(rate(http_request_duration_seconds_bucket{service="$service", le="0.3"}[$__rate_interval])) / sum(rate(http_request_duration_seconds_count{service="$service"}[$__rate_interval]))	% de requêtes sous 300 ms, comparer au SLO (ex: 95 %)
Budget d'erreur restant	Calcul basé sur le burn rate (voir guide Alerting)	Budget consommé depuis le début de la fenêtre SLO

Glissez pour voir

Le panneau de budget d'erreur est le plus puissant : il répond à la question "peut-on déployer une fonctionnalité risquée, ou sommes-nous déjà en zone rouge?". Les détails sur le burn rate et le multi-window alerting sont couverts dans le guide dédié à l'alerting.

Fenêtre glissante, pas calendaire

Un SLO de 99.9 % sur 30 jours doit être calculé sur une fenêtre glissante (les 30 derniers jours en continu), pas sur un mois calendaire. Sinon, le budget se "remet à zéro" le 1er du mois et les incidents de fin de mois sont amnistiés.

Recording rules : accélérer vos dashboards

Quand un dashboard contient des panneaux avec des requêtes PromQL complexes (agrégations multi-dimensions, histogram_quantile, rate sur des millions de séries), chaque ouverture du dashboard exécute ces requêtes en temps réel sur Prometheus. Résultat : dashboards lents, charge élevée sur la datasource, et timeout quand la fenêtre de temps est longue.

Le principe

Les recording rules pré-calculent le résultat d'une requête à intervalle régulier et stockent le résultat comme une nouvelle métrique. Le dashboard interroge cette métrique pré-calculée au lieu de recalculer à chaque affichage.

Exemple concret

Au lieu que chaque ouverture du dashboard RED recalcule le taux d'erreur :

prometheus/rules/recording-rules.yaml

groups:
  - name: red_dashboard_rules
    interval: 30s
    rules:
      - record: service:http_requests:rate5m
        expr: sum by (service) (rate(http_requests_total[5m]))

      - record: service:http_errors:ratio_rate5m
        expr: |
          sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum by (service) (rate(http_requests_total[5m]))

      - record: service:http_request_duration_seconds:p99
        expr: |
          histogram_quantile(0.99,
            sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
          )

Dans le dashboard, remplacez la requête PromQL complexe par le nom de la recording rule :

service:http_errors:ratio_rate5m{service="$service"}

Quand utiliser des recording rules

Le critère commun à ces cinq lignes est le coût de recalcul multiplié par la fréquence d'accès. Une recording rule n'est pas gratuite : elle s'exécute à intervalle fixe même quand personne ne consulte le dashboard, et elle crée de nouvelles séries qui occupent de la place dans la base. Elle devient rentable dès que le calcul est lourd ou que plusieurs consommateurs, dashboards et règles d'alerte confondus, l'exécutent en parallèle.

Situation	Recording rule utile ?
Dashboard consulté par 1-2 personnes, fenêtre courte	Non, overhead inutile
Dashboard consulté par 10+ personnes en parallèle	Oui, réduit la charge
Requête avec histogram_quantile sur 30+ services	Oui, le calcul est coûteux
Alerting basé sur la même requête qu'un dashboard	Oui, cohérence et performance
Requête simple (rate sur 1 série)	Non, pas de gain

Glissez pour voir

Dashboards = lecture, alerting = règles

Le principe fondamental : ne jamais alerter depuis un dashboard (via l'interface Grafana). Les alertes doivent être définies comme des rules Prometheus (ou des recording rules consommées par Alertmanager). Cela garantit que les alertes fonctionnent même quand Grafana est en panne, et qu'elles sont versionnées dans Git comme le reste de votre infrastructure.

Les annotations : superposer le contexte

Un graphe de latence qui monte ne dit rien de la cause. Une annotation qui montre qu'un déploiement a eu lieu 2 minutes avant donne immédiatement le suspect n°1.

Types d'annotations utiles

Ces quatre sources partagent une caractéristique : ce sont des changements décidés par un humain ou par un automatisme, donc des causes plausibles. C'est ce qui les distingue d'une simple métrique supplémentaire. Commencez par les déploiements, qui expliquent à eux seuls une large part des dégradations soudaines, et n'ajoutez les autres que si vous constatez un besoin réel de corrélation. Trop d'annotations rendent le graphe illisible et annulent le bénéfice.

Annotation	Source	Valeur
Déploiement	CI/CD (GitLab, ArgoCD, Flux)	"Est-ce que le déploiement de 14h32 a causé la régression ?"
Incident	PagerDuty, Opsgenie, Grafana OnCall	"Cet incident est-il corrélé au pic de latence ?"
Scaling	HPA Kubernetes, Auto Scaling Group	"Le scaling a-t-il résolu le problème ou l'a-t-il causé ?"
Changement de config	Git webhook, ConfigMap update	"Qui a modifié la config à 16h05 ?"

Glissez pour voir

Comment envoyer une annotation depuis la CI/CD

Grafana expose une API HTTP pour créer des annotations. Pour créer une annotation globale (visible sur tous les dashboards), omettez le champ dashboardUID et utilisez des tags pour le filtrage :

# .gitlab-ci.yml : stage deploy
deploy:
  stage: deploy
  script:
    - ./deploy.sh
    - |
      curl -s -X POST "${GRAFANA_URL}/api/annotations" \
        -H "Authorization: Bearer ${GRAFANA_API_KEY}" \
        -H "Content-Type: application/json" \
        -d '{
          "text": "Deploy '"${CI_PROJECT_NAME}"' v'"${CI_COMMIT_TAG}"'",
          "tags": ["deploy", "'"${CI_ENVIRONMENT_NAME}"'", "'"${CI_PROJECT_NAME}"'"]
        }'

En omettant dashboardUID, l'annotation est globale, elle apparaît dans tous les dashboards qui ont activé le filtre par tags correspondant. Pour cibler un dashboard spécifique, ajoutez "dashboardUID": "abc123".

Dans Grafana, activez l'affichage des annotations : Dashboard Settings → Annotations → Add → Grafana → Filter by Tags → deploy. Chaque dashboard peut choisir quels tags il affiche.

Sécurité du token Grafana

Le token API Grafana (GRAFANA_API_KEY) doit être stocké dans les variables CI protégées, jamais en clair dans le fichier. Créez un service account dédié aux annotations avec les permissions minimales, au minimum le rôle Editor sur le dossier ou l'organisation concernée (la création d'annotations requiert des droits d'édition, pas seulement de lecture). Ne lui donnez pas le rôle Admin.

Variables et templating

Les variables Grafana rendent un dashboard réutilisable sans duplication. Au lieu de créer un dashboard par service ou par nœud, vous créez un seul dashboard avec des sélecteurs.

Variables essentielles

L'ordre de ce tableau est aussi l'ordre de déclaration recommandé dans Grafana, car chaque variable peut filtrer la suivante. La ligne $instance en donne l'illustration : sa requête référence $namespace, ce qui réduit la liste proposée aux seules instances pertinentes. Sans cette dépendance en cascade, un cluster de taille moyenne remplit le menu déroulant de plusieurs centaines d'entrées inutilisables.

Variable	Type	Requête	Usage
$datasource	Data source	sans requête	Permet de basculer entre clusters/environnements
$service	Query	label_values(http_requests_total, service)	Filtre par service
$namespace	Query	label_values(kube_pod_info, namespace)	Filtre par namespace Kubernetes
$instance	Query	label_values(node_cpu_seconds_total{namespace="$namespace"}, instance)	Filtre par nœud, scopé au namespace

Glissez pour voir

Bonnes pratiques de templating

Ces cinq règles répondent au même risque : une variable mal bornée transforme un dashboard en générateur de charge sur la datasource. Le point le plus coûteux est le troisième, une variable non limitée provoque à chaque ouverture une requête label_values sur l'ensemble des séries, qui peut peser plus lourd que tous les panneaux réunis.

• Ajoutez un filtre All : cochez "Include All option" pour voir tous les services d'un coup, mais par défaut, sélectionnez un seul service pour éviter de surcharger le dashboard
• Limitez la portée : une variable $instance sans filtre charge toutes les instances du cluster, ajoutez un filtre namespace en amont pour limiter
• Limitez le nombre de valeurs : si une variable retourne 5 000 services, le dropdown devient inutilisable et le dashboard se bloque. Ajoutez un filtre regex dans la définition de la variable ou un limit dans la requête pour cap à 100-200 valeurs max
• Utilisez $__rate_interval : dans toutes vos rate(), préférez [$__rate_interval] à un intervalle fixe comme [5m]. Cette variable s'ajuste automatiquement au pas de temps du dashboard
• Ordonnez les variables : datasource → namespace → service → instance, du plus large au plus spécifique

$__rate_interval vs [5m] vs irate

$__rate_interval s'ajuste automatiquement : sur une fenêtre de 1 h il vaut ~15 s, sur 7 jours il vaut plusieurs minutes. Vous évitez les artefacts (graphe en escalier ou trop lissé). Si vous utilisez irate() (taux instantané entre les 2 derniers samples), gardez un intervalle court, irate ne se comporte pas bien avec un intervalle large. Réservez irate aux dashboards de diagnostic temps réel (fenêtre < 1 h).

Conventions pour des dashboards cohérents

Quand plusieurs équipes créent des dashboards, l'absence de convention produit un résultat chaotique : chaque dashboard a un style différent, des unités différentes, des seuils différents. Définir une charte de dashboards résout le problème.

Charte minimale

Deux lignes de cette charte font gagner plus que toutes les autres. Formuler les titres de panneaux comme des questions oblige à justifier l'existence de chaque panneau : celui qui ne répond à aucune question disparaît de lui-même. Et fixer les unités évite le malentendu le plus coûteux en astreinte, un ratio 0.005 interprété comme 5 % d'erreurs alors qu'il s'agit de 0,5 %.

Convention	Règle	Exemple
Nommage	[Équipe] Service - Type	Payments payment-api - RED
Titres de panneaux	Formulés comme une question	"Error rate, payment-api (%)"
Unités	req/s, ms, %, bytes, bits/s, jamais d'unité ambiguë	Ratio 0..1 → format Grafana "Percent (0.0-1.0)"
Seuils visuels	Vert < warning, orange < critical, rouge ≥ critical	Error rate : vert < 0.1 %, orange < 1 %, rouge ≥ 1 %
Couleurs	Rouge = mauvais, vert = bon, partout, sans exception	Pas de rouge pour "normal"
Time range par défaut	6 h pour diagnostic, 24 h pour vue quotidienne, 7 j pour tendance	Configurer par dashboard dans Settings → Time Range
Description	Chaque dashboard a une description (Settings → General)	"Dashboard RED du service payment-api, latence, erreurs, débit"

Glissez pour voir

Où documenter la charte

Le critère de choix est simple : une charte que personne ne lit ne sert à rien. Le dashboard modèle a l'avantage d'être appliqué sans effort de lecture, puisque les bonnes valeurs sont déjà en place ; la page de documentation a l'avantage d'expliquer les raisons, ce qui compte quand une équipe veut s'écarter de la règle. Les deux se complètent, mais si vous n'en tenez qu'une à jour, tenez le dashboard modèle.

Deux options qui fonctionnent :

1. Un dashboard "Template" : un dashboard vide avec les bonnes variables, les bons seuils, les bons dossiers, que les équipes dupliquent pour démarrer
2. Une page dans votre wiki/documentation interne : les règles de nommage, unités et seuils, avec des exemples

Les anti-patterns : ce qu'il ne faut pas faire

Ces dix erreurs ont deux origines distinctes qu'il est utile de séparer. Les premières relèvent de la lisibilité : trop de panneaux, titres muets, couleurs incohérentes. Elles rendent le dashboard inutile en incident mais ne coûtent rien au système. Les dernières relèvent de la charge : requêtes non filtrées, rafraîchissement trop fréquent, variables sans borne. Celles-là dégradent Prometheus pour tout le monde, y compris pour les alertes, et méritent donc d'être traitées en priorité.

Anti-pattern	Pourquoi c'est un problème	Solution
Dashboard de 40+ panneaux	Impossible à lire, charge lente, aucune hiérarchie	5-10 panneaux max par dashboard, organisés par question
Graphes sans titre explicite	"Panel 1", "Untitled", impossible de comprendre sans lire la requête	Titre = la question que le panneau résout ("Error rate, payment-api")
Moyenne seule (sans percentiles)	Masque les outliers, donne une fausse impression de normalité	Afficher p50 + p99 minimum
Fenêtre de temps trop large par défaut	30 jours de données = lent et illisible	6 h ou 24 h par défaut, le SRE ajuste si besoin
Pas d'annotations	Impossible de corréler un changement avec un symptôme	Annotations de déploiement au minimum
Dashboard sans variable	Un dashboard par service = duplication, maintenance impossible	Variables $service, $namespace au minimum
Panels qui query "*"	Charge toutes les séries du cluster = lent et coûteux	Filtres explicites (service, namespace) dans chaque requête
Refresh trop fréquent	Auto-refresh à 5 s sur un dashboard avec 30 panneaux = DDoS sur la datasource	30 s ou 1 min pour les dashboards opérationnels, 5 min pour les dashboards de tendance
Couleurs arbitraires	Rouge pour "normal", vert pour les erreurs, confus	Rouge = mauvais, vert = bon, partout, sans exception
Variables sans limite	Un dropdown qui retourne 5 000 services bloque le dashboard et surcharge Prometheus	Regex ou limite dans la requête de variable (100-200 valeurs max)

Glissez pour voir

Le dashboard fantôme

Le pire anti-pattern est le dashboard qu'on crée, qu'on ne regarde jamais, et qu'on n'ose pas supprimer. Les statistiques d'usage par dashboard sont une fonction Grafana Enterprise et Grafana Cloud, elles ne sont pas disponibles dans l'édition open source : sur celle-ci, appuyez-vous sur la liste des dashboards récemment consultés et sur une revue périodique en équipe. Si un dashboard n'a pas été ouvert depuis 90 jours, archivez-le ou supprimez-le. Un dashboard inutilisé consomme de la maintenance, de la confusion et parfois des ressources de requêtage.

Workflow : construire vos dashboards étape par étape

Cette séquence de huit étapes se déroule sur plusieurs semaines, pas en une après-midi. L'ordre a une raison : les étapes 1 à 4 produisent quelque chose d'utilisable immédiatement, les étapes 5 à 7 optimisent, et la huitième est celle qu'on saute presque toujours alors qu'elle est la plus décisive. Un dashboard n'est jamais terminé à sa création, il le devient après élagage au vu de l'usage réel.

1. Identifiez vos services critiques

   Listez les 3-5 services dont la dégradation a le plus d'impact sur vos utilisateurs. Ce sont vos candidats prioritaires pour un dashboard RED.

2. Créez le dashboard overview

   Un seul dashboard avec le statut (vert/rouge) de chaque service critique, les alertes actives et les derniers déploiements. C'est la porte d'entrée de votre observabilité.

3. Créez un dashboard RED par service

   Pour chaque service : rate, error rate, latence (p50, p90, p99). Ajoutez les variables $service et $namespace. Ajoutez un panneau "derniers logs ERROR" si vous avez Loki. Ajoutez le panneau "Top 5 routes" pour le diagnostic fin.

4. Créez un dashboard USE pour l'infrastructure

   CPU, mémoire, disque, réseau, organisé par nœud avec une variable $instance. Ajoutez le load average pour la saturation. Utilisez les filtres fstype et device adaptés à votre environnement.

5. Ajoutez les recording rules

   Pour les requêtes les plus coûteuses (histograms, agrégations multi- services), créez des recording rules. Le dashboard référence la métrique pré-calculée au lieu de recalculer à chaque ouverture.

6. Connectez les dashboards entre eux

   Ajoutez des data links : overview → service RED → infra USE. Le SRE doit pouvoir naviguer de "quel service est impacté ?" à "quel nœud est saturé ?" en 3 clics.

7. Ajoutez les annotations

   Configurez l'envoi d'annotations depuis votre CI/CD. Au minimum : les déploiements. Si vous avez un outil d'incident management, ajoutez les incidents.

8. Revoyez et élaguez

   Après 2 semaines d'utilisation, demandez aux utilisateurs : "Quels panneaux avez-vous réellement consultés ?" Supprimez le reste. Un bon dashboard est un dashboard qui a été élagué.

Pièges courants

À la différence des anti-patterns, qui portent sur le contenu du dashboard, ces cinq pièges portent sur la méthode de travail. Le deuxième est le plus fréquent en pratique : importer un dashboard communautaire donne un résultat impressionnant en cinq minutes, puis personne ne sait interpréter les quarante panneaux le jour où un incident survient. Un dashboard qu'on n'a pas construit soi-même ne se lit pas sous pression.

Piège	Conséquence	Solution
Construire le dashboard avant de savoir quoi mesurer	Dashboard sans direction, panneaux inutiles	Choisir le framework (RED/USE) d'abord, puis les panneaux
Copier un dashboard communautaire sans l'adapter	50 panneaux dont 45 inutiles pour votre contexte	Partir d'un dashboard vide, ajouter panneau par panneau
Mélanger RED et USE dans le même dashboard	Confusion entre symptôme service et cause infra	1 dashboard RED (service) + 1 dashboard USE (infra), reliés par data links
Pas de convention de nommage	"Dashboard API", "Mon dashboard", "test-2", introuvable	Convention : [Équipe] Service - Type (ex: "Payments payment-api - RED")
Alerter depuis le dashboard	Les alertes dépendent du dashboard, pas de règles centralisées	Séparer alerting (recording rules + Alertmanager) et dashboards (visualisation)

Glissez pour voir

À retenir

1. Un dashboard utile répond à une question précise en moins de 5 secondes, s'il faut chercher, c'est raté

2. Utilisez la méthode RED (Rate, Errors, Duration) pour les services orientés requêtes et la méthode USE (Utilization, Saturation, Errors) pour l'infrastructure

3. Organisez vos dashboards en trois niveaux : overview → service RED → infra USE, connectés par des data links

4. Les annotations de déploiement sont le moyen le plus simple de corréler un changement avec un incident, envoyez-les comme annotations globales (sans dashboardUID) avec des tags pour le filtrage

5. Les recording rules pré-calculent les requêtes coûteuses et accélèrent vos dashboards, indispensable dès que plusieurs personnes consultent les mêmes panneaux

6. Les variables Grafana ($service, $namespace, $instance) rendent un dashboard réutilisable, mais limitez le nombre de valeurs retournées pour éviter les dropdown de 5 000 entrées

7. Affichez toujours les percentiles (p50, p99), jamais la moyenne seule, et affichez le p99 par route en complément du p99 global

8. Définissez une charte de dashboards (nommage, unités, seuils, couleurs) pour que les dashboards de toutes les équipes restent cohérents

9. Un dashboard non consulté depuis 90 jours doit être archivé ou supprimé, la maintenance invisible a un coût

Sources

• Tom Wilkie, RED Method : grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services, origine de la méthode RED
• Brendan Gregg, USE Method : brendangregg.com/usemethod.html, méthodologie USE pour le diagnostic de performance
• Google SRE Book, Monitoring Distributed Systems : sre.google/sre-book/monitoring-distributed-systems, Golden Signals et philosophie du monitoring
• Grafana, Dashboard Best Practices : grafana.com/docs/grafana/latest/dashboards/build-dashboards/best-practices, niveaux de maturité et bonnes pratiques
• Grafana, Annotations : grafana.com/docs/grafana/latest/dashboards/build-dashboards/annotate-visualizations, documentation des annotations
• Prometheus, Recording Rules : prometheus.io/docs/prometheus/latest/configuration/recording_rules, documentation des recording rules

Prochaines étapes

Golden Signals, RED, USE Les frameworks théoriques derrière les dashboards, choisir quoi mesurer selon le type de composant

Alerting efficace Configurer des alertes symptom-first qui réveillent pour les bonnes raisons, SLO-based alerting et burn rate

Métriques Counter, gauge, histogram, comprendre les types de métriques que vos dashboards affichent

Corrélation des signaux Relier logs, métriques et traces, le drill-down qui va au-delà du dashboard

Gouvernance Coûts, rétention, cardinalité, les règles qui empêchent vos dashboards de devenir un gouffre financier

×

📖 Voir la documentation →