48.9k
The OpenTelemetry profiles signal is a fourth core telemetry signal, alongside traces, metrics, and logs, that records sampled stack traces showing which functions consume CPU and memory in production. The OpenTelemetry Profiling SIG announced its public alpha in March 2026, with support landing in Collector v0.148.0.
TL;DR
- Profiles joined traces, metrics, and logs as an OpenTelemetry signal in public alpha, announced by the Profiling SIG in March 2026.
- The OTLP profiles format round-trips losslessly with pprof and cuts wire size roughly 40% through a shared string dictionary.
- Collector v0.148.0 and newer adds a pprof receiver, Kubernetes metadata enrichment via
k8sattributesprocessor, and OTTL transforms for profile data. - The whole-system eBPF profiler, donated by Elastic, now ships as an official collector component, with runtime support work for Go, Node.js (V8), Ruby, .NET 9 and 10, and initial BEAM (Erlang/Elixir).
- The SIG advises against critical production workloads for now, and production-ready backends have not yet emerged, so treat the alpha as something to evaluate.
What shipped in the profiles alpha?
The alpha release covers three artifacts: an OTLP profiles data format with a deduplicated stack representation, profiles pipeline support in OpenTelemetry Collector v0.148.0 and newer, and the eBPF profiler running as an official collector component for low-overhead, whole-system continuous profiling on Linux.
The data format is the foundation. Profiles in pprof format (the de facto container popularized by Go's runtime tooling) convert to and from OTLP profiles with no loss of information, and a shared string dictionary makes the OTLP representation about 40% smaller on the wire. On the collection side, Collector v0.148.0 adds a pprof receiver for ingesting existing profile files, k8sattributesprocessor support so samples carry pod and namespace metadata, and OTTL rules for transforming profile data in the pipeline. Engineers from Google, Datadog, Elastic, Grafana Labs, Polar Signals, Red Hat, Splunk, and Shopify contributed to the milestone, and Elastic's open source devfiler desktop app serves as a local viewer for experimentation.
Why does a profiles signal exist?
Metrics report that CPU is high, and traces show which request was slow, but neither names the function responsible. Profiles answer that question directly: continuously sampled stack traces reveal where applications spend resources in production, and a shared OTel format makes that data portable instead of locked to one vendor's agent.
Continuous profiling is an established practice. Google described running it fleet-wide in the Google-Wide Profiling paper (IEEE Micro, 2010), but until now every implementation used proprietary agents and incompatible formats. Standardizing the signal does for profiling what OTLP did for traces: one wire format, any compliant backend. The signal's design also links samples to the trace and span active when they were captured, so a slow span can open directly onto the code that ran during it.
| Signal | Question it answers | OpenTelemetry status (July 2026) |
|---|---|---|
| Traces | Where in the request path did time go? | Stable |
| Metrics | What is the rate, error count, or p99 over time? | Stable |
| Logs | What did the application say happened? | Stable |
| Profiles | Which code consumed the CPU and memory? | Alpha |
What changes for you?
Nothing is mandatory yet. Application teams keep their existing instrumentation, because profiles collection is zero-code. Platform teams can start evaluating by running the eBPF profiler on a non-critical Linux node, shipping samples through a collector, and inspecting them locally. Teams building telemetry backends should start implementing OTLP profiles ingestion now.
The zero-code property comes from eBPF: the profiler samples stacks from the kernel side, across every process on the host, without SDK changes or redeploys. The SIG does warn that the signal "should not be used for critical production workloads," SDK-level APIs for in-process profiling are still ahead, and support in telemetry backends is in progress rather than shipped. Treat 2026 as the evaluation window before beta and GA.
What does a minimal setup look like?
A minimal profiles setup is a standard collector pipeline with a profiles signal type. A receiver accepts OTLP profiles or pprof files, optional processors enrich samples with metadata, and an OTLP exporter forwards them to a backend. It runs in OpenTelemetry Collector v0.148.0 or newer with no application changes.
The fragment below is illustrative: component names and gates are changing during alpha, so confirm against the Collector release notes for your version.
receivers:
otlp: # SDKs / agents exporting OTLP profiles
protocols:
grpc:
pprof: # ingest existing pprof files (v0.148.0+)
processors:
k8sattributes: # enrich samples with pod/namespace metadata
exporters:
otlp:
endpoint: backend:4317
service:
pipelines:
profiles:
receivers: [otlp, pprof]
processors: [k8sattributes]
exporters: [otlp]ClickStack support status
ClickStack, the ClickHouse observability stack, does not yet support profiles as a native signal. Its OpenTelemetry collector distribution ingests logs, traces, and metrics into ClickHouse, and HyperDX, the ClickStack UI, correlates them with session replays; profile visualization is not part of that surface today.
Profiles are high-volume, append-only, heavily repetitive columnar data, the same shape as the OpenTelemetry data ClickStack already stores, so the storage layer is a natural fit, and the alpha's trace-to-profile linking maps onto the trace-ID correlation HyperDX uses across signals. Until native support ships, ClickStack users can follow the alpha with the collector components above and keep profiles in a parallel pipeline.
FAQ
What is the OpenTelemetry profiles signal?
OpenTelemetry treats profiles as a core signal in the same family as traces, metrics, and logs. A profile is a stream of sampled stack traces showing where running code spends CPU and memory, carried in an OTLP format compatible with pprof. The signal reached public alpha in March 2026.
Is the OpenTelemetry profiles signal production ready?
No. The signal is in alpha, and the Profiling SIG advises against relying on it for anything critical. Collector support exists from v0.148.0, and the eBPF profiler is usable for evaluation, but the format can still change and backends that ingest OTLP profiles are still being built. Beta and GA come next.
How do profiles link to traces in OpenTelemetry?
Profile samples carry the trace ID and span ID that were active when each stack was captured. That lets a backend jump from a slow span to the exact functions executing during it, and from a CPU spike on a host to the requests it served, a correlation neither signal provides alone.
Do I need to change my code to collect profiles?
No. The whole-system eBPF profiler runs outside your applications, observing every process on a Linux host from the kernel, so there is nothing to add to your code and nothing to redeploy. The alpha includes runtime support work for Go, Node.js, Ruby, .NET 9 and 10, and initial BEAM coverage for Erlang and Elixir.
Try ClickStack to keep logs, traces, and metrics in one queryable ClickHouse store while profiles mature.
