OpenTelemetry profiling brought performance closer to the main stack

Profiling used to feel separate from the rest of observability.

Logs told you what happened. Metrics told you how the system behaved over time. Traces told you where a request went. Profiling was the side quest where you opened another tool, captured a flame graph, and hoped you could line it back up with the incident.

OpenTelemetry profiling matters because it makes that detour less awkward.

four questions, four signals

• logs: what happened
• metrics: how often or how much
• traces: where the request went
• profiles: which code paid the bill

The profile is the one people reach for too late. A trace can show that a request spent 900ms in a service. A metric can show CPU climbed. A log can show a timeout. The profile can show that the hot path was serialization, regex work, compression, allocation churn, or a dependency call nobody suspected.

sampling makes it practical

Production profiling has to be cheap enough to keep around or easy enough to turn on during an incident. Sampling-based profilers do that by collecting stacks at intervals instead of demanding a manual debugging session every time something feels slow.

That does not remove the tradeoffs. Short-lived behavior can be missed. Symbolization can be annoying. Native stacks and stripped binaries add friction. Still, the workflow is much better when the profile can travel through the same telemetry path as the rest of the data.

resource context keeps the story honest

The useful profile is the one with service version, region, host, deployment, tenant class, and feature flag context attached. Otherwise the team ends up staring at averages and guessing.

Maybe the slowdown only exists on the new version. Maybe it only hits one customer. Maybe one node class is worse. Maybe the deploy changed input size. The profile should help answer those questions instead of floating above them.

I like the direction because it removes one more excuse to treat performance as a separate discipline. A slow route should lead to the code path, the hot stack, and the deploy that changed it. If OpenTelemetry can make profiling feel like part of the main stack, that is enough.