What is continuous profiling and how does it differ from traditional profiling?

Continuous profiling is the practice of running lightweight profilers in production continuously (24/7), sampling CPU usage, memory allocations, goroutine counts, or mutex contention at low frequency, and storing the results in a queryable database. The key word is continuously — unlike traditional profiling, you do not need to predict when a performance problem will occur and manually attach a profiler to catch it.

Traditional profiling (using tools like JProfiler, YourKit, or Java Flight Recorder in triggered mode) is done on demand: a developer identifies a performance issue, attaches a profiler to the suspect process, reproduces the problem, and analyzes the profile. This works well in development but has two problems in production: the profiler overhead can be too high for continuous use (JProfiler in full instrumentation mode can add 20-200% overhead), and you cannot retroactively profile an incident that already passed.

Continuous profiling tools like Pyroscope (open-source), Parca (CNCF), Google Cloud Profiler, and Datadog Continuous Profiler use sampling-based profilers (typically 100 Hz) that add less than 1-5% overhead, making them safe for production. Results are stored with timestamps and labels, enabling queries like: "Show me the flame graph for the payment-service during last Tuesday's latency spike" — and directly compare it to flame graphs from the same time the previous week.

Continuous profiling connects naturally to the other observability pillars: when traces show a method is slow, the continuous profiler shows exactly which code path within that method consumes the time.