Grafana : construire des dashboards qui survivent en production

La plupart des dashboards Grafana commencent bien et finissent mal. Créés dans l’urgence d’un incident, ils accumulent des panels sans cohérence, des requêtes non documentées et des alertes qui se déclenchent en permanence. Quelques pratiques changent la donne.

La règle des trois niveaux

Un dashboard efficace se lit en une seconde. Organisez-le en trois niveaux verticaux :

Vue d’ensemble (haut) : RED metrics — taux de requêtes, taux d’erreur, latence p99. Un seul coup d’œil suffit pour savoir si ça va.
Analyse (milieu) : breakdown par service, endpoint ou région. Pour isoler le problème.
Détail (bas) : métriques bas niveau (CPU, mémoire, connexions DB). Pour comprendre la cause racine.

Ce n’est pas une contrainte esthétique — c’est une question de temps de réaction en incident.

Variables : un dashboard pour les gouverner tous

Les variables transforment un dashboard statique en outil interactif :

Variable: datasource (type: Datasource, plugin: Prometheus)
Variable: env (type: Query, query: label_values(up, environment))
Variable: instance (type: Query, query: label_values(up{environment="$env"}, instance))

Avec ces trois variables, un seul dashboard couvre tous les environnements et toutes les instances. Le filtrage en cascade (changer env rafraîchit les valeurs de instance) évite les erreurs de contexte.

Annotations : contextualiser les graphes

Les annotations placent des marqueurs sur les graphes aux moments des événements importants :

# Depuis votre pipeline CI/CD, au moment du déploiement :
curl -X POST http://grafana:3000/api/annotations \
  -H "Content-Type: application/json" \
  -d '{"text": "Deploy v2.4.1", "tags": ["deploy", "prod"], "time": '$(date +%s000)'}'

Sur un graphe de latence, voir exactement quand un déploiement s’est produit est souvent ce qui permet de relier une régression à sa cause.

Grafana Alerting unifié : ce qui a changé

Grafana a remplacé les anciennes alertes par panel par un système centralisé. La différence clé : les règles d’alerte sont maintenant des objets de première classe, indépendants des dashboards, avec un routage configurable.

# Règle d'alerte en tant que code (via provisioning)
groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 2m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "Taux d'erreur HTTP supérieur à 5% depuis 2 minutes"

Grafana as Code : versionner ses dashboards

Stocker les dashboards en JSON dans Git et les déployer via le mécanisme de provisioning est la pratique la plus sous-utilisée de Grafana :

# Structure de provisioning
grafana/
├── provisioning/
│   ├── dashboards/
│   │   └── dashboards.yml    # pointe vers le dossier JSON
│   └── alerting/
│       └── rules.yml
└── dashboards/
    ├── api-overview.json
    └── infrastructure.json

Avec cette configuration, Grafana charge automatiquement les dashboards au démarrage. Ils apparaissent dans l’interface mais ne peuvent pas être modifiés depuis l’UI — seulement via Git.

Notre formation Grafana & Prometheus couvre ces pratiques avec des ateliers sur des environnements réels.