Les méthodes de Brendan Gregg pour la latence et le profilage

Pourquoi l'approche de Brendan Gregg réduit les suppositions

Brendan Gregg est l'une des voix les plus influentes en performance des systèmes, en particulier dans l'univers Linux. Il a écrit des ouvrages largement utilisés, créé des outils pratiques et — surtout — partagé des méthodes claires pour enquêter sur des problèmes réels en production. Les équipes adoptent son approche parce qu'elle fonctionne sous pression : quand la latence grimpe et que tout le monde veut des réponses, il faut un moyen de passer de « peut‑être c'est X » à « c'est définitivement Y » avec un minimum de drama.

Ce que signifie vraiment « méthode de performance »

Une méthode de performance n'est pas un outil unique ou une commande astucieuse. C'est une façon répétable d'enquêter : une check‑list de ce qu'il faut regarder en premier, comment interpréter ce qu'on voit, et comment décider de l'étape suivante.

Cette répétabilité réduit les suppositions. Au lieu de dépendre de la personne qui a le plus d'intuition (ou l'opinion la plus forte), vous suivez un processus cohérent qui :

• réduit le problème à une ressource, un service ou un chemin de code précis
• mesure ce qui se passe dans la même fenêtre temporelle que l'incident
• confirme le goulet d'étranglement avec des preuves avant d'appliquer des changements

Mode d'échec courant : réparer avant de mesurer

Beaucoup d'enquêtes sur la latence partent mal dans les cinq premières minutes. Les gens passent directement aux correctifs : « ajouter du CPU », « redémarrer le service », « augmenter le cache », « tuner le GC », « ça doit être le réseau ». Parfois ces actions aident — souvent elles masquent le signal, font perdre du temps ou introduisent un nouveau risque.

Les méthodes de Gregg vous poussent à différer les « solutions » jusqu'à ce que vous puissiez répondre à des questions plus simples : Qu'est‑ce qui est saturé ? Qu'est‑ce qui fait des erreurs ? Qu'est‑ce qui a ralenti — le débit, la mise en file d'attente, ou les opérations individuelles ?

Ce que ce guide vous aide à faire

Ce guide vous aide à restreindre la portée, mesurer les bons signaux et confirmer le goulet d'étranglement avant d'optimiser. L'objectif est un flux de travail structuré pour enquêter sur la latence et le profilage en production afin que les résultats ne dépendent pas de la chance.

Notions de base sur la latence : que mesurer avant d'optimiser

La latence est un symptôme : les utilisateurs attendent plus longtemps la fin d'un travail. La cause se situe généralement ailleurs — contention CPU, attentes disque ou réseau, contention sur des verrous, garbage collection, mise en file d'attente, ou ralentissements de dépendances distantes. Mesurer uniquement la latence vous dit qu'il y a un problème, pas d'où il provient.

Débit, latence et erreurs évoluent ensemble

Ces trois signaux sont couplés :

• Débit (requêtes/seconde) en hausse peut augmenter la mise en file d'attente, ce qui accroît la latence.
• Erreurs peuvent réduire la latence observée (échecs rapides) ou l'augmenter (reprises et timeouts).
• Restreindre le débit (limites, backpressure) peut améliorer la latence des queues extrêmes tout en rendant moins de requêtes réussies.

Avant d'optimiser, capturez les trois pour la même fenêtre temporelle. Sinon vous risquez de « réparer » la latence en supprimant du travail ou en échouant plus vite.

Ne faites pas confiance aux moyennes : percentiles et latence extrême

La latence moyenne masque les pics que les utilisateurs retiennent. Un service avec une moyenne à 50 ms peut avoir des blocages fréquents à 2 s.

Suivez les percentiles :

