Zero Instrumentation: No Code Changes Required

No More SDKs

One of the most operationally significant advantages of eBPF-based profilers is that they require no changes to application code. No library imports. No SDK initialization. No restart. No redeployment. You deploy the profiling agent once, and it immediately sees inside every process on the machine — regardless of programming language.

How the agent works in a Kubernetes environment:

1. You deploy the Profiler Agent as a DaemonSet — one pod per node, running with elevated privileges to load eBPF programs.
2. The agent loads an eBPF program that attaches to the perf_event hardware timer at 99 Hz.
3. On every timer tick, the kernel pauses the currently running thread for a few microseconds, records the CPU instruction pointer and the full call stack (as raw memory addresses), and resumes execution.
4. The agent reads these raw addresses from the BPF map.
5. The agent performs stack unwinding and symbolization: it maps raw memory addresses back to human-readable function names like main.processRequest or java.util.HashMap.get. This requires access to debug symbols (DWARF data) for each binary.

The Symbolization Challenge

Symbolization is the hardest part of eBPF profiling. In production, binaries are often stripped of debug symbols to reduce size. Modern profilers solve this in several ways:

• debuginfod: A protocol where the profiler agent fetches debug symbols on demand from a symbol server, keyed by the binary's build ID. Parca uses this extensively.
• Frame pointers: Go and Rust binaries include frame pointers by default, making stack unwinding reliable. Java and Python require language-specific unwinders (e.g., reading the JVM's internal stack structures).
• DWARF-based unwinding: For C/C++ binaries compiled with -g, the agent reads DWARF debug info to reconstruct the call stack even without frame pointers.