Continuous Profiling
Sampling CPU, memory and lock profiles from production continuously at low overhead, so resource usage can be attributed to specific code paths.
Metrics say a service uses 80% CPU. Traces say a span took 400 ms. Neither says which function is responsible. Profiling closes that gap, and it is the most commonly missing layer of observability.
Continuous profiling means sampling in production, always, at overhead low enough to ignore — typically a few percent. That matters because performance problems appear under real workloads and real data distributions, and a laboratory profile of a synthetic benchmark frequently points somewhere else.
What it makes possible: attributing cost to code (a flame graph showing that 30% of CPU is spent in JSON serialisation is directly actionable, and a common finding); differential profiles comparing versions or comparing now with last week, which is how a regression is localised in minutes; and diagnosing memory growth by allocation site rather than by inference.
The complements: lock and blocking profiles, which explain the case where CPU is low and latency is high — usually contention or connection-pool exhaustion, and effectively invisible to CPU profiling.
The economic argument that gets it funded: it converts "we need bigger instances" into "these three functions account for half the CPU", which is usually much cheaper to fix than to scale.