• p50 : expérience typique de l'utilisateur
• p95/p99 : latence de queue (où se situe la plupart de la douleur lors d'incidents)

Surveillez aussi la forme de la latence : un p50 stable avec un p99 en hausse indique souvent des blocages intermittents (par ex. contention de verrou, problèmes d'E/S, pauses stop‑the‑world) plutôt qu'un ralentissement généralisé.

Budgets de latence : où le temps peut être dépensé

Un budget de latence est un modèle simple de comptabilité : « si la requête doit finir en 300 ms, comment le temps peut‑il être réparti ? » Décomposez‑le en postes tels que :

• temps dans votre service (calcul + attente)
• temps dans les services en aval
• temps dans bases de données/caches
• transit réseau et TLS
• temps passé en file d'attente (threads, pools de connexions, load balancers)

Ce budget cadre la première tâche de mesure : identifiez quel poste a augmenté pendant le pic, puis enquêtez cette zone au lieu d'optimiser à l'aveugle.

Commencez par une question et une portée claires

Les travaux sur la latence partent de travers quand le « problème » est décrit comme le système est lent. Les méthodes de Gregg débutent plus tôt : forcez la question en un énoncé précis et testable.

Définissez ce que « lent » signifie (et pour qui)

Écrivez deux phrases avant de toucher aux outils :

• Qu'est‑ce qui est lent ? (chargement de page, endpoint API, job batch, login, checkout, une requête SQL spécifique)
• Où cette lenteur est‑elle observée ? (navigateur client, appli mobile, une région, un pod, un hôte, un service interne)

Cela évite d'optimiser la mauvaise couche — par exemple le CPU hôte — alors que la douleur est isolée à un endpoint ou une dépendance en aval.

Choisissez une fenêtre temporelle et une portée

Prenez une fenêtre qui correspond à la plainte et inclut une période « bonne » en comparaison si possible.

Délimitez explicitement votre enquête :

• Hôte vs service vs endpoint : « un nœud Kubernetes » n'est pas la même chose qu'« une route API ».
• Quelle tranche de trafic : région, niveau de client, requêtes erronées seulement, ou toutes les requêtes.
• Quel signal a déclenché le rapport : p95, timeouts, profondeur de file, ou timing utilisateur.

La précision ici accélère les étapes suivantes (USE, RED, profilage) car vous saurez quelles données doivent évoluer si votre hypothèse est correcte.

Traitez les changements récents comme des hypothèses, pas des réponses

Notez les déploiements, changements de config, évolutions de trafic et événements infra — mais n'assumez pas la causalité. Formulez‑les comme « si X, alors on s'attend à Y », afin de pouvoir confirmer ou rejeter rapidement.

Gardez un journal d'enquête léger

Un petit journal évite le travail dupliqué entre collègues et facilite les transmissions.

Time | Question | Scope | Data checked | Result | Next step

Même cinq lignes comme celle‑ci peuvent transformer un incident stressant en un processus répétable.

La méthode USE : un inventaire rapide des goulets par ressource

La méthode USE (Utilisation, Saturation, Erreurs) est la check‑list rapide de Gregg pour scanner les « quatre grandes » ressources — CPU, mémoire, disque (stockage) et réseau — afin de cesser de deviner et commencer à restreindre le problème.

En quoi ça consiste : une check‑list par ressource

Au lieu de regarder des dizaines de tableaux, posez les mêmes trois questions pour chaque ressource :

• Utilisation : À quel point est‑elle occupée en ce moment ?
• Saturation : Est‑ce que du travail s'accumule (files, temps d'attente), même si l'utilisation n'est pas maximale ?
• Erreurs : Est‑ce que ça échoue ou relance de manière à créer de la latence ?

Appliquée de manière cohérente, c'est un inventaire rapide de là où existe la « pression ».

Comment l'appliquer en pratique

Pour le CPU, l'utilisation est le % d'occupation, la saturation se manifeste par la file d'attente run‑queue ou des threads en attente d'exécution, et les erreurs peuvent inclure du throttling (en conteneurs) ou des interruptions mal gérées.

Pour la mémoire, l'utilisation est la mémoire utilisée, la saturation apparaît souvent sous forme de paging ou de collections fréquentes du GC, et les erreurs incluent les échecs d'allocation ou événements OOM.

Pour le disque, l'utilisation est le temps d'occupation du périphérique, la saturation est la profondeur de file et le temps d'attente lecture/écriture, et les erreurs sont les erreurs I/O ou timeouts.

Pour le réseau, l'utilisation est le débit, la saturation ce sont les pertes/queues/latences, et les erreurs sont retransmissions, resets, ou pertes de paquets.

Signaux les plus utiles lors d'incidents de latence

Quand les utilisateurs signalent de la lenteur, les signaux de saturation sont souvent les plus révélateurs : files, temps d'attente et contention corrèlent plus directement avec la latence que l'utilisation brute.

USE complète les métriques service (sans les remplacer)

Les métriques de service (latence des requêtes, taux d'erreur) vous disent l'impact. USE vous indique où regarder ensuite en identifiant la ressource sous contrainte.

Une boucle pratique :

1. Confirmer l'impact utilisateur (Durée/Erreurs)
2. Lancer l'inventaire USE
3. Zoomer sur la ressource suspecte avec des outils plus profonds (profils, traces, stats kernel)

La méthode RED : signaux axés sur le service qui pointent l'impact

La méthode RED vous garde ancré sur l'expérience utilisateur avant de plonger dans les graphiques d'hôte.

• Rate : combien de requêtes par seconde votre service ou endpoint gère
• Errors : combien de requêtes échouent (et ce que « échec » signifie pour votre app)
• Duration : combien de temps prennent les requêtes réussies (suivi en percentiles, pas en moyennes)

Pourquoi RED vous aide à prioriser

RED vous évite de courir après des métriques « intéressantes » qui n'affectent pas les utilisateurs. Il impose une boucle plus serrée : quel endpoint est lent, pour quels utilisateurs, et depuis quand ? Si la Duration monte seulement sur une route alors que le CPU global est stable, vous avez déjà un point de départ plus précis.

Une habitude utile : conserver RED détaillé par service et principaux endpoints (ou méthodes RPC clés). Cela permet de distinguer facilement une dégradation générale d'une régression localisée.

Mapper les symptômes RED aux vérifications USE

RED vous dit où ça fait mal. USE vous aide à tester quelle ressource en est responsable.

Exemples :

• Duration en hausse + Rate stable → vérifier la saturation/mise en file : run queue CPU, latence stockage, pools de connexions DB.
• Erreurs en hausse + Duration en hausse → vérifier timeouts et retries : services en aval surchargés, pools de threads, pertes réseau.
• Rate en hausse + Duration en hausse → vérifier limites de capacité : utilisation CPU, comportement des load balancers, délais d'autoscaling.

Un tableau de bord minimal « qu'est‑ce qui a changé ? »

Gardez une présentation concentrée :

1. Vue RED : Rate, Errors et p50/p95/p99 Duration pour le service.
2. Top endpoints : mêmes signaux RED par endpoint, triés par trafic ou pire p95.
3. Dépendances : panneaux de type RED pour les principaux downstreams (DB, cache, API externes).
4. Une ligne de corrélation : un petit ensemble de métriques système (CPU, pression mémoire, latence I/O disque, retransmissions réseau) pour accélérer le saut de la vue service vers le test de la cause racine.

Si vous voulez un flux d'incident cohérent, associez cette section à l'inventaire USE dans /blog/use-method-overview pour passer de « les utilisateurs le ressentent » à « cette ressource est la contrainte » avec moins d'agitation.

Priorisation : choisir la prochaine meilleure question à poser

Une enquête de performance peut exploser en dizaines de graphiques et d'hypothèses en quelques minutes. L'état d'esprit de Gregg est de rester étroit : votre travail n'est pas de « collecter plus de données », mais de poser la prochaine question qui élimine le plus rapidement l'incertitude.

Règle 80/20 pour les goulets d'étranglement

La plupart des problèmes de latence sont dominés par un coût unique (ou une petite paire) : un verrou chaud, une dépendance lente, un disque surchargé, un pattern de pause GC. Prioriser signifie chercher d'abord ce coût dominant, car diminuer de 5 % cinq endroits différents déplace rarement la latence visible par l'utilisateur.

Un test pratique : « Qu'est‑ce qui pourrait expliquer la majeure partie du changement de latence que nous observons ? » Si une hypothèse n'explique qu'une petite part, c'est une question de moindre priorité.

Top‑down vs bottom‑up : où commencer

Utilisez top‑down lorsque vous répondez à « les utilisateurs sont‑ils impactés ? » Commencez par les endpoints (signaux RED) : latence, débit, erreurs. Cela évite d'optimiser quelque chose qui n'est pas sur le chemin critique.

Utilisez bottom‑up quand l'hôte est manifestement malade (symptômes USE) : saturation CPU, pression mémoire incontrôlée, attente I/O. Si un nœud est saturé, vous perdrez du temps à regarder les percentiles d'endpoints sans comprendre la contrainte.

Un simple arbre de décision pour éviter la dispersion

Quand une alerte sonne, prenez une branche et restez‑y jusqu'à confirmation ou réfutation :

• Pic de latence + pic d'erreurs → « dépendance ou capacité ? » (timeouts, épuisement de pools, downstream 5xx)
• Pic de latence + pic CPU → « le CPU fait‑il un travail utile ou est‑il bloqué ? » (on‑CPU vs off‑CPU)
• Pic de latence + forte attente I/O → « quel périphérique ou système de fichiers est en cause ? »
• Pic de latence sans pics de ressource → « où est passé le temps d'attente ? » (verrous, ordonnanceur, réseau, appels distants)

Éviter la surcharge de métriques, rester systématique

Limitez‑vous à un petit ensemble de signaux de départ, puis creusez seulement quand quelque chose bouge. Si vous avez besoin d'une checklist pour rester concentré, liez vos étapes à un runbook comme /blog/performance-incident-workflow afin que chaque nouvelle métrique ait un but : répondre à une question précise.

Profilage en production sans mettre le système hors service

Le profilage en production peut sembler risqué car il touche au système live — mais c'est souvent le moyen le plus rapide de remplacer le débat par des preuves. Les logs et tableaux vous disent que quelque chose est lent. Le profilage vous dit où le temps est passé : quelles fonctions sont chaudes, quels threads attendent, et quels chemins de code dominent pendant l'incident.

Ce que le profilage répond réellement

Le profilage est un outil de « budget temporel ». Plutôt que de débattre (« c'est la base de données » vs « c'est le GC »), vous obtenez des preuves comme « 45 % des échantillons CPU étaient dans le parsing JSON » ou « la plupart des requêtes sont bloquées sur un mutex ». Cela réduit la prochaine étape à un ou deux correctifs concrets.

Types courants utilisables en production

• Profilage CPU : montre quel code s'exécute on‑CPU.
• Profilage off‑CPU (wait) : montre où les threads passent du temps bloqués (attente I/O, ordonnanceur, sleep, réseau, disque).
• Profilage de verrous : montre la contention — le temps perdu en attente de verrous, mutex et verrous lecture/écriture.

Chacun répond à une question différente. Une latence élevée avec un faible CPU pointe souvent vers du off‑CPU ou de la contention de verrous plutôt que des hotspots CPU.

Toujours actif vs à la demande

• Profilage toujours actif (continu, faible overhead) aide pour les mystères « c'est arrivé à 3h du matin » car vous pouvez revenir en arrière.
• Profilage à la demande est une capture ciblée pendant un pic. C'est plus simple à adopter, mais il faut être prêt à le déclencher rapidement.

Beaucoup d'équipes commencent par du profiling à la demande, puis passent au toujours‑actif une fois qu'elles ont confiance dans la sécurité et voient des problèmes récurrents.

Sécurité : overhead, échantillonnage et fenêtres courtes

Le profilage sûr en production consiste à contrôler le coût. Préférez l'échantillonnage (ne tracez pas chaque événement), gardez les fenêtres de capture courtes (par ex. 10–30 secondes) et mesurez l'overhead sur un canari d'abord. Si vous doutez, commencez avec un échantillonnage basse fréquence et augmentez seulement si le signal est trop bruité.

Flame graphs : comment les lire et éviter les conclusions hâtives

Les flame graphs visualisent où le temps échantillonné a été passé pendant une fenêtre de profilage. Chaque « boîte » est une fonction (ou une frame de pile), et chaque pile montre comment l'exécution a atteint cette fonction. Ils sont excellents pour repérer rapidement des patterns — mais ils ne disent pas automatiquement « le bug est ici ».

Ce qu'un flame graph montre (et ne montre pas)

Un flame graph représente généralement des échantillons on‑CPU : le temps pendant lequel le programme tournait réellement sur un cœur CPU. Il peut mettre en évidence des chemins CPU lourds, un parsing inefficace, une sérialisation excessive ou des hotspots qui brûlent réellement du CPU.

Il ne montre pas directement l'attente sur disque, réseau, ordonnanceur ou le temps bloqué sur un mutex (ce sont des temps off‑CPU et nécessitent un autre type de profilage). Il ne prouve pas non plus la causalité pour la latence utilisateur à moins que vous ne le rattachiez à un symptôme cadré.

Lire largeur et profondeur de pile

• Largeur : fréquence d'apparition du frame dans les échantillons. Plus large signifie généralement « plus de temps CPU », mais seulement pour la fenêtre temporelle sélectionnée.
• Profondeur de pile : profondeur d'appel. Les piles profondes ne sont pas intrinsèquement mauvaises ; ce qui compte, c'est quels chemins dominent et s'ils correspondent au travail qui vous importe.

Pièges courants à éviter

La boîte la plus large est tentante à blâmer, mais demandez‑vous : est‑ce un hotspot modifiable ou simplement du « temps passé dans malloc, GC ou logging » parce que le vrai problème est en amont ? Faites aussi attention au contexte manquant (JIT, inlining, symboles) qui peut faire ressembler une boîte au coupable alors qu'elle n'est que la messagère.

Associez les flame graphs à une question précise

Traitez un flame graph comme la réponse à une question cadrée : quel endpoint, quelle fenêtre, quels hôtes, et qu'est‑ce qui a changé. Comparez des flame graphs « avant vs après » (ou « sain vs dégradé ») pour le même chemin de requête afin d'éviter le bruit de profilage.

Off‑CPU : la source cachée de la latence

Quand la latence grimpe, beaucoup d'équipes regardent d'abord le % CPU. C'est compréhensible — mais cela pointe souvent dans la mauvaise direction. Un service peut être « seulement à 20 % CPU » et pourtant très lent si ses threads passent la plupart de leur temps à ne pas s'exécuter.

Pourquoi le % CPU est trompeur

Le % CPU répond à « à quel point le processeur est occupé ? » Il n'indique pas « où est passé le temps de ma requête ? » Les requêtes peuvent stagner pendant que les threads attendent, sont bloqués ou parkés par l'ordonnanceur.

Idée clé : le temps horloge d'une requête inclut à la fois le travail on‑CPU et l'attente off‑CPU.

Coupables off‑CPU courants

Le temps off‑CPU se cache souvent derrière des dépendances et de la contention :

• I/O disque : lectures/écritures synchrones, fsync, stockage lent, défauts de cache de pages.
• Attentes réseau : résolutions DNS, retransmissions TCP, services en aval surchargés.
• Contention sur verrous/mutex : threads bloqués sur des verrous, read/write latches, contention d'allocateur.
• Mise en file d'attente : attente dans des pools de threads, pools de connexions ou files internes.

Symptômes à surveiller

Quelques signaux souvent corrélés aux goulets off‑CPU :

• temps de queue en hausse (requêtes qui attendent avant de commencer à s'exécuter)
• augmentation des threads en état runnable (plus de compétition pour le CPU)
• I/O wait élevé et latences disque/réseau allongées

Ces symptômes indiquent « on attend », mais pas quoi on attend.

Comment le profilage off‑CPU montre « où est passé le temps »

Le profilage off‑CPU attribue le temps à la raison pour laquelle vous n'étiez pas en exécution : bloqué dans des syscalls, attente sur des verrous, en sleep, ou désordonnancé. C'est puissant pour la latence car ça transforme des ralentissements vagues en catégories actionnables : « bloqué sur le mutex X », « attente sur read() depuis le disque », ou « bloqué dans connect() vers un upstream ». Une fois que vous pouvez nommer l'attente, vous pouvez la mesurer, la confirmer et la corriger.

Confirmer le goulet d'étranglement par des preuves, pas par l'intuition

Le travail de performance échoue souvent au même moment : quelqu'un repère une métrique suspecte, la déclare « le problème » et commence à tweaker. Les méthodes de Gregg vous poussent à ralentir et prouver ce qui limite le système avant de changer quoi que ce soit.

Goulet, hotspot et bruit

Un goulet d'étranglement est la ressource ou le composant qui actuellement plafonne le débit ou cause la latence. Si vous le soulagez, les utilisateurs voient une amélioration.

Un hot spot est l'endroit où le temps est passé (par ex. une fonction fréquentée dans un profil). Les hotspots peuvent être de réels goulets — ou simplement du travail occupé qui n'affecte pas le chemin lent.

Le bruit est tout ce qui semble significatif mais ne l'est pas : jobs en arrière‑plan, pics isolés, artefacts d'échantillonnage, effets de cache, ou « top talkers » qui ne corrèlent pas avec le problème visible par l'utilisateur.

Prouvez‑le avec des comparaisons et des changements contrôlés

Commencez par capturer un instantané propre avant : le symptôme utilisateur (latence ou taux d'erreur) et les signaux candidats (saturation CPU, profondeur de file, I/O disque, contention de verrous, etc.). Puis appliquez un changement contrôlé qui devrait n'affecter que la cause suspectée.

Exemples de tests causals :

• Ajouter de la capacité à la ressource suspecte (un worker de plus, plus de parts CPU, pool de connexions plus grand) et vérifier si la latence s'améliore.
• Réduire temporairement la demande (limiter un endpoint bruyant, rejouer une charge plus petite) et voir si la contrainte suspecte se relâche.

La corrélation est un indice, pas un verdict. Si « le CPU monte quand la latence monte », vérifiez en changeant la disponibilité CPU ou en réduisant le travail CPU et observez si la latence suit.

Documentez ce que vous avez prouvé

Notez : ce qui a été mesuré, le changement exact, les résultats avant/après et l'amélioration observée. Cela transforme une victoire ponctuelle en playbook réutilisable pour le prochain incident — et empêche l'« intuition » de réécrire l'histoire plus tard.

Construire un flux de travail répétable pour les incidents de performance

Les incidents de performance paraissent urgents, c'est précisément quand les suppositions s'invitent. Un flux de travail léger et répétable vous aide à passer de « quelque chose est lent » à « nous savons ce qui a changé » sans tourner en rond.

La boucle d'incident : détecter → trier → mesurer → corriger

Détecter : alerter sur latence et taux d'erreur visibles par l'utilisateur, pas seulement sur le CPU. Pager quand la p95/p99 dépasse un seuil pendant une fenêtre soutenue.

Trier : répondez immédiatement à trois questions : qu'est‑ce qui est lent, quand ça a commencé, et qui est affecté ? Si vous ne pouvez pas nommer la portée (service, endpoint, région, cohorte), vous n'êtes pas prêt à optimiser.

Mesurer : collectez des preuves qui restreignent le goulet. Préférez des captures bornées dans le temps (ex. 60–180 secondes) pour pouvoir comparer « mauvais » vs « bon ».

Corriger : changez une chose à la fois, puis re‑mesurez les mêmes signaux pour confirmer l'amélioration et écarter l'effet placebo.

Standardisez un petit ensemble de graphiques

Gardez un dashboard partagé que tout le monde utilise pendant les incidents. Rendez‑le ennuyeux et cohérent :

• Latence : p50 / p95 / p99 (par endpoint critique)
• Signaux RED : Rate, Errors, Duration (vue service‑first)
• Quelques métriques USE : utilisation, saturation, erreurs pour CPU, disque et réseau

Le but n'est pas de tout grapher ; c'est de raccourcir le temps pour obtenir le premier fait.

Définissez des « golden signals » par endpoint critique

Instrumentez les endpoints qui comptent vraiment (checkout, login, recherche), pas chaque endpoint. Pour chacun, convenez : p95 attendu, taux d'erreur maximal, et dépendance clé (DB, cache, tiers).

Décidez quoi capturer pendant les incidents

Avant la prochaine panne, mettez d'accord un kit de capture :

• Profils (CPU et off‑CPU), plus flame graphs
• Traces pour les endpoints lents
• Logs d'erreurs/timeouts (échantillonnés)

Documentez‑le dans un runbook court (ex. /runbooks/latency), incluant qui peut lancer les captures et où stocker les artefacts.

Où Koder.ai s'intègre dans un flux de travail à la Gregg

La méthodologie de Gregg repose sur le changement contrôlé et la vérification rapide. Si votre équipe construit des services avec Koder.ai (plateforme chat‑driven pour générer et itérer des applis web, backend et mobiles), deux fonctionnalités s'alignent naturellement :

• Planning Mode vous aide à transformer « peut‑être c'est X » en une hypothèse explicite et un petit jeu de changements testables avant de toucher la production.
• Snapshots et rollback permettent des expériences sûres à variable unique : appliquez un changement, re‑mesurez les signaux RED/USE, et revenez en arrière rapidement si les preuves disent « non ».

Même si vous ne générez pas de code pendant un incident, ces habitudes — petits diffs, résultats mesurables et réversibilité rapide — sont les mêmes que Gregg recommande.

Un guide pratique : du pic de latence à la correction vérifiée

Scénario : le p99 bondit au pic de trafic

Il est 10h15 et votre dashboard montre le p99 de l'API passant d'environ 120 ms à ~900 ms pendant le pic. Le taux d'erreur est stable, mais des clients signalent des requêtes « lentes ».

Étape 1 — Commencez par RED pour cerner l'impact utilisateur

Commencez par le service : Rate, Errors, Duration.

Vous tranchez la Duration par endpoint et voyez une route qui domine le p99 : POST /checkout. Le débit a doublé, les erreurs sont normales, mais la Duration augmente spécifiquement quand la concurrence monte. Cela pointe vers la mise en file ou la contention, pas un échec total.

Ensuite, vérifiez si la latence est du temps de calcul ou d'attente : comparez le « handler time » applicatif au temps total de requête (ou spans upstream vs downstream si vous avez du tracing). Le handler est court, le temps total est long — les requêtes attendent.

Étape 2 — Appliquez USE aux hôtes suspects

Inventoriez les goulets probables : Utilisation, Saturation, Erreurs pour CPU, mémoire, disque et réseau.

L'utilisation CPU est seulement ~35 %, mais la run queue CPU et les switches de contexte montent. Disque et réseau semblent stables. Ce décalage (CPU bas, forte attente) est un indice classique : les threads ne brûlent pas du CPU — ils sont bloqués.

Étape 3 — Choisissez le profilage selon les symptômes

• Si le CPU est élevé : utilisez un profil CPU (flame graphs on‑CPU) pour voir où le temps est passé.
• Si les requêtes attendent : utilisez un profil off‑CPU pour voir pourquoi les threads sont bloqués (verrous, I/O, ordonnanceur).

Vous capturez un profil off‑CPU durant le pic et trouvez beaucoup de temps passé dans un mutex autour d'un cache partagé de « validation de promotion ».

Étape 4 — Corrigez puis vérifiez

Vous remplacez le verrou global par un verrou par‑clé (ou un chemin de lecture sans verrou), déployez et observez le p99 revenir à la normale alors que le débit reste élevé.

Checklist post‑incident :

• Enregistrer les symptômes RED exacts et l'endpoint ciblé.
• Sauvegarder le profil et la fenêtre temporelle.
• Ajouter une alerte pour le signal de saturation spécifique (ex. temps d'attente sur verrou / run queue).
• Noter la « prochaine question à poser » si ça se reproduit.