Broad Language Support
Pyroscope (originally by Grafana Labs, now merged with Grafana Phlare into a unified project) takes a different approach from Parca. Where Parca is eBPF-first, Pyroscope supports both eBPF-based profiling and language-specific SDK agents.
Why offer SDK agents if eBPF is zero-instrumentation?
eBPF sees the world from the kernel's perspective. It knows memory addresses and CPU registers. For compiled languages like Go and Rust, this is sufficient — the binary has stable symbols. But for interpreted or JIT-compiled languages, the kernel cannot see inside the runtime:
- Python: The kernel sees the CPython interpreter's C functions, not your Python function names. A Python SDK agent reads the interpreter's internal frame objects to get real Python stack traces.
- Ruby: Same problem — the kernel sees the MRI interpreter, not Ruby method names.
- Java: The JVM JIT-compiles bytecode at runtime. The kernel cannot unwind JIT frames without JVM cooperation. The Java SDK agent uses the JVM's
AsyncGetCallTraceAPI to get accurate Java stacks.
Grafana Integration:
Pyroscope/Phlare has first-class integration with Grafana. You can correlate profiles directly with metrics and traces:
- Open a Grafana dashboard showing a CPU spike in a metrics panel.
- Click on the spike.
- A linked Flamegraph panel automatically loads the profile for that exact time window.
- You go from "CPU is high" to "this specific function is the cause" in seconds.
This tight integration — metrics, logs, traces, and profiles in one UI — is called Grafana's LGTM stack: Loki (logs), Grafana (visualization), Tempo (traces), Mimir (metrics), with Phlare (profiles) completing the picture.