Continuous profiling
An always-on production profiler that lets you see which functions consumed CPU or memory during any past slowdown.
See it
What it is
Continuous profiling keeps a low-rate sampling profiler running in production and stores profiles over time. Instead of attaching a profiler after the slowdown has vanished, you can ask which functions used CPU, allocated memory, or held locks during a particular release and compare that window with yesterday. Google described the approach in its 2010 Google-Wide Profiling paper; Grafana Pyroscope and Parca are products built around this workflow.
Reach for it when performance regressions are intermittent, tied to real traffic, or too subtle for traces. Tag profiles with service, environment, version, and region, then use flame graphs or diff views to connect a resource spike to the code path that changed.
Gotcha: always-on does not mean free or complete. Sampling adds overhead and can miss short-lived work, while allocation and lock profiles can cost more than CPU sampling. Start conservatively, measure overhead in your runtime, and keep unbounded values such as user IDs out of profile labels.
Ask AI for it
Add continuous profiling to this Go service with Grafana Pyroscope. Start CPU profiling with the github.com/grafana/pyroscope-go SDK pointed at the Pyroscope server URL, and tag every profile with service_name, environment, region, and release SHA. Do not attach user IDs, request IDs, URLs, or other unbounded values. Build a flame graph view filtered by release and a comparison view for the 30 minutes before and after a deployment. Load-test with profiling on and off, and report the measured CPU and memory overhead before enabling it in production.