Surveiller les systèmes distribués

Surveiller (monitoring) un système distribué, c'est d'abord savoir ce qu'on veut en apprendre — et, surtout, ce qui mérite de réveiller un humain à trois heures du matin. Les équipes SRE de Google ont forgé un petit corpus de principes pour bâtir des systèmes de surveillance et d'alerte qui réussissent là où tant d'autres noient leurs ingénieurs sous le bruit. Là où Accelerate mesurait la performance de livraison et où The DevOps Handbook décrivait le flux, ce chapitre — signé par Rob Ewaschuk — répond à une question d'exploitation très concrète : quels problèmes doivent interrompre un humain par une alerte (page), et que faire de tout le reste ? La réponse tient en une phrase qui irrigue tout le texte : alertez sur les symptômes, gardez les causes pour le débogage, et que chaque alerte soit actionnable.

Un vocabulaire commun

Il n'existe pas de vocabulaire universellement partagé autour de la surveillance ; même chez Google, l'usage varie. Posons donc les termes que ce chapitre emploie.

Terme	Définition
Surveillance (monitoring)	Collecter, traiter, agréger et afficher en temps réel des données quantitatives sur un système : nombre et type de requêtes, nombre et type d'erreurs, temps de traitement, durée de vie des processus
Surveillance boîte blanche (white-box)	Fondée sur des métriques exposées par les entrailles du système — journaux (logs), interfaces de profilage, point d'accès HTTP émettant des statistiques internes
Surveillance boîte noire (black-box)	Tester le comportement visible de l'extérieur, exactement comme le verrait un utilisateur
Tableau de bord (dashboard)	Application (souvent web) offrant une vue synthétique des métriques d'un service, préconstruite pour exposer les plus importantes
Alerte (alert)	Notification destinée à un humain, poussée vers une file de tickets, un alias courriel ou un récepteur (pager) — respectivement un ticket, une alerte courriel, une page
Cause racine (root cause)	Défaut d'un système logiciel ou humain qui, une fois réparé, donne confiance que l'incident ne se reproduira pas de la même façon ; un incident peut avoir plusieurs causes racines
Push	Tout changement apporté au logiciel en exécution d'un service ou à sa configuration

Pourquoi surveiller ?

On surveille pour de nombreuses raisons, dont les cinq familles suivantes, et il vaut la peine de les distinguer car elles n'imposent pas les mêmes contraintes.

• Analyser les tendances de long terme. Quelle est la taille de ma base de données, à quelle vitesse grossit-elle ? À quel rythme croît mon nombre d'utilisateurs actifs quotidiens ?
• Comparer dans le temps ou entre groupes d'expérience. Les requêtes sont-elles plus rapides avec tel moteur de stockage qu'avec tel autre ? De combien mon taux de succès de cache s'améliore-t-il avec un nœud supplémentaire ? Mon site est-il plus lent que la semaine dernière ?
• Alerter (alerting). Quelque chose est cassé et il faut le réparer maintenant ; ou quelque chose va casser bientôt et quelqu'un doit y regarder vite.
• Construire des tableaux de bord. Ils doivent répondre aux questions de base sur le service et incluent normalement une forme des quatre signaux d'or.
• Conduire une analyse rétrospective ad hoc — autrement dit, déboguer. « Notre latence vient de bondir ; quoi d'autre s'est passé au même moment ? »

La surveillance et l'alerte permettent à un système de nous dire quand il est cassé, ou même ce qui est sur le point de casser. Quand le système ne peut pas se réparer tout seul, on veut qu'un humain examine l'alerte, détermine s'il y a un vrai problème, l'atténue (mitigate), puis en trouve la cause racine. La règle d'or, négative cette fois : ne déclenchez jamais une alerte simplement parce que « quelque chose semble un peu bizarre ».

Fixer des attentes raisonnables

Surveiller une application complexe est en soi un projet d'ingénierie d'envergure. Même avec une infrastructure d'instrumentation, de collecte, d'affichage et d'alerte déjà en place, une équipe SRE de Google de dix à douze membres compte typiquement une, parfois deux personnes dont la mission principale est de bâtir et maintenir la surveillance du service. Ce nombre a baissé à mesure que Google a généralisé et centralisé l'infrastructure commune, mais chaque équipe a son « monitoring person ». Précision importante : aussi plaisant soit-il d'avoir accès à de beaux graphes de trafic, les équipes SRE évitent soigneusement toute situation qui obligerait quelqu'un à « fixer un écran pour guetter les problèmes ».

