Continuous profiling with eBPF

1. Le principe #

Échantillonner les piles d'appels depuis le noyau.

Comment ça marche #

Un programme eBPF attaché à un perf event (par exemple 19 fois par seconde par CPU) lit la pile d'appels du processus en cours, côté noyau et côté utilisateur, et l'agrège dans une map. L'agent remonte périodiquement les piles agrégées, les symbolise et les envoie au serveur.

2. Les outils #

Trois options open source.

Comparatif #

Parca avec Docker #

docker network create prof
docker run -d --name parca --network prof -p 7070:7070 ghcr.io/parca-dev/parca:latest /parca
docker run -d --name parca-agent --network prof --privileged --pid host \
  -v /sys/kernel/debug:/sys/kernel/debug -v /lib/modules:/lib/modules:ro \
  ghcr.io/parca-dev/parca-agent:latest \
  --remote-store-address=parca:7070 --remote-store-insecure

L'interface (http://localhost:7070) affiche les profils CPU de tous les processus, filtrables par labels (comm, conteneur, pod).

À savoir : Les options exactes de l'agent évoluent selon les versions : consultez le README de parca-agent si une option est refusée.

3. Les symboles #

Des noms de fonctions plutôt que des adresses.

Bien symboliser #

• Go, Rust, C/C++ : gardez les tables de symboles (pas de strip, pas de -ldflags="-s -w") ou publiez les fichiers debuginfo.
• Java, Node.js, Python : les agents récents savent dérouler les piles de ces environnements ; vérifiez la liste des runtimes pris en charge par votre agent.
• Parca peut récupérer les symboles depuis un serveur debuginfod pour les paquets des distributions.