// the find
parca-dev/parca
Continuous profiling for analysis of CPU and memory usage, down to the line number and throughout time. Saving infrastructure cost, improving performance, and increasing reliability.
Parca is a continuous profiling backend that collects CPU and memory profiles from your whole infrastructure using an eBPF agent, stores them in a custom columnar format, and lets you query flamegraphs over arbitrary time ranges. It's the open-source core of what Polar Signals sells commercially, aimed at platform engineers who want always-on profiling without instrumenting individual services.
- The eBPF agent auto-discovers processes from Kubernetes or systemd with zero application-side changes — one binary per node, no sidecars, no pprof endpoints to add
- Uses pprof as both its ingestion format and its native format, which means any language with a pprof library can push profiles to it and existing Go tooling (pprof CLI, Pyroscope exporters) works unmodified
- Custom Apache Arrow columnar storage (pkg/parcacol) instead of storing raw blobs — this is the right call for time-range queries and aggregations across millions of samples, and it shows the team understood the query patterns before picking the storage model
- Symbolization pipeline is unusually complete: DWARF parsing, debuginfod upstream integration, addr2line fallback, C++ demangling with multiple modes — most OSS profilers paper over at least one of these
- In-memory storage by default with a 512MB hard cap; persistence requires --enable-persistence with a WAL that's clearly still experimental — restart without it in production and you lose your entire profiling history
- The eBPF profiler is a separate repo (parca-agent) and a separate binary with its own config, so the 'zero instrumentation, single deploy' pitch requires deploying and managing two things
- --profile-share-server defaults to api.pprof.me:443, meaning the share-profile feature routes your profiling data (exact function names, hot paths) to an external third-party service unless you explicitly set a different address
- No authentication or multi-tenancy in the OSS build — the gRPC API is open, so any production deployment needs a reverse proxy doing auth in front of it, which the docs don't emphasize nearly enough