Un dashboard Grafana avec trente panneaux n’aide personne à trois heures du matin. Le problème n’est presque jamais le manque de métriques : Prometheus en expose des milliers par service. Le problème, c’est l’absence de structure qui dit dans quel ordre les regarder quand quelque chose casse. RED et USE sont deux réponses à cette question, chacune pour un type de composant différent, et les confondre produit exactement le genre de dashboard qu’on ferme au bout de dix secondes en plein incident.

RED : pour ce qui traite des requêtes

RED s’applique à tout composant qui répond à des requêtes : un service HTTP, une API, un endpoint gRPC. Trois signaux, dans cet ordre de lecture :

  • Rate : le nombre de requêtes par seconde. Sert à voir si le trafic correspond à ce qui est attendu, pas à juger la santé en soi.
  • Errors : le taux de requêtes qui échouent. C’est le signal qui doit sauter aux yeux en premier sur un dashboard d’incident.
  • Duration : la distribution de latence, en percentiles (p50, p95, p99), jamais en moyenne : une moyenne masque exactement les 1 % de requêtes lentes qui font l’incident.
# Rate : requêtes par seconde, par code de statut
sum(rate(http_requests_total[5m])) by (status)

# Errors : taux d'erreur en pourcentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100

# Duration : p95 de latence
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Ces trois requêtes tiennent sur une seule ligne de panneaux, lisible en cinq secondes. C’est le test : si un dashboard RED ne se lit pas d’un coup d’œil sur un écran de portable, il a trop de panneaux ou les mauvais.

USE : pour ce qui traite des ressources

USE s’applique aux ressources qui ne répondent pas à des requêtes mais qu’on consomme : CPU, mémoire, disque, réseau, connexions d’un pool. Trois signaux différents :

  • Utilization : le pourcentage de temps où la ressource est occupée à faire un travail utile.
  • Saturation : la file d’attente de travail que la ressource n’arrive pas à absorber tout de suite (le nombre de processus en attente de CPU, la profondeur d’une queue).
  • Errors : les erreurs matérielles ou logicielles de la ressource elle-même (paquets réseau perdus, secteurs disque défaillants).
# Utilization CPU par nœud
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Saturation : run queue (load average normalisé par le nombre de cœurs)
node_load1 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"})

# Errors réseau
rate(node_network_receive_errs_total[5m])

L’erreur classique est d’appliquer RED à une ressource : le CPU n’a pas de « taux de requêtes » ni de « latence de requête » au sens utile, il a une utilisation et une saturation. Un dashboard qui affiche la latence moyenne du CPU est un signe qu’on a copié un gabarit sans réfléchir à ce qu’il mesure.

Pourquoi la confusion coûte cher en plein incident

Un dashboard bien construit répond à une question précise sans qu’on ait à la formuler : « qu’est-ce qui a changé juste avant que les utilisateurs commencent à se plaindre ? ». Un dashboard RED en tête de service répond à ça pour la couche applicative. Un dashboard USE juste en dessous, pour l’infrastructure qui la porte. Empiler les deux sur le même panneau, ou pire, mélanger les métriques (afficher la latence HTTP à côté de l’utilisation CPU sans hiérarchie claire) oblige la personne d’astreinte à reconstruire mentalement cette hiérarchie sous pression, au moment précis où elle en a le moins la capacité.

Une structure de dashboard qui tient sous pression

Un dashboard d’incident efficace suit un ordre de lecture, pas une liste de métriques disponibles : d’abord RED sur le service concerné (est-ce que les utilisateurs sont impactés, et comment), puis USE sur les ressources dont ce service dépend directement (le nœud, la base de données, le cache), et seulement ensuite les métriques métier spécifiques. Chaque ligne du dashboard doit correspondre à une question qu’on se pose réellement en marchant vers l’incident, dans l’ordre où on se la pose.

Ce même principe de mesurer avant d’agir infuse tout ce qui touche à l’observabilité : un dashboard n’est utile que s’il raccourcit le chemin entre le symptôme et la cause, pas s’il affiche tout ce qui est mesurable. Les golden signals donnent le vocabulaire de base ; RED et USE en sont l’application organisée par type de composant, prête à devenir des règles d’alerte une fois qu’on sait ce qui mérite de réveiller quelqu’un.

À retenir

RED pour ce qui répond à des requêtes, USE pour ce qui se consomme comme ressource. Un dashboard qui mélange les deux sans hiérarchie force une reconstruction mentale en plein incident. La question à se poser pour chaque panneau n’est pas « est-ce que cette métrique existe » mais « à quelle question précise ce panneau répond-il, et dans quel ordre je le regarde ». Structurer un système d’observabilité qui tient cette promesse fait partie de ce qui se traite dans une mission de fiabilité et observabilité.