Google tend vers des systèmes de surveillance plus simples et plus rapides, dotés de meilleurs outils d'analyse a posteriori. On se méfie des systèmes « magiques » qui prétendent apprendre des seuils ou détecter automatiquement la causalité. Un contre-exemple assumé : les règles qui détectent un changement inattendu du débit de requêtes utilisateur final — gardées aussi simples que possible, elles offrent une détection très rapide d'une anomalie simple, spécifique et sévère. D'autres usages (planification de capacité, prédiction de trafic) tolèrent davantage de fragilité, donc de complexité : une expérience observée sur des mois ou des années, avec un faible taux d'échantillonnage, survit à quelques relevés manqués sans que la tendance disparaisse.

L'expérience de Google avec les hiérarchies de dépendances complexes est mitigée. On utilise rarement des règles du type « si je sais que la base de données est lente, alerter pour la base lente ; sinon alerter pour le site lent ». Les rares règles fondées sur les dépendances concernent des parties très stables du système — par exemple « si un centre de données est drainé (drained) de son trafic, ne m'alerte pas sur sa latence ». Peu d'équipes maintiennent ces hiérarchies, car l'infrastructure connaît un rythme soutenu de refactorisation continue.

Symptômes contre causes

Votre système de surveillance doit répondre à deux questions : qu'est-ce qui est cassé, et pourquoi ? Le « quoi » désigne le symptôme ; le « pourquoi » désigne une cause (éventuellement intermédiaire). Cette distinction est l'une des plus importantes pour écrire une bonne surveillance, à signal maximal et bruit minimal.

