Observability: the three pillars aren't enough — what's the fourth?

The 'three pillars' of observability (logs, metrics, traces) are a great foundation, but I've increasingly felt they're not enough, especially when you're trying to debug performance regressions in a complex distributed system. You can see *what* happened, but often not *why*. For us, continuous profiling has become the unofficial 'fourth pillar.' Tools like Pyroscope or Parca, which collect CPU and memory profiles constantly across our services, have been game-changers. If a new deployment suddenly makes a particular API endpoint 3x slower, metrics will show the latency spike, traces will show which service is slow, but only the profiler tells us exactly which function in that service is suddenly taking more CPU or allocating more memory. It's incredible for root-cause analysis. Correlating this profiling data with our existing logs, metrics, and traces is where the real power lies. When you can jump from a trace span to the profile of that specific service at that specific time, it accelerates debugging significantly. It feels like we're just scratching the surface of what's possible here.