OpenTelemetry Profiles Enters Public Alpha
SRE teams already use traces, metrics, and logs to explain what failed. Profiling answers a different question: where the CPU time actually goes when production slows down or costs spike. The new OpenTelemetry Profiles alpha matters because it pushes continuous profiling toward the same open standard model that made OpenTelemetry useful in the first place.
What Is OpenTelemetry Profiles?
OpenTelemetry Profiles is a new signal for capturing and transporting profiling data in a standard format. The goal is simple: let teams collect low-overhead production profiles and correlate them with the rest of their telemetry. Instead of treating profiling as a separate silo, operators can line it up with the same resources, services, spans, and infrastructure metadata they already use for incident response.
The alpha release introduces a shared OTLP representation for profiles, plus round-trip compatibility with pprof data. The opentelemetry-proto repository now includes development-stage profiles/* and collector/profiles/* definitions, which is a big step toward ecosystem-wide interoperability.
Key Features
- Cross-Signal Correlation: Profiles can be associated with resource attributes and trace or span IDs.
- Efficient Encoding: Deduplicated stacks and dictionary tables reduce storage and wire overhead.
- pprof Interoperability: Existing pprof data can be translated to and from the OTLP Profiles format.
- Collector Integration: The OTel Collector can now receive, enrich, and transform profile data.
- eBPF Path for Linux: The OpenTelemetry eBPF profiler brings low-overhead, whole-system profiling without app restarts or code changes.
Why SRE Teams Should Care
This release is interesting because it turns profiling into operational data instead of a specialist-only workflow. If a service starts burning CPU after a deploy, you do not want a separate debugging stack with its own agent model and metadata scheme. You want to pivot from a service, pod, or trace into the hottest code paths with as little friction as possible.
That is exactly where the alpha is heading. Collector support means profiles can move through familiar pipelines. The k8sattributesprocessor can enrich them with Kubernetes metadata. OTTL support means teams can filter or transform profile streams using the same collector patterns they already know.
Getting Started
If you want to experiment, start with the OpenTelemetry eBPF profiler and an OTel Collector release that includes profile support.
git clone https://github.com/open-telemetry/opentelemetry-ebpf-profiler.git
cd opentelemetry-ebpf-profiler
make otelcol-ebpf-profiler
From there, use the example collector configuration from the repository and export profile data into a test backend or local tooling.
Operational Tips
Treat this as an early-stage standard, not a drop-in replacement for mature production profiling stacks. The OpenTelemetry team is explicit that Profiles is still alpha and not ready for critical workloads. For SRE teams, the right move today is controlled evaluation: validate overhead, test metadata enrichment, and see how well profiles line up with your trace and metric investigations.
Conclusion
OpenTelemetry Profiles entering public alpha is a meaningful milestone for observability. It brings continuous profiling closer to the mainstream OpenTelemetry workflow and gives SRE teams a cleaner path to unified performance analysis. Check out the official announcement and the GitHub repositories to start experimenting.
Looking for an AI-powered platform to help your SRE team? Akmatori helps teams automate incident response and infrastructure management. Backed by Gcore, we're building the future of intelligent operations.