// the find
grafana/pyroscope
Continuous Profiling Platform. Debug performance issues down to a single line of code
Grafana Pyroscope is a continuous profiling backend that stores flame graph data from your applications and lets you trace CPU, memory, and I/O bottlenecks down to specific lines of code. Version 2.0 (released this year) rearchitected the storage layer to write directly to object storage, dropping the in-memory ingester tier. It's for teams already running Grafana who want profiling to live alongside their metrics and logs.
The v2 architecture is genuinely well-thought-out: writing profiles straight to object storage means no local disk dependency and horizontal scaling without sticky sessions. The eBPF profiling path via Grafana Alloy requires zero application code changes — useful when you can't or won't instrument services directly. The profilecli tool covers day-two operations (block inspection, Parquet querying, canary exporting) that most observability tools leave as an exercise for the reader. Language coverage is unusually wide: Go, Java, Python, Ruby, Node, .NET, Rust, and eBPF for everything else.
Deep Grafana coupling is a real constraint — the primary UI is 'Profiles Drilldown' inside Grafana, so standalone use without a Grafana instance means falling back to the basic built-in UI which is considerably less capable. The v1-to-v2 migration requires running both architectures in parallel during transition, which adds operational complexity and isn't zero-risk despite the docs claiming no data loss. AGPL v3 license will block most commercial SaaS use cases without a paid Grafana Enterprise agreement. Correlation with traces requires OpenTelemetry wiring that isn't trivial to set up, so the 'find the slow line during an incident' promise takes more plumbing than the README implies.