Connecting Profiling to the Rest of Your Observability Stack

Profiling in Isolation Is Half the Value

A flamegraph tells you what is slow. Your traces tell you when and for which requests it was slow. Connecting these two signals is where continuous profiling becomes genuinely powerful.

Modern tools support trace-to-profile linking: when you view a slow trace in Jaeger or Tempo, you can click a button to open the flamegraph for that exact service during that exact time window. This workflow looks like:

1. Alert fires: p99 latency exceeds SLO.
2. Open traces: Find a representative slow trace in Grafana Tempo.
3. Identify the slow span: The payment-service span took 4 seconds.
4. Jump to profile: Click "View Profile" — opens the CPU flamegraph for payment-service during those 4 seconds.
5. Find the function: bcrypt.GenerateFromPassword is 80% wide.
6. Fix: Reduce bcrypt cost factor, or cache the result.

This end-to-end workflow — from alert to root cause in minutes — is the goal of a mature observability stack.

The OpenTelemetry Profiling Signal

The OpenTelemetry project (the vendor-neutral observability standard) is actively developing a profiling signal specification. This will allow profiling data to be exported using the same OTLP (OpenTelemetry Protocol) pipeline already used for traces and metrics, making it trivial to send profiling data to any compatible backend. As of 2024, this specification is in active development and several vendors have begun implementing experimental support.