Symptôme (ce que vit l'utilisateur)	Cause possible (le pourquoi)
Je sers des HTTP 500 ou 404	Les serveurs de base de données refusent les connexions
Mes réponses sont lentes	CPU surchargés par un tri inefficace, ou un câble Ethernet écrasé sous une baie (perte partielle de paquets)
Les utilisateurs en Antarctique ne reçoivent pas leurs GIF animés	Le réseau de diffusion de contenu (CDN) a mis sur liste noire certaines IP clientes
Du contenu privé est lisible par tous	Un nouveau push a oublié les listes de contrôle d'accès (ACL) et autorisé toutes les requêtes

La clé : alertez sur les symptômes — ce que l'utilisateur subit — et réservez les heuristiques orientées causes au débogage. On consacre beaucoup plus d'effort à attraper les symptômes qu'à attraper les causes ; et pour les causes, on ne s'inquiète que des causes très définies et très imminentes.

Une nuance de placement vaut d'être retenue : surveiller les symptômes est d'autant plus facile que l'on se place « haut » dans la pile — au plus près de l'utilisateur, là où le symptôme se manifeste tel qu'il le vit. En revanche, la saturation et la performance des sous-systèmes — par exemple les bases de données — doivent souvent être mesurées directement sur le sous-système lui-même, faute de quoi elles restent invisibles aux couches supérieures.

Boîte noire contre boîte blanche

Google combine un usage intensif de la surveillance boîte blanche avec un usage modeste mais critique de la boîte noire. La façon la plus simple de les opposer : la boîte noire est orientée symptômes et représente des problèmes actifs, pas prédits — « le système ne marche pas correctement, là, maintenant ». La boîte blanche dépend de la capacité à inspecter les entrailles du système (logs, points d'accès HTTP, instrumentation) ; elle permet donc de détecter les problèmes imminents, les défaillances masquées par des reprises (retries), et ainsi de suite.

Subtilité essentielle des systèmes en couches : le symptôme de l'un est la cause de l'autre. Si une base de données est lente, des lectures lentes sont un symptôme pour le SRE de la base qui les détecte ; mais pour le SRE du frontend qui observe un site lent, ces mêmes lectures lentes sont une cause. La boîte blanche est donc tantôt orientée symptômes, tantôt orientée causes, selon le degré d'information qu'elle livre.

                Frontend (site lent)
                      ▲  symptôme observé par le SRE frontend
                      │
              lecture base lente
                      ▲  ← CAUSE pour le frontend
                      │  ← SYMPTÔME pour le SRE base
                      │
                Base de données

Pour collecter de la télémétrie de débogage, la boîte blanche est indispensable : si les serveurs web semblent lents sur les requêtes lourdes en base, il faut savoir et à quelle vitesse le serveur web perçoit la base, et à quelle vitesse la base se croit elle-même — sinon impossible de distinguer une base réellement lente d'un problème réseau entre les deux. Pour la page, en revanche, la boîte noire impose une discipline salutaire : elle ne dérange un humain que lorsqu'un problème est déjà en cours et produit de vrais symptômes. Pour un problème pas-encore-survenu mais imminent, la boîte noire ne sert à rien.

Les quatre signaux d'or

Les quatre signaux d'or (the four golden signals) de la surveillance sont la latence (latency), le trafic (traffic), les erreurs (errors) et la saturation. Si vous ne pouviez mesurer que quatre métriques de votre système exposé aux utilisateurs, concentrez-vous sur celles-ci.

Signal	Ce qu'il mesure	Pièges et finesses
Latence	Le temps de service d'une requête	Distinguer la latence des requêtes réussies de celle des échecs : un HTTP 500 servi très vite fausse le calcul global. Et une erreur lente est pire qu'une erreur rapide — donc suivez la latence des erreurs au lieu de simplement les filtrer
Trafic	La demande exercée sur le système, dans une métrique de haut niveau propre au service	Requêtes HTTP par seconde pour un service web (statique vs dynamique) ; débit d'E/S réseau ou sessions concurrentes pour du streaming audio ; transactions et lectures par seconde pour un stockage clé-valeur
Erreurs	Le taux de requêtes qui échouent	Explicitement (HTTP 500), implicitement (un 200 mais avec le mauvais contenu) ou par règle (« au-delà d'une seconde, c'est un échec »). Les 500 se captent bien au répartiteur de charge ; le mauvais contenu, lui, n'apparaît qu'aux tests de bout en bout
Saturation	À quel point le service est « plein », en insistant sur la ressource la plus contrainte	Beaucoup de systèmes se dégradent avant 100 % d'utilisation : un objectif d'utilisation est donc essentiel. La hausse de latence est souvent un indicateur avancé ; la saturation couvre aussi les prédictions (« le disque sera plein dans 4 heures »)

Pour la saturation, on s'appuie typiquement sur des signaux indirects à borne supérieure connue — utilisation CPU, bande passante réseau. Pour les services très simples sans paramètre faisant varier la complexité (« donne-moi un nonce », « un entier monotone unique »), une valeur statique issue d'un test de charge peut suffire. Mesurer le 99ᵉ centile du temps de réponse sur une petite fenêtre (une minute, par exemple) donne un signal très précoce de saturation.

Se soucier de la queue de distribution

En partant de zéro, il est tentant de bâtir une surveillance fondée sur la moyenne : latence moyenne, charge CPU moyenne, remplissage moyen des bases. Le danger pour les deux dernières est évident — CPU et bases peuvent être utilisés de façon très déséquilibrée. Il en va de même pour la latence. Faites tourner un service web à 100 ms de latence moyenne et 1 000 requêtes par seconde, et il est tout à fait possible que 1 % des requêtes prennent 5 secondes. Si vos utilisateurs dépendent de plusieurs services de ce type pour afficher une page, le 99ᵉ centile d'un backend peut aisément devenir la médiane de votre frontend.

Le piège logique mérite d'être nommé : si 1 % de vos requêtes sont dix fois plus lentes que la moyenne, c'est que le reste est environ deux fois plus rapide que cette moyenne. Mais sans mesurer la distribution, croire que la plupart des requêtes sont proches de la moyenne relève du vœu pieux.

La parade : collecter des comptes de requêtes répartis par intervalles de latence (histogramme), plutôt que des latences brutes. Combien de requêtes entre 0 et 10 ms, entre 10 et 30 ms, entre 30 et 100 ms, entre 100 et 300 ms, etc. ? Distribuer les bornes de l'histogramme de façon approximativement exponentielle (ici par facteurs d'environ 3) visualise commodément la distribution.

Requêtes par intervalle de latence (bornes ~exponentielles)

  0–10 ms   ████████████████████████   (le gros du trafic)
 10–30 ms   ██████████████
 30–100 ms  █████
100–300 ms  ██
300 ms–1 s  ▌
   1–5 s    ▎   ← la « queue » (tail) : invisible dans la moyenne,
                  pourtant elle dégrade l'expérience réelle

Choisir la bonne résolution

Différents aspects d'un système se mesurent à différentes granularités. Quelques garde-fous concrets :

• Observer la charge CPU à l'échelle de la minute ne révélera même pas des pics pourtant assez longs qui font flamber la latence de queue.
• À l'inverse, pour un service web visant < 9 heures d'indisponibilité cumulée par an (99,9 % de disponibilité annuelle), sonder un statut 200 plus d'une ou deux fois par minute est probablement inutilement fréquent.
• De même, vérifier le remplissage des disques d'un service à 99,9 % plus d'une fois toutes les 1 à 2 minutes est sans doute superflu.

Attention au coût : collecter la charge CPU par seconde produit des données intéressantes, mais peut coûter très cher à collecter, stocker et analyser. Si l'objectif appelle une haute résolution sans exiger une très faible latence, on réduit ces coûts par un échantillonnage interne au serveur, puis une agrégation externe. Par exemple :

1. Relever l'utilisation CPU courante chaque seconde.
2. À l'aide d'intervalles de 5 %, incrémenter chaque seconde
   le bon « seau » (bucket) d'utilisation CPU.
3. Agréger ces valeurs chaque minute.

On observe ainsi les brefs points chauds CPU sans payer le prix d'une collecte et d'une rétention très fines.

Aussi simple que possible, pas plus

Empilées, toutes ces exigences peuvent engendrer un système de surveillance d'une grande complexité : alertes sur différents seuils de latence, à différents centiles, sur des métriques variées ; code supplémentaire pour détecter et exposer les causes possibles ; tableaux de bord dédiés à chacune de ces causes. Les sources de complexité sont sans fin. Comme tout logiciel, la surveillance peut devenir si complexe qu'elle en devient fragile, pénible à changer et coûteuse à maintenir.

Concevez donc votre surveillance avec un œil constant sur la simplicité. Trois règles d'élagage :

• Les règles qui attrapent le plus souvent de vrais incidents doivent être aussi simples, prévisibles et fiables que possible.
• Toute collecte, agrégation ou configuration d'alerte rarement exercée — moins d'une fois par trimestre pour certaines équipes — est candidate à la suppression.
• Tout signal collecté mais qui n'apparaît dans aucun tableau de bord préconstruit ni n'est utilisé par aucune alerte est candidat à la suppression.

Relier les principes : une page doit être actionnable

Ces principes se condensent en une philosophie de l'alerte largement adoptée par les équipes SRE de Google. Avant d'écrire ou de réviser une alerte, posez-vous ces questions, conçues pour éviter les faux positifs et l'épuisement du pager :

• Cette règle détecte-t-elle une condition autrement indétectée, qui est urgente, actionnable, et activement ou imminemment visible par l'utilisateur ? (Une situation à redondance nulle, N + 0, compte comme imminente, tout comme une ressource « presque pleine ».)
• Pourrai-je un jour ignorer cette alerte en la sachant bénigne ? Quand, pourquoi, et comment éviter ce scénario ?
• Cette alerte indique-t-elle à coup sûr que des utilisateurs sont affectés négativement ? Y a-t-il des cas détectables où ils ne le sont pas — trafic drainé, déploiements de test — qu'il faudrait filtrer ?
• Puis-je agir en réponse ? L'action est-elle urgente ou peut-elle attendre le matin ? Pourrait-elle être automatisée sans danger ? Est-ce un correctif durable ou un palliatif ?
• D'autres personnes sont-elles déjà alertées pour le même incident, rendant au moins une des pages inutile ?

Ces questions reflètent une philosophie fondamentale du pager : chaque fois qu'il sonne, je dois pouvoir réagir avec un sentiment d'urgence — ce que je ne peux faire que quelques fois par jour avant la fatigue ; chaque page doit être actionnable ; chaque réponse doit exiger de l'intelligence — si une réponse robotique suffit, cela ne devrait pas être une page ; et une page devrait concerner un problème nouveau.

Sur le long terme : deux cas

En production moderne, la surveillance suit un système en perpétuelle évolution — architecture, charge, objectifs de performance changeants. Une alerte aujourd'hui rare et difficile à automatiser peut devenir fréquente ; il faut alors trouver et éliminer ses causes racines, ou à défaut automatiser pleinement la réponse. Chaque page d'aujourd'hui détourne un humain de l'amélioration du système de demain : il y a donc souvent un argument pour accepter une baisse de disponibilité à court terme afin d'améliorer la perspective à long terme. Deux études de cas l'illustrent.

Bigtable : trop d'alertes

L'infrastructure interne de Google est généralement mesurée contre un objectif de niveau de service (SLO, service level objective). Il y a des années, le SLO de Bigtable reposait sur la performance moyenne d'un client synthétique bien élevé. À cause de problèmes dans Bigtable et les couches de stockage inférieures, cette moyenne était tirée par une « grosse » queue : les 5 % de requêtes les pires étaient nettement plus lentes que le reste. Des alertes courriel se déclenchaient à l'approche du SLO, des pages à son dépassement. Les deux types crépitaient en masse, dévorant un temps d'ingénierie inacceptable : l'équipe triait sans fin pour trouver les rares alertes vraiment actionnables, et manquait souvent les problèmes affectant réellement les utilisateurs, tant ils étaient noyés. Beaucoup de pages étaient non urgentes, dues à des défauts bien compris de l'infrastructure, avec des réponses machinales ou aucune réponse.

Le remède fut triple : en travaillant d'arrache-pied à améliorer la performance de Bigtable, l'équipe a temporairement abaissé son SLO au 75ᵉ centile de latence, et désactivé les alertes courriel devenues trop nombreuses pour être diagnostiquées. Ce répit a donné l'espace de corriger les vrais problèmes de fond plutôt que de colmater sans fin. Les ingénieurs d'astreinte (on-call) pouvaient enfin travailler sans être tenus éveillés par les pages. Reculer temporairement sur les alertes a permis d'avancer plus vite vers un meilleur service.

Gmail : des réponses humaines scriptables

Aux tout débuts de Gmail, le service tournait sur un gestionnaire de processus distribué détourné, Workqueue, conçu à l'origine pour le traitement par lots de l'index de recherche. Adapté à des processus de longue durée puis appliqué à Gmail, il traînait dans son ordonnanceur des bogues coriaces nichés dans une base de code opaque. La surveillance déclenchait alors une alerte chaque fois qu'une tâche individuelle était « dé-planifiée » (de-scheduled) par Workqueue. Or Gmail comptait déjà des milliers de tâches, chacune ne représentant qu'une fraction de pour-cent des utilisateurs : ce dispositif était ingérable.

L'équipe construisit un outil pour « pousser » l'ordonnanceur juste comme il faut afin de minimiser l'impact. Restait une tension : fallait-il automatiser toute la boucle, de la détection à la relance, en attendant une vraie solution durable ? Certains craignaient qu'un tel contournement ne retarde le vrai correctif.

Le long terme

Un fil relie Bigtable et Gmail : la tension entre disponibilité de court et de long terme. La force brute peut hisser un système bancal à une haute disponibilité, mais cette voie est éphémère, jalonnée d'épuisement et dépendante de quelques héros. Accepter une baisse contrôlée et temporaire de disponibilité est souvent un échange douloureux mais stratégique pour la stabilité à long terme. Il ne faut pas penser chaque page comme un événement isolé, mais se demander si le niveau global de paging mène vers un système sainement disponible et une équipe viable. Google revoit en réunion trimestrielle avec le management des statistiques de fréquence des pages — souvent exprimées en incidents par garde (un incident pouvant regrouper quelques pages liées) — pour tenir les décideurs informés de la charge du pager et de la santé des équipes.

À retenir

• On surveille pour cinq raisons distinctes — tendances de long terme, comparaisons, alerte, tableaux de bord et débogage rétrospectif — et chacune tolère un degré différent de complexité ; ne déclenchez jamais une alerte juste parce que « quelque chose semble bizarre ».
• Alertez sur les symptômes, pas sur les causes : ce que vit l'utilisateur (le « quoi ») prime sur le « pourquoi », réservé au débogage ; dans un système en couches, le symptôme de l'un est la cause de l'autre.
• Combinez une boîte blanche intensive (logs, instrumentation, problèmes imminents et masqués par les reprises) avec une boîte noire modeste mais critique (symptômes actifs, vus comme l'utilisateur) pour le paging.
• Mesurez les quatre signaux d'or — latence, trafic, erreurs, saturation — et alertez dès qu'un signal est problématique (ou presque, pour la saturation) : c'est le socle minimal d'une couverture décente.
• Surveillez la queue de distribution, pas la moyenne : un histogramme à bornes exponentielles révèle le 99ᵉ centile qui peut devenir la médiane du frontend ; choisissez la résolution selon l'objectif, en échantillonnant pour maîtriser les coûts.
• Gardez la surveillance aussi simple que possible : élaguez les règles rarement exercées et les signaux sans tableau de bord ni alerte ; séparez la surveillance du profilage, des tests de charge et du débogage fin.
• Chaque page doit être actionnable, urgente, intelligente et nouvelle : une alerte non actionnable est du bruit. À long terme (Bigtable, Gmail), accepter une baisse temporaire et contrôlée de disponibilité ou automatiser les réponses machinales bat l'héroïsme chronique et l'épuisement du pager.