La manière traditionnelle de profiler un problème de production a une dépendance maladroite : vous devez déjà le soupçonner. Quelque chose semble lent, vous attachez un profileur, vous essayez de reproduire la condition, et — si vous avez de la chance et que le problème se reproduit toujours — vous capturez les données. Le mode d'échec est évident et courant. L'incident s'est produit à 3 h du matin, il a duré quatre minutes, et au moment où quelqu'un a regardé, la preuve avait disparu. Vous ajoutez la journalisation, espérez qu'il se reproduira, et attendez.
eBPF a changé l'économie assez pour inverser ce flux de travail. Parce que les programmes eBPF s'exécutent à l'intérieur du noyau dans un sandbox vérifié, ils peuvent observer les syscalls, la planification, et les traces de pile sur tous les processus d'une machine à une surcharge assez basse — de manière cohérente moins de 1% — pour rester en exécution permanente. Cela transforme le profilage de quelque chose que vous commencez en quelque chose que vous interrogez : les données pour 3 h du matin existent déjà. Ce guide couvre ce changement via Parca Agent pour le profilage continu, et une application plus nouvelle qui a émergé à mesure que les agents autonomes prolifèrent — utiliser la même visibilité au niveau noyau pour voir ce qu'un agent IA a réellement fait, via des outils comme AgentSight.
Pourquoi eBPF a Rendu le Toujours-Activé Viable
La raison technique pour laquelle le profilage continu était impratique avant est que les anciennes options imposaient toutes une taxe que vous ne paieriez pas de manière permanente. Les profileurs d'échantillonnage basés sur perf sont bon marché mais nécessitent une configuration par cible et produisent les données que vous devez gérer vous-même. Les profileurs instrumentés nécessitent des changements de code et ajoutent la surcharge par appel. Les agents spécifiques au langage couvrent un runtime et introduisent souvent leur propre coût de performance. Aucun d'eux n'était des choses que vous exécuteriez sur tous les processus sur tous les nœuds pour toujours.
La contribution d'eBPF est que les programmes s'exécutent dans l'espace noyau, donc la collecte d'une trace de pile ne nécessite pas de basculer de contexte vers un agent userspace pour chaque échantillon, et le vérificateur du noyau prouve statiquement que le programme ne peut pas planter le système ou boucler pour toujours avant qu'il ne soit autorisé à se charger. Le résultat est une visibilité au niveau du noyau avec des garanties de sécurité et une surcharge dans le bruit. De manière cruciale, c'est également zéro instrumentation : vous ne modifiez pas, recompilez ou redémarrez les applications en cours de profil, ce qui supprime la friction organisationnelle qui a tué la plupart des tentatives précédentes (« nous aurions besoin que chaque équipe ajoute un agent »).
Il y a un vrai prérequis valant la peine de mentionner : cela dépend d'un noyau raisonnablement moderne avec le support BTF, et la qualité du déroulement de pile dépend de vos binaires ayant les symboles. Les binaires de production dépouillés produisent des profils pleins d'adresses hexadécimales, ce qui est un problème soluble mais un que vous devriez résoudre avant de conclure que l'outil ne fonctionne pas.
Profilage Continu en Pratique
Parca Agent est l'expression la plus claire de l'idée. Déployé en tant que DaemonSet sur Kubernetes (ou un processus sur un nœud), il échantillonne les traces de pile de tous les processus sur ce nœud, en continu, les étiquette avec les métadonnées pod, conteneur et namespace, et les envoie à un serveur où ils sont stockés comme des métriques — interrogeables par plage de temps et étiquette.
Ce modèle de stockage est ce qui le rend utile plutôt que simplement intéressant. Parce que les profils sont des séries temporelles étiquetées, vous pouvez poser des questions que le profilage à la demande ne peut pas répondre. Qu'était-ce qui consommait le CPU dans le namespace des paiements entre 03 h 04 et 03 h 08 ? Le profil existe ; vous filtrez sur la fenêtre. Encore plus précieuse est la comparaison : comparez le profil d'avant un déploiement contre après, et la régression apparaît comme une fonction qui a grandi. Vous n'aviez pas besoin de prédire que vous voudriez le profil « avant » — la collection continue signifie qu'il est toujours là.
Parca gère les piles multilingues, ce qui compte plus qu'il n'y paraît. Un service moderne pourrait être Go appelant dans les bibliothèques C, ou Python invoquant les extensions natives, et un profil qui ne résout qu'une couche raconte une histoire trompeuse. Le déroulement au niveau du noyau voit la pile entière. Pour l'analyse approfondie unique, vous atteindrez toujours perf ou async-profiler — le profilage continu optimise pour la couverture et l'historique, pas la profondeur maximale par exécution — mais la question de tous les jours « sur quoi ce cluster dépense-t-il CPU » est répondue en continu et à bas coût.
Le Problème Plus Nouveau : Qu''a Fait l''Agent ?
L'application secondaire est plus nouvelle et, en 2026, de plus en plus pressante. Les équipes exécutent des agents de codage autonomes et des agents LLM avec accès aux outils sur des systèmes réels. L'observabilité que ces systèmes fournissent est au niveau application : invites, appels d'outils, nombres de jetons, portées. Les outils comme Langfuse et Arize Phoenix le font bien et sont véritablement utiles pour comprendre le raisonnement d'un agent.
Mais le suivi au niveau application a une limitation structurelle : il montre ce que le cadre de l'agent a choisi de signaler. Si un outil exécute une commande shell, la trace enregistre la chaîne de commande — pas les dix-sept processus que la commande a générés, les fichiers qu'ils ont touchés ou l'hôte qu'ils ont contacté. Si l'agent est compromis par l'injection d'invite et prend une action en dehors de sa portée prévue, la trace montre l'action qu'il a narrée, ce qui est exactement la mauvaise source de vérité pour une question de sécurité.
AgentSight applique eBPF ici : observer le comportement système réel de l'agent au niveau du noyau — exécution de processus, accès au fichier, connexions réseau — sans instrumentation de l'agent du tout. L'agent ne peut pas omettre ou signaler ces événements de manière incorrecte parce qu'il n'est pas celui qui les signale. Pour un agent de codage opérant sur un dépôt, vous obtenez la vraie réponse à « quels fichiers a-t-il modifiés », « qu'a-t-il exécuté », et « a-t-il atteint en dehors de l'espace de travail ».
La posture correcte est que ce sont des couches complémentaires, pas des concurrents. Le suivi application vous dit l'intention et le raisonnement de l'agent ; le suivi du noyau vous dit ses effets. Les corréler par horodatage vous donne les deux moitiés : c'est ce que l'agent essayait de faire, et c'est ce qui s'est réellement passé sur la machine. Pour n'importe quoi avec des permissions réelles, avoir seulement la première moitié est un écart.
Sécurité, Pas Seulement Performance
Ce cadrage pointe vers l'utilisation plus large. La même fondation eBPF soutend les outils de sécurité d'exécution — Tracee, Falco, Tetragon — qui regardent le comportement du noyau suspect et, dans le cas de Tetragon, peuvent appliquer la politique in-kernel. Une fois que vous collectez les événements de processus, de fichier et de réseau sur tous les nœuds, la différence entre « observabilité » et « détection » est surtout quelle question vous posez des données.
Pour les charges de travail d'agent spécifiquement, cette convergence est utile. Les questions « pourquoi ceci est lent », « qu'a changé l'agent » et « quelque chose a-t-il échappé à son sandbox » sont toutes répondues à partir du même flux d'événements. Pratiquement, cela signifie qu'une organisation déployant des agents avec accès système devrait traiter la visibilité au niveau du noyau comme partie du déploiement, pas un après-coup — c'est le seul niveau qui produit des preuves auditables de ce qu'un processus autonome a réellement fait.
L'avertissement honnête est le volume. Le suivi au niveau du noyau peut générer des flux d'événements énormes, et la journalisation naïve de chaque syscall sur un nœud occupé submergera votre stockage et votre capacité à trouver quelque chose. Le filtrage à la source — par chemin, par processus, par type d'événement — n'est pas une optimisation mais une exigence, et c'est où vit la plupart du travail opérationnel dans ces outils.
Lire un Profil Sans Se Tromper
Le profilage continu produit beaucoup de données, et il y a quelques moyens fiables de le mal lire. Utile de savoir avant d'agir sur un graphique de flamme.
La largeur est des échantillons, pas de la latence en temps réel. Un profil CPU montre où le temps CPU a été dépensé. Si votre service est lent parce qu'il est attente — sur une base de données, un verrou, un appel réseau — le profil CPU peut sembler parfaitement sain, parce qu'un thread bloqué ne consomme pas de CPU. C'est le diagnostic erroné unique le plus courant : conclure qu'il n'y a pas de problème parce que le profil CPU est plat, quand le problème est le temps CPU hors-ligne. Le profilage en temps réel ou hors-CPU répond plutôt à cette question.
Les hotspots agrégés ne sont pas nécessairement votre problème de latence. Une fonction consommant 30% du CPU du cluster peut être entièrement du travail d'arrière-plan attendu — sérialisation, compression, garbage collection. Le signal intéressant est généralement un changement : cette fonction était 5% la semaine dernière et est 30% maintenant. C'est pourquoi la comparaison compte plus que le classement absolu, et pourquoi la collection continue bat un snapshot unique.
La qualité des symboles façonne les conclusions. Les symboles manquants font effondrer les piles en adresses hexadécimales inutiles, et pire, ils peuvent mal attribuer le temps à la trame résoluble la plus proche — produisant une réponse confiante et mauvaise. Si un profil blâme une fonction qui n'a aucun sens, soupçonnez le déroulement avant de soupçonner le code.
L'échantillonnage a un sol. Une fonction qui s'exécute fréquemment mais très brièvement peut être sous-représentée par rapport à son vrai coût, et les événements rares mais chers peuvent ne pas apparaître du tout dans une courte fenêtre. La collection continue l'atténue en agrégation sur les longues périodes, qui est un autre argument pour toujours-activé plutôt que à la demande.
L'habitude pratique : utilisez le profil pour former une hypothèse, puis confirmez-la avec une mesure ciblée avant de passer un sprint à optimiser.
Adopter Ceci Judicieusement
Une séquence pragmatique évite l'échec courant du déploiement de tout et de la noyade. Commencez par le profilage continu sur un sous-ensemble de nœuds. C'est l'introduction à risque minimal, livre la valeur immédiatement (vous trouverez quelque chose de surprenant dans la première semaine), et vous enseigne comment vos noyaux et symboles se comportent avant que quelque chose ne dépend de cela. Confirmez que les piles se résolvent en vrais noms de fonction ; corrigez la disponibilité des symboles s'ils ne le font pas.
Ensuite, ajoutez des flux de travail de comparaison, parce que c'est où la retombée se concentre : câblez la comparaison de profils dans votre processus de version pour qu'une régression CPU soit capturée en tant que changement de profil plutôt que comme une alerte de latence trois jours plus tard.
Ajoutez le suivi au niveau agent quand vous exécutez réellement des agents avec accès système. Si vos agents n'appellent que les API et retournent du texte, le suivi du noyau est excessif. S'ils exécutent des commandes, écrivent des fichiers ou opèrent sur des dépôts, l'écart de visibilité est réel et vaut la peine d'être fermé.
Et filtrez agressivement dès le départ. Décidez d'avance quels chemins, processus et types d'événements comptent, et excluez le reste. Il est beaucoup plus facile d'élargir un filtre étroit plus tard que de rétro-adapter le filtrage à un firehose que vous stockez déjà.
Enfin, gardez les outils à la demande tranchants. Le profilage continu vous dit que une fonction est devenue hot et quand ; perf, bpftrace et async-profiler restent meilleur pour la plongée profonde dans pourquoi. Le flux de travail qui fonctionne est les données continues pour la détection et l'historique, les outils ciblés pour le diagnostic.
Le Point Final
eBPF a déplacé l'observabilité de « attachez un profileur quand vous soupçonnez un problème » à « les données existent déjà, interrogez-les », parce que l'exécution au côté noyau avec un sandbox vérifié a rendu la collection toujours-activée coûtant moins de 1% et ne nécessitant aucun changement application. Parca Agent livre cela comme du profilage CPU continu interrogeable-par-étiquette et multi-langage dont le vrai superpower est la comparaison avant et après. La nouvelle frontière est d'appliquer la même visibilité aux agents autonomes : AgentSight montre ce qu'un agent a réellement fait au niveau syscall, fermant l'écart laissé par les traces application qui ne rapportent que ce que l'agent a choisi de narrer. Commencez par le profilage sur quelques nœuds, vérifiez vos symboles, intégrez la comparaison dans les versions, ajoutez le suivi d'agent quand les agents touchent les systèmes réels, filtrez dur dès le départ, et gardez perf et bpftrace pour les plongées profondes.
Références et Ressources
Outils
Contexte et Analyse
- 8 Best Open-Source eBPF Tracing Tools in 2026 — Better Stack
- eBPF.io — what is eBPF
- Brendan Gregg on eBPF performance tools
Cheatsheets 1337skills Associées