Habr décortique l'auto-instrumentation des APM : où se perdent les 4 secondes d'une requête

Une requête met 4 secondes à s'exécuter. Dans un monolithe, le développeur activerait un profileur et trouverait la méthode coûteuse en une soirée. Dans un système où la requête traverse une API Gateway, plusieurs microservices, une file de messages, une base de données et une API externe, un profileur sur une seule machine n'en montre qu'un fragment. Habr a publié une analyse de la façon dont un APM répond à la question « où est passé le temps » grâce au tracing distribué et à l'instrumentation automatique.

Trace et span : comment se construit la vue d'ensemble

En distributed tracing, chaque requête est représentée par une trace, c'est-à-dire son parcours complet à travers tous les composants. La trace se découpe en spans : chaque appel individuel côté front, côté back ou sur le bus reçoit son propre intervalle de temps. Un span possède un identifiant, une référence à son parent, une heure de début et une durée. Ces liens permettent de reconstituer l'arbre des appels.

Pour que les spans de services différents atterrissent dans le même arbre, le contexte doit voyager avec la requête. Aujourd'hui, il s'agit généralement de l'en-tête traceparent défini par le standard W3C Trace Context. Il contient l'identifiant de la trace (16 octets), l'identifiant du span courant (8 octets) et des drapeaux, par exemple l'indicateur d'échantillonnage. Le service reçoit l'en-tête, crée un span enfant et transmet le contexte plus loin.

Comment fonctionne l'auto-instrumentation

La méthode manuelle consiste, pour le développeur, à envelopper les appels dans du code de tracing dans chaque service. Dans des équipes qui gèrent des dizaines de services, cela devient vite une dette. L'auto-instrumentation supprime ce travail : un agent se branche sur le runtime et ajoute lui-même des mesures autour des bibliothèques connues.

Les mécanismes dépendent de la plateforme :

• Java : l'agent, chargé via -javaagent et java.lang.instrument, modifie le bytecode au chargement des classes, souvent à l'aide d'ASM ou de Byte Buddy.
• .NET : on utilise le Profiling API du CLR.
• Python et Node.js : les fonctions des bibliothèques populaires sont remplacées (monkey-patching, hooks de chargement de modules).
• Go et les langages compilés : on recourt plutôt à eBPF ou à des wrappers manuels, car le runtime se prête moins à la modification.

L'agent connaît les points typiques : serveurs et clients HTTP, pilotes de bases de données, clients de files de messages. Il n'a pas besoin de comprendre la logique métier pour mesurer une requête entrante, une requête SQL ou la publication d'un message. Ces mesures donnent naissance à des spans, envoyés à un collecteur puis vers le stockage de l'APM.

Les limites de cette approche

L'auto-instrumentation ne voit que ce qui a été décrit à l'avance. Si le temps part dans un algorithme maison à l'intérieur d'une méthode, dans un verrou sur une ressource partagée ou dans un pool de threads, les hooks standard n'affichent qu'un seul long span, sans explication. Des spans supplémentaires autour des sections critiques et le profilage des threads aident alors.

Les coûts de fonctionnement forment un sujet à part. L'agent ajoute du travail à chaque appel, c'est pourquoi le tracing est presque toujours associé à de l'échantillonnage. Le head-based décide du sort de la trace au début de la requête et coûte peu. Le tail-based décide une fois la requête terminée : il conserve donc les requêtes lentes et en erreur, mais exige une mise en tampon dans le collecteur.

En pratique : par où commencer

Si le système compte plus de trois ou quatre services et que les incidents sont analysés à la main dans les logs, mieux vaut commencer par un ensemble minimal d'étapes :

• Activer l'auto-instrumentation sur un seul chemin critique, par exemple la validation de commande, plutôt que sur toute l'infrastructure d'un coup.
• Vérifier la transmission de bout en bout de traceparent à travers la passerelle, les files de messages et les handlers asynchrones : c'est là que les traces se rompent le plus souvent.
• Ajouter à la main des spans autour des zones où l'agent automatique affiche une « boîte noire ».
• Configurer l'échantillonnage pour que les requêtes lentes (par exemple au-dessus du p95) soient toujours conservées.
• Recouper le résultat avec les métriques et les logs via un trace ID commun, pour que le passage d'un signal à l'autre prenne quelques secondes.

Cette approche remplace le constat « le système rame » par des faits précis : 3,1 secondes sont parties dans l'API externe, 0,6 dans la requête à la base, le reste dans la file de messages. L'optimisation commence là, et non par des suppositions.