Parca Agent - Always-On eBPF Continuous Profiling Cheatsheet
Parca Agent is an eBPF-based continuous profiler. Rather than attaching a profiler when you suspect a problem, it samples stack traces from every process on a node, all the time, at roughly 1% overhead and with zero application instrumentation. That inverts the usual workflow: instead of reproducing an incident under a profiler, you look up what was actually running during the incident window. It attributes CPU (and memory, for supported runtimes) down to the line number and ships profiles to a Parca server or any Prometheus-compatible profile store.
Requirements
- Linux kernel with eBPF/BTF (5.4+, newer preferred)
- Root / privileged container
- Parca server (or compatible store) to receive profiles
Installation
| Method | Command |
|---|
| Binary | download from GitHub Releases |
| Docker | docker run --privileged ghcr.io/parca-dev/parca-agent:latest |
| Kubernetes | Deploy as a DaemonSet (manifests provided) |
| Server | run parca separately to store/query profiles |
| Verify | parca-agent --version |
Running
sudo parca-agent \
--node=my-node-1 \
--remote-store-address=parca.internal:7070 \
--remote-store-insecure
| Flag | Purpose |
|---|
--node | Node label attached to profiles |
--remote-store-address | Where to ship profiles |
--http-address | Local UI/metrics endpoint (:7071) |
--profiling-duration | Sampling window (default 10s) |
--log-level | Verbosity |
Kubernetes DaemonSet
| Aspect | Note |
|---|
| Deployment | One agent per node |
| Privileges | privileged: true, hostPID |
| Discovery | Automatically labels by pod/container/namespace |
| Overhead | ~1% CPU typical |
| Storage | Profiles go to the Parca server, not the node |
Language Support
| Runtime | Stack unwinding |
|---|
| C/C++/Rust/Go | Native (DWARF or frame pointers) |
| Java | JIT symbol resolution |
| Python / Ruby | Interpreter-aware unwinding |
| Node.js | Supported via runtime unwinding |
| Any binary with symbols | Best results when not stripped |
Mixed-language stacks resolve in one profile, which is exactly what you need for a polyglot service.
Querying Profiles
Parca’s UI (and API) lets you slice profiles like metrics:
| Query dimension | Example |
|---|
| Time range | The 5 minutes around an incident |
| Labels | namespace="prod", pod=~"api-.*" |
| Comparison | Diff two time ranges (before/after a deploy) |
| Function | Filter to a symbol |
# Conceptual: CPU profile for one service during a spike
cpu_samples{namespace="prod", container="api"} [14:05 → 14:10]
The Killer Feature: Comparison
| Use | How |
|---|
| Regression hunt | Diff profiles before vs after a release |
| Incident analysis | Diff incident window vs baseline |
| Optimization proof | Show the hot function shrank |
Continuous profiling makes this possible because the “before” profile already exists — you did not need to predict you would want it.
| Aspect | Parca Agent | perf | Pyroscope | async-profiler |
|---|
| Model | Always-on, fleet-wide | On-demand, per-run | Always-on | On-demand, JVM |
| Instrumentation | None (eBPF) | None | Agent/SDK options | JVM agent |
| Multi-language | Yes | Yes (native) | Yes | JVM only |
| Best for | Production continuous profiling | Deep local analysis | Continuous profiling | JVM accuracy |
Same category as Pyroscope; use perf or async-profiler when you need deep one-off analysis.
Resources
