Instrumentation eBPF sans code pour le proxy TCP Envoy via Beyla

Résumé Rapide

L'article explore l'intégration de Beyla avec Envoy pour réaliser une instrumentation sans code en utilisant eBPF. Cette méthode permet aux développeurs de surveiller les proxies TCP sans modifier le code source ni redémarrer les processus.

Les résultats clés incluent la capacité de capturer automatiquement les métriques et les traces TCP. Cependant, l'approche présente des limites distinctes concernant les protocoles de plus haut niveau comme HTTP/2 et gRPC, qui ne sont pas inspectables via cette méthode.

L'implémentation repose sur l'attachement de programmes eBPF au processus Envoy. Cela offre une visibilité réseau approfondie tout en maintenant une faible surcharge, ce qui le rend adapté aux environnements de production.

Comprendre l'Instrumentation Sans Code

L'instrumentation sans code désigne la capacité de surveiller une application sans modifier son code source ni nécessiter un redémarrage. La surveillance traditionnelle demande souvent aux développeurs d'importer des bibliothèques ou des SDK spécifiques, ce qui peut être difficile pour les systèmes hérités ou les binaires tiers comme Envoy.

En tirant parti d'eBPF (extended Berkeley Packet Filter), les outils peuvent s'interfacer avec le noyau Linux pour observer les appels système et l'activité réseau. Cela permet l'extraction de données de télémétrie—telles que les durées de requêtes et les comptages d'octets—directement depuis le processus en cours d'exécution.

L'avantage principal de cette approche est l'agilité. Les équipes d'exploitation peuvent déployer des agents d'observabilité sur l'infrastructure existante immédiatement, contournant les longs cycles de développement associés à l'instrumentation basée sur le code.

Intégration de Beyla et Envoy

L'article démontre comment Beyla, un outil d'auto-instrumentation basé sur eBPF, est configuré pour fonctionner avec un proxy TCP Envoy. Beyla fonctionne en identifiant le processus Envoy et en se rattachant aux fonctions réseau spécifiques à l'intérieur du binaire.

Pour y parvenir, l'outil nécessite une configuration spécifique pour cibler l'application correcte. Pour Envoy, Beyla surveille les sockets TCP pour générer des métriques. Le processus implique les étapes suivantes :

1. Trouver l'ID du processus Envoy.
2. Configurer Beyla pour tracer les connexions TCP.
3. Exporter les données collectées vers un backend d'observabilité.

Cette configuration permet la capture de traces réseau détaillées, permettant aux utilisateurs de visualiser le flux du trafic à travers le proxy sans toucher aux fichiers de configuration d'Envoy.

Limites et Capacités des Protocoles

Bien que l'intégration offre une observabilité TCP robuste, l'article souligne des contraintes importantes concernant le support des protocoles. Spécifiquement, Beyla ne peut pas inspecter la charge utile du trafic HTTP/2 ou gRPC lorsqu'il fonctionne en mode sans code.

Parce que ces protocoles reposent sur des couches d'encadrement binaires plutôt que sur du texte clair, les sondes eBPF attachées au niveau du socket ne peuvent pas décoder facilement la sémantique requête/réponse. Par conséquent, les utilisateurs verront les métriques de connexion TCP (telles que les temps de poignée de main et les volumes de transfert de données) mais manqueront des codes de statut HTTP spécifiques ou des noms de méthodes gRPC.

Malgré cette limitation, l'outil reste très efficace pour :

• Les applications héritées où la modification du code est impossible.
• Les services tiers manquant de support d'instrumentation.
• Les environnements à haute performance nécessitant une surcharge minimale.

Conclusion

L'utilisation d'eBPF pour l'instrumentation sans code représente un changement significatif dans la manière dont l'observabilité est atteinte pour les composants d'infrastructure comme Envoy. En utilisant Beyla, les équipes peuvent obtenir des informations immédiates sur les modèles de trafic TCP sans la charge opérationnelle des modifications de code.

Cependant, l'incapacité à décoder les charges utiles HTTP/2 et gRPC signifie que cette approche est mieux adaptée à la surveillance au niveau TCP ou aux scénarios où les détails du protocole de haut niveau sont secondaires par rapport au comportement du réseau. À mesure que la technologie évolue, il est probable que le support pour des protocoles plus complexes s'étendra, réduisant davantage l'écart entre l'observabilité gérée et non gérée.