Dashboards efficaces¶
Concevoir des dashboards lisibles, utiles et adaptés a leur audience.
Principes de design¶
Un bon dashboard répond a une question précisé. S'il répond à tout, il ne répond a rien.
Les 3 critères fondamentaux¶
| Critère | Description |
|---|---|
| Hiérarchie visuelle | Les informations critiques en haut à gauche, détails en bas |
| Densite adaptée | Ni trop charge (illisible), ni trop vide (inutile) |
| Glanceability | Comprehensible en 5 secondes sans lecture approfondie |
Glanceability (règle des 5 secondes)¶
Un opérateur qui ouvre le dashboard en urgence doit pouvoir comprendre l'état du système en moins de 5 secondes. Si ce n'est pas possible, simplifiez.
Un bon dashboard répond a une question
Definissez la question avant de construire le dashboard. Exemple : "Est-ce que l'API de paiement est dégradée ?" plutôt que "Afficher toutes les métriques de l'API".
Dashboards par audience¶
Chaque audience a des besoins différents. Un seul dashboard pour tous = dashboard pour personne.
| Audience | Focus | Métriques typiques |
|---|---|---|
| Opérations / SRE | État en temps réel, diagnostics | Golden signals, erreurs, saturation |
| Management | Tendances, SLO, disponibilité | SLO compliance, MTTR, incidents du mois |
| Développeurs | Comportement applicatif | Latence p99, taux d'erreur par endpoint |
| Sécurité | Anomalies, accès | Tentatives d'authent, trafic anormal |
Hiérarchie des dashboards¶
graph TD
G["Dashboard global\nEtat general du systeme"] --> S["Dashboards service\nVue par domaine metier"]
S --> C["Dashboards composant\nDetail technique"]
C --> D["Debug ad-hoc\nExploration libre"]Concevez du général vers le particulier : le dashboard global est une porte d'entree, pas une encyclopedie.
Template USE : dashboard serveur¶
Pour chaque serveur ou nœud, un dashboard USE couvre :
| Panneau | Métrique | Seuil indicatif |
|---|---|---|
| CPU Utilization | cpu_usage_percent | Alerte > 80% sur 5min |
| CPU Saturation | node_load1 / nb_cores | Alerte > 1.5 |
| Memory Utilization | mem_used / mem_total | Alerte > 90% |
| Memory Saturation | swap_used | Alerte > 0 |
| Disk Utilization | disk_io_percent | Alerte > 85% |
| Network Errors | interface_errors_total | Alerte > 0 |
Template RED : dashboard service¶
Pour chaque service applicatif, un dashboard RED couvre :
| Panneau | Métrique | Seuil indicatif |
|---|---|---|
| Rate (req/s) | http_requests_total (rate) | Référence, pas de seuil fixe |
| Error Rate | http_5xx / http_total | Alerte > 1% |
| Duration p50 | histogram_quantile(0.5) | Référence baseline |
| Duration p99 | histogram_quantile(0.99) | Alerte si > SLO latence |
| Saturation | goroutines / connections | Dépend du service |
Anti-patterns¶
| Anti-pattern | Problème | Solution |
|---|---|---|
| Trop de panneaux | Impossible a lire en urgence | Max 12 panneaux par vue |
| Vanity metrics | Métriques impressionnantes mais inutiles | Ne garder que ce qui déclenche une action |
| Pie charts pour time series | Mauvaise représentation temporelle | Utiliser des graphes en courbe ou barres |
| Échelles non normalisees | Comparaisons trompeuses | Fixer les axes quand pertinent |
| Dashboard unique pour tous | Ne répond a aucune question bien | Créer des vues par audience |
| Pas de legende | Impossible a interpréter sans contexte | Labelliser toutes les series |
Les pie charts pour les time series
Un pie chart ne montre pas l'évolution dans le temps. Pour toute métrique temporelle, utilisez un graphe lineaire ou un bar chart. Reservez les pie charts aux repartitions statiques.
Outils¶
| Outil | Points forts |
|---|---|
| Grafana | Standard open source, multi-datasources, dashboards as code |
| Datadog | SaaS clé en main, correlations automatiques |
| Kibana | Orienté logs/APM, écosystème Elastic |
| Chronograf | Écosystème InfluxDB |
| Perses | Standard CNCF emergent, GitOps-friendly |