Golden Signals, RED, USE : choisir quoi mesurer

Vous savez que l’observabilité repose sur les logs, les métriques et les traces — mais concrètement, quelles métriques collecter en premier ? Sans cadre de réflexion, les équipes finissent par mesurer ce qui est facile à mesurer (le CPU, la RAM) plutôt que ce qui compte pour leurs utilisateurs.

Trois frameworks existent pour répondre à cette question : les Golden Signals de Google SRE, la méthode RED de Tom Wilkie et la méthode USE de Brendan Gregg. Chacun est conçu pour un type de composant différent. Ce guide vous apprend à choisir le bon framework selon ce que vous mesurez — un service, une API ou une ressource d’infrastructure.

En résumé

• Golden Signals (Google SRE) : latence, trafic, erreurs, saturation — vision globale d’un service.
• RED (Tom Wilkie) : rate, errors, duration — focus API et microservices.
• USE (Brendan Gregg) : utilization, saturation, errors — focus infrastructure (CPU, disque, réseau).
• En pratique, on combine souvent RED + USE pour couvrir à la fois les services et l’infrastructure.

Ce que vous allez apprendre

• Les 4 Golden Signals et pourquoi Google les a choisis
• La méthode RED et quand l’appliquer à vos APIs
• La méthode USE et quand l’appliquer à vos ressources système
• Un arbre de décision pour choisir le bon framework selon le composant
• Des exemples concrets de métriques Prometheus pour chaque signal

Le problème : mesurer tout, ne rien comprendre

Avant de présenter les frameworks, comprenons le problème qu’ils résolvent.

Un serveur Linux expose des centaines de métriques système. Une application web peut en générer des milliers. Un cluster Kubernetes en exporte des dizaines de milliers. Face à cette masse de données, deux erreurs classiques apparaissent :

• Mesurer ce qui est facile plutôt que ce qui est utile. Le CPU et la RAM sont les premières métriques que tout le monde collecte, mais elles disent rarement si vos utilisateurs sont satisfaits.
• Créer des dashboards de 50 graphiques que personne ne regarde, parce que personne ne sait quel graphique regarder en cas d’incident.

Les modèles mentaux que nous allons voir résolvent ce problème : ils vous donnent une grille de lecture pour sélectionner les métriques qui comptent vraiment, selon le type de composant que vous surveillez.

Les Golden Signals — la vision Google SRE

Les 4 Golden Signals sont définis dans le chapitre Monitoring Distributed Systems du livre Site Reliability Engineering de Google, publié en 2016. C’est le framework le plus connu et le point de départ recommandé pour tout système orienté utilisateur.

Le principe est simple : si vous ne pouvez mesurer que 4 choses sur un service, mesurez celles-ci.

1. Latence

Le temps nécessaire pour traiter une requête. La latence doit être mesurée séparément pour les requêtes réussies et les requêtes en erreur, car une erreur renvoyée en 2ms est très différente d’une réponse réussie en 2ms.

Ce qu’il faut mesurer concrètement :

• Latence p50 (médiane) : ce que vit l’utilisateur “typique”
• Latence p90 : ce que vivent 10% des utilisateurs les plus lents
• Latence p99 : la “traîne” — les pires cas

Pourquoi les percentiles et pas la moyenne ?

La moyenne masque les valeurs extrêmes. Si 99 requêtes prennent 10ms et une prend 10 secondes, la moyenne affiche 109ms — un chiffre qui ne décrit l’expérience de personne. Le p99 affiche 10s, ce qui reflète un vrai problème.

2. Trafic

La quantité de demandes que votre service reçoit. Selon le type de service, le trafic se mesure différemment :

Type de service	Métrique de trafic
API HTTP	Requêtes par seconde
Base de données	Transactions par seconde
Système de streaming	Messages par seconde
CDN / stockage	Octets par seconde

Glissez pour voir

Le trafic est essentiel pour contextualiser les autres signaux. Une latence de 500ms avec 10 requêtes/s n’a pas la même signification qu’avec 10 000 requêtes/s.

3. Erreurs

Le taux de requêtes qui échouent — que ce soit une erreur explicite (HTTP 500), implicite (réponse HTTP 200 avec un contenu incorrect) ou par politique (toute réponse au-delà de votre SLO de latence compte comme une erreur fonctionnelle).

Les erreurs se mesurent idéalement sous forme de taux (erreurs / requêtes totales) plutôt qu’en compteur absolu. Un pic de 100 erreurs/minute est alarmant à 200 requêtes/minute, mais normal à 100 000 requêtes/minute.

4. Saturation

À quel point votre service est “plein”. La saturation mesure le travail en attente au niveau des ressources contraintes — celles qui, une fois épuisées, dégradent le service. Ce n’est pas simplement un pourcentage d’utilisation : c’est ce qui déborde quand l’utilisation atteint ses limites.

• File d’attente de requêtes qui s’allonge
• Pool de connexions à la base de données rempli à 95%
• Mémoire disponible qui diminue progressivement

La saturation est le signal le plus prédictif : une saturation croissante vous alerte avant que la latence ou les erreurs n’explosent.

Le piège du CPU comme Golden Signal

Le CPU est un indicateur de saturation utile, mais il est souvent mis en avant au détriment des autres signaux. Un CPU à 30% ne signifie pas que votre service va bien — votre pool de connexions à la base de données peut être saturé à 100%. Mesurez la saturation de chaque ressource contrainte, pas seulement le CPU.

La méthode RED — focus microservices

La méthode RED a été créée par Tom Wilkie, co-fondateur de Grafana Labs, comme une simplification des Golden Signals spécifiquement conçue pour les services orientés requête (APIs, microservices, applications web).

La logique est directe : pour chaque service de votre architecture, mesurez ces trois choses.

Rate — combien de requêtes par seconde ?

Le débit de requêtes entrant dans le service. C’est l’équivalent du signal “trafic” des Golden Signals, appliqué spécifiquement aux requêtes HTTP ou gRPC.

Exemple de métrique Prometheus :

rate(http_requests_total[5m])

Errors — quel pourcentage échoue ?

Le nombre de requêtes qui échouent par seconde, ou le taux d’erreur rapporté au nombre total de requêtes.

Exemple de métrique Prometheus :

sum(rate(http_requests_total{code=~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

Le label de code HTTP s’appelle souvent code ou status selon l’instrumentation — adaptez à vos conventions. Le sum() évite les résultats partiels quand plusieurs instances exportent la même métrique.

Duration — combien de temps prend chaque requête ?

La distribution des temps de réponse au niveau du service (handler / endpoint), idéalement exprimée en percentiles (p50, p90, p99) plutôt qu’en moyenne. Pour la latence ressentie de bout en bout par l’utilisateur, il faut du tracing distribué.

Exemple de métrique Prometheus :

histogram_quantile(
  0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Le sum by (le) est nécessaire pour agréger correctement les buckets de l’histogram avant de calculer le percentile. Sans cette agrégation, le résultat peut être faux si plusieurs instances exportent la même métrique.

Pourquoi RED et pas directement les Golden Signals ?

RED est un sous-ensemble des Golden Signals : il retire volontairement la saturation parce que, dans le contexte des microservices, la saturation est souvent mieux capturée par la méthode USE sur l’infrastructure sous-jacente.

L’avantage de RED est sa simplicité : trois métriques, un pattern d’instrumentation identique sur tous vos services, et une corrélation directe avec l’expérience utilisateur.

Golden Signal	Équivalent RED
Latence	Duration
Trafic	Rate
Erreurs	Errors
Saturation	(couvert par USE sur l’infra)

Glissez pour voir

Attention à la cardinalité

Lorsque vous instrumentez vos métriques RED, ne mettez jamais un identifiant à haute cardinalité en label Prometheus (user_id, request_id, session_id). Chaque combinaison unique de labels crée une série temporelle en mémoire. 100 000 utilisateurs × 5 endpoints = 500 000 séries → explosion de la consommation mémoire de Prometheus.

La méthode USE — focus infrastructure

La méthode USE a été créée par Brendan Gregg, ingénieur performance chez Netflix (précédemment Joyent et Sun Microsystems), et publiée en 2013 dans Communications of the ACM. C’est un framework conçu pour identifier rapidement les goulots d’étranglement sur les ressources physiques et virtuelles.

La méthode s’applique ressource par ressource : pour chaque composant matériel (CPU, mémoire, disque, réseau, GPU), posez trois questions.

Utilization — quel pourcentage de la capacité est utilisé ?

Le temps pendant lequel la ressource a été occupée, exprimé en pourcentage. Une utilisation de 100% signifie que la ressource ne peut plus absorber de charge supplémentaire.

Exemples :

Ressource	Métrique d’utilisation
CPU	% de temps non-idle
Mémoire	% de RAM utilisée
Disque	% de temps disque occupé (busy time / I/O time)
Réseau	% de bande passante consommée

Glissez pour voir

Saturation — y a-t-il du travail en attente ?

La quantité de travail que la ressource n’a pas pu traiter et qui attend en file d’attente. La saturation apparaît quand l’utilisation approche les 100%.

Exemples :

• CPU : run queue length (nombre de processus en attente d’exécution)
• Mémoire : taux de swap (la mémoire déborde sur le disque)
• Disque : longueur de la file d’attente I/O
• Réseau : paquets droppés, retransmissions TCP

Errors — des erreurs matérielles ou logicielles ?

Le nombre d’événements d’erreur sur la ressource. Ces erreurs sont souvent silencieuses (pas de log applicatif) mais dégradent les performances :

• Erreurs ECC mémoire corrigées
• Erreurs CRC réseau
• Erreurs de lecture/écriture disque
• Erreurs de bus PCIe

La force de USE : la couverture systématique

Ce qui rend USE puissant, c’est son approche exhaustive. Vous dressez la liste de toutes les ressources de votre système, puis vous vérifiez les trois métriques pour chacune. Cela empêche de passer à côté d’un goulot d’étranglement caché sur une ressource que vous n’auriez pas pensé à vérifier.

Quel framework choisir ? L’arbre de décision

Vous n’avez pas à choisir un seul framework — ils sont complémentaires. Voici un guide de décision pragmatique pour savoir lequel appliquer en fonction de ce que vous instrumentez.

Service orienté requête ?  → RED
Ressource système ?        → USE
Vue service critique ?     → Golden Signals
Composant hybride ?        → RED + USE

Le tableau de correspondance

Composant	Framework	Signaux à mesurer
API / microservice	RED	Rate, Errors, Duration
Service orienté utilisateur	Golden Signals	Latence, Trafic, Erreurs, Saturation
CPU, mémoire, disque, réseau	USE	Utilization, Saturation, Errors
Base de données	RED + USE	RED pour les requêtes SQL, USE pour le CPU et les I/O disque
File de messages (Kafka, RabbitMQ)	RED + USE	RED pour le débit de messages, USE pour les partitions et la mémoire
Load balancer	Golden Signals	Latence, Trafic (distribution backends), Erreurs (5xx), Saturation (connexions actives)

Glissez pour voir

La règle simple

1. Vous instrumentez un service qui répond à des requêtes ? → RED (Rate, Errors, Duration). C’est le cas pour une API, un microservice, une application web.

2. Vous surveillez une ressource matérielle ou système ? → USE (Utilization, Saturation, Errors). C’est le cas pour le CPU, la mémoire, le disque, le réseau.

3. Vous avez besoin d’une vue globale sur un service critique ? → Golden Signals (Latence, Trafic, Erreurs, Saturation). C’est le cas pour un service orienté utilisateur où la saturation vous intéresse directement.

4. Vous instrumentez un composant hybride (base de données, broker de messages) ? → Combinez RED pour les requêtes + USE pour les ressources sous-jacentes.

En pratique : combinez RED + USE

La combinaison la plus courante et la plus efficace est RED pour les services + USE pour l’infrastructure. Cette approche couvre les deux angles :

• RED vous dit si vos utilisateurs sont impactés (le service répond-il vite ? renvoie-t-il des erreurs ?)
• USE vous dit si votre infrastructure est le goulot d’étranglement (CPU saturé ? disque plein ? réseau congestionné ?)

Quand une alerte RED se déclenche (“le taux d’erreur du service checkout dépasse 2%”), vous basculez sur les métriques USE pour identifier la ressource responsable (“le pool de connexions PostgreSQL est saturé, la file d’attente I/O du disque s’allonge”).

Scénario concret : diagnostic en 3 couches

Pour illustrer l’utilisation combinée des frameworks, suivons une équipe qui reçoit une alerte sur son application e-commerce.

Alerte : le taux d’erreur du service checkout-api dépasse 5% depuis 2 minutes.

1. Couche RED (service) — L’équipe consulte les métriques RED du service checkout-api :

   • Rate : 800 req/s (normal)
   • Errors : 42 req/s → 5.2% (anormal, seuil à 1%)
   • Duration p99 : 4.2s (normalement 200ms)

   Verdict : le service souffre, les erreurs et la latence ont explosé en même temps.

2. Couche RED (dépendances) — L’équipe regarde les métriques RED des services appelés par checkout-api :

   • payment-service : Rate 800/s, Errors 0%, Duration p99 50ms → OK
   • inventory-service : Rate 800/s, Errors 12%, Duration p99 8s → problème ici

   Verdict : le problème vient du service inventory-service.

3. Couche USE (infra sous inventory-service) — L’équipe vérifie les ressources du pod inventory-service :

   • CPU : utilization 35%, saturation 0 → OK
   • Mémoire : utilization 72%, saturation 0 → OK
   • Disque (PostgreSQL) : utilization 98%, saturation : file d’attente I/O de 47 opérations → goulot d’étranglement

   Cause racine : un index manquant sur une table a provoqué des full table scans qui saturent les I/O disque.

Sans ces frameworks, l’équipe aurait regardé le CPU (normal), conclu que “l’infra va bien” et tâtonné pendant des heures.

Pièges courants

• Appliquer USE à un service. La méthode USE est conçue pour les ressources matérielles, pas pour les services. “L’utilisation d’un microservice” n’a pas de sens — utilisez RED à la place.
• Ignorer la saturation. La saturation est le signal le plus prédictif, mais c’est aussi le plus négligé. Mesurez les files d’attente, les pools de connexions et la run queue, pas seulement l’utilisation.
• Se focaliser sur la moyenne. La latence moyenne cache les problèmes qui affectent une minorité significative d’utilisateurs. Mesurez toujours en percentiles (p50, p90, p99).
• Oublier les erreurs implicites. Une requête HTTP 200 qui renvoie un résultat vide ou incorrect est une erreur fonctionnelle. Vos métriques doivent la capturer.
• Traiter les frameworks comme des dogmes. Ce sont des grilles de lecture, pas des lois. Si votre système a une particularité qui nécessite un signal supplémentaire, ajoutez-le.

À retenir

• Les Golden Signals (latence, trafic, erreurs, saturation) sont le cadre général défini par Google SRE pour mesurer la santé d’un service.
• La méthode RED (rate, errors, duration) simplifie les Golden Signals pour les APIs et microservices — c’est le point de départ idéal.
• La méthode USE (utilization, saturation, errors) est conçue pour l’infrastructure — CPU, mémoire, disque, réseau.
• En pratique, on combine souvent RED pour les services et USE pour l’infrastructure pour couvrir les deux couches.
• Ce ne sont pas des outils ni des produits : ce sont des modèles mentaux qui vous aident à poser les bonnes questions, quel que soit votre stack.

Sources

• Golden Signals : Google, Monitoring Distributed Systems, chapitre du livre Site Reliability Engineering, 2016.
• RED Method : Tom Wilkie, The RED Method: How to Instrument Your Services, Grafana Labs.
• USE Method : Brendan Gregg, The USE Method. Également publié dans Communications of the ACM, vol. 56, n° 2, février 2013.

Prochaines étapes

SLI, SLO, SLA et Error Budget Transformez vos métriques en objectifs de fiabilité mesurables.

Les logs comme signal d'observabilité Structurez vos logs pour passer du grep au diagnostic rapide.

Les métriques comme signal d'observabilité Counter, Gauge, Histogram — comprenez les types et les pièges de la cardinalité.

Prometheus : collecte de métriques Mettez en pratique RED et USE avec Prometheus et PromQL.

Observabilité vs monitoring Revenez aux fondamentaux : la différence entre détecter et diagnostiquer.

×

📖 Voir la documentation →