Que mesurer exactement ?
Résumé : la question n'est pas « comment mesurer ? » mais « quoi mesurer ? ». Google a formalisé la réponse avec les quatre signaux dorés : latence, trafic, erreurs, saturation. Cette leçon les détaille, présente les méthodes complémentaires USE et RED, explique pourquoi la moyenne est trompeuse, et pourquoi surveiller la charge processeur est un mauvais réflexe.
1. Les quatre signaux dorés
Ils sont définis dans le chapitre 6 du livre « Site Reliability Engineering » de Google (2016), qui reste la référence du domaine.
Le signal 4 est le seul prédictif, et c'est pour cela qu'il est précieux. Latence, trafic et erreurs décrivent ce qui se passe maintenant. La saturation annonce ce qui va se passer : un disque à 92 % qui progresse de 1 % par jour vous laisse huit jours pour agir.
Le piège du signal 1, très fréquent : si vous mesurez la latence de toutes les requêtes confondues, une panne qui renvoie des erreurs instantanées améliorera votre latence moyenne. Votre graphique s'améliore pendant que votre service est cassé. Mesurez toujours séparément la latence des succès et celle des échecs.
2. Pourquoi la moyenne est trompeuse
C'est l'erreur statistique la plus coûteuse en observabilité.
Comprendre les centiles
| Centile | Signification | Ce qu'il révèle |
|---|---|---|
| p50 (médiane) | La moitié des requêtes sont plus rapides | L'expérience typique |
| p90 | 90 % des requêtes sont plus rapides | Le début de la zone lente |
| p95 | 95 % sont plus rapides | L'expérience des utilisateurs défavorisés |
| p99 | 99 % sont plus rapides | Les cas problématiques réels |
| p99.9 | 99,9 % sont plus rapides | Les cas extrêmes, souvent révélateurs de bugs |
L'argument d'Amazon, souvent cité : à grande échelle, le p99 n'est pas un cas marginal. Sur un million de requêtes par jour, le p99 représente 10 000 requêtes — donc potentiellement des milliers de clients mécontents. Et paradoxalement, ce sont souvent vos meilleurs clients qui sont dans le p99, car ce sont eux qui ont le plus de données à charger.
Recommandation pratique : surveillez le p50 et le p99 au minimum. Le p50 vous dit si l'expérience typique est bonne, le p99 vous dit si vous maltraitez une minorité.
3. La méthode USE — pour les ressources
Complémentaire aux signaux dorés, la méthode USE de Brendan Gregg s'applique aux ressources plutôt qu'aux services.
Le point le plus utile de la méthode USE : la saturation est presque toujours plus révélatrice que l'utilisation. Un processeur à 100 % d'utilisation sans file d'attente fonctionne parfaitement — il est simplement pleinement employé, ce qui est même souhaitable. Un processeur à 60 % avec dix processus en attente indique un vrai problème.
Application concrète très fréquente : le pool de connexions à la base de données. L'utilisation peut sembler modeste, mais si des requêtes attendent une connexion libre, votre application ralentit sans que rien ne paraisse saturé. Surveillez la file d'attente du pool, pas seulement son taux d'occupation.
4. La méthode RED — pour les services
L'atout pratique de RED : sa standardisation. Avec RED, vous construisez un seul modèle de tableau de bord et vous le dupliquez pour chacun de vos quarante services. Chaque ingénieur sait immédiatement lire n'importe quel tableau de bord, sans apprentissage. C'est un gain d'exploitation considérable dans une architecture en microservices.
5. Comment combiner les trois approches
6. Symptôme ou cause — la règle d'alerte fondamentale
C'est le principe le plus important de cette leçon. La plupart des équipes qui souffrent de fatigue d'alerte ont commis exactement cette erreur : elles alertent sur des causes (processeur, mémoire) au lieu de symptômes (erreurs, lenteur). Résultat, elles reçoivent des dizaines d'alertes qui ne correspondent à aucun impact utilisateur, et finissent par les ignorer toutes.
Le contre-exemple qui convainc : votre base de données est injoignable. Vos serveurs web ne travaillent presque plus, donc leur charge processeur est basse. Toutes vos alertes machine sont vertes, et votre service est totalement cassé. Seule une alerte sur le taux d'erreur vous aurait prévenu.
7. Ce qu'il faut mesurer, par type de composant
| Composant | À mesurer en priorité |
|---|---|
| API web | Taux d'erreur (par code de statut), latence p50/p95/p99, requêtes par seconde |
| Base de données | Latence des requêtes, connexions actives et en attente, requêtes lentes, retard de réplication |
| File de messages | Longueur de la file, retard du consommateur (le plus important), débit, messages en échec |
| Cache | Taux de succès (hit ratio), latence, évictions, mémoire utilisée |
| Tâche planifiée | Dernière exécution réussie, durée, taux d'échec |
| Frontal web | Core Web Vitals (LCP, INP, CLS), erreurs JavaScript, latence réseau réelle |
| Kubernetes | Redémarrages de pods, pods non planifiables, limites atteintes, sondes en échec |
| Métier | Commandes par heure, inscriptions, paiements réussis — les plus utiles de tous |
La dernière ligne est celle qu'on oublie systématiquement, et c'est dommage. Une métrique métier est souvent le meilleur détecteur de panne qui existe. Si le nombre de commandes par heure s'effondre alors que tous vos indicateurs techniques sont verts, il y a un problème — même si aucune erreur n'est remontée. C'est le type de panne silencieuse que rien d'autre ne détecte : un formulaire cassé côté client, un bouton invisible après une mise à jour de style, un paiement qui échoue silencieusement.
8. Les erreurs de mesure les plus fréquentes
Retenir en 30 secondes
- Quatre signaux dorés (Google) : latence, trafic, erreurs, saturation. Si vous ne mesurez que quatre choses, ce sont celles-là.
- La saturation est le seul signal prédictif — elle annonce les pannes avant qu'elles arrivent.
- Ne mesurez jamais la latence moyenne seule. Utilisez le p50 et le p99. À grande échelle, le p99 représente des milliers de clients réels.
- Séparez la latence des succès et des échecs — sinon une panne embellira vos graphiques.
- Méthode USE (ressources) : Utilisation, Saturation, Erreurs. La saturation est plus révélatrice que l'utilisation.
- Méthode RED (services) : Rate, Errors, Duration. Permet un tableau de bord standardisé par service.
- Règle d'alerte fondamentale : alertez sur les symptômes (impact utilisateur), affichez les causes en tableau de bord.
- N'oubliez pas les métriques métier — commandes, inscriptions, paiements. Ce sont les meilleurs détecteurs de pannes silencieuses.
- 20 métriques bien comprises valent mieux que 2 000 ignorées.