Introduction: The "It Works on My Machine" Problem

The Mystery Slowdown

You have metrics that say CPU usage is at 90%. You have logs saying "Request processed." You have traces saying "The request took 5 seconds."

But why?

Is the CPU high because of a bad regular expression? A tight loop? JSON parsing? Garbage collection?

Metrics, logs, and traces tell you that something is wrong and where in the request lifecycle it happened. They cannot tell you which lines of code are responsible. That gap is exactly what profiling fills.

Profiling: The Missing Link

Profiling is the act of recording exactly which functions your code is executing and how much of a resource — CPU time, memory, network I/O — each function consumes. Think of it like a time-motion study for your code: instead of watching factory workers, you watch function calls.

Traditionally, profiling was something you did locally with a debugger, or by attaching a heavy tool to a running process for 10 minutes — which often slowed the application down significantly and was never safe to run in production. You'd profile on your laptop, hope the problem reproduced, and guess whether your findings applied to the real workload.

Continuous Profiling changes this entirely. It uses ultra-low-overhead techniques (like eBPF — Extended Berkeley Packet Filter, a Linux kernel technology that lets you run sandboxed programs inside the kernel without modifying application code) to profile all your production servers, all the time, with almost zero performance impact (typically under 1%). It stores this data historically, so you can travel back in time to see exactly what the CPU was doing during yesterday's outage — even after the incident is over and the process has restarted.

Where Continuous Profiling Fits in Observability

The three traditional pillars of observability are metrics, logs, and traces. Continuous profiling is increasingly called the fourth pillar. Each pillar answers a different question: