https://opentelemetry.io/blog/2026/profiles-alpha/ OpenTelemetry * Docs * Ecosystem * Status * Community * Training * Blog * English EN + baaNlaa (Bengali) + English + Espanol + Francais + Ri Ben Yu (Japanese) + Polski (Polish) + Portugues + Romana (Romanian) + Ukrayins'ka (Ukrainian) + Zhong Wen (Chinese) * + Light + Dark + Auto [ ] [ ] * Blog + [ ] 2026 o [ ] Profiles Public Alpha o [ ] New OpenTelemetry Kotlin SDK o [ ] Beyond the good first issue o [ ] How Mastodon Runs OpenTelemetry Collectors in Production o [ ] Deprecating Span Events API o [ ] Kubernetes SemConv RC o [ ] Declarative Config Stabilized o [ ] Context inference for filtering o [ ] It's us, your community managers! o [ ] New Community Managers o [ ] KubeCon EU '26 o [ ] OTel Collector Survey o [ ] OBI 2026 Goals o [ ] Dapr Workflow Observability o [ ] Log Deduplication Processor o [ ] OTel JS DOS Mitigation o [ ] OTel in Traditional Environments o [ ] Year in review o [ ] Community Slack Analysis + [ ] 2025 o [ ] New Configuration Schema release candidate o [ ] New Contributor Research Study o [ ] Deprecating Zipkin Exporter o [ ] Is the OTCA Exam Right for You? Insights for Both Newcomers and Advanced Users o [ ] OpenTelemetry Community Awards Winners o [ ] Stability Proposal Announcement o [ ] Adding the Unroll Processor o [ ] Announcing Support for Complex Attribute Types in OTel o [ ] OBI First Release o [ ] 2025 GC Election Results o [ ] 2025 GC Candidates o [ ] Declarative configuration journey o [ ] OpenTelemetry Sampling update o [ ] OpenTelemetry on Mainframes Survey Insights o [ ] OTel Unplugged EU '26 o [ ] Demystifying Auto-Instrumentation o [ ] Life of an OTel maintainer o [ ] Community Awards o [ ] KubeCon NA '25 o [ ] OTel Android: Road to Stable o [ ] Technical Committee Election Results o [ ] CfC: OTel for Kotlin o [ ] 2025 GC Election o [ ] Retrospective of go.opentelemetry.io incident o [ ] How to Contribute to OpenTelemetry o [ ] How to Name Your Metrics o [ ] OpenTelemetry for Legacy Apps o [ ] How to Name Your Span Attributes o [ ] GitHub Issue Reactions o [ ] How to Name Your Spans o [ ] OTiP: Alibaba o [ ] How Should Prometheus Handle OTel Resource Attributes? o [ ] OTel Weaver o [ ] OpenTelemetry Injector o [ ] Slack Workspace Changes o [ ] OTel Pride o [ ] OTel Community Day o [ ] ContribEx survey results o [ ] Collector with Gateway API and mTLS o [ ] Stabilizing RPC Semantic Conventions o [ ] kubeletstats Receiver metrics update o [ ] KubeCon Japan '25 o [ ] KubeCon China '25 o [ ] OTel-Arrow Phase 2 o [ ] Humans of OTel EU 2025 o [ ] OTel Logging o [ ] OTel Sucks (But Also Rocks!) o [ ] Insights from the Developer Experience Survey o [ ] OTel JS SDK 2.0 o [ ] Outreachy Internship o [ ] AI Agent Observability o [ ] KubeCon EU '25 o [ ] OpenTelemetry Is Expanding Into CI/CD Observability o [ ] OTel Demo 2.0 o [ ] OTTL contexts just got easier o [ ] ContribEx Survey is open o [ ] Observing Lambdas o [ ] Mainframe Priorities Survey o [ ] Go Auto-Instrumentation Beta o [ ] K8s annotation-based discovery o [ ] Go Compile-Time Instrumentation o [ ] Go 2025 Goals + [ ] 2024 o [ ] Fuzzing Audit Results o [ ] Humans of OTel NA 2024 o [ ] OTel-docs Survey o [ ] Year in review o [ ] OTel-compliant Java logs from files o [ ] OTel for GenAI o [ ] OpenTelemetry Community Awards Winners o [ ] KubeCon NA '24 o [ ] OpenTelemetry Community Awards o [ ] Profiling state o [ ] 2024 GC Election Results o [ ] 2024 GC Candidates o [ ] Spring Starter stable o [ ] OpenTelemetry Arrow in Production o [ ] Prometheus and OpenTelemetry o [ ] 2024 GC Election o [ ] Planned Migration for go.opentelemetry.io o [ ] Multilingual website o [ ] Behind the scenes of the OpenTelemetry Governance Committee o [ ] Prometheus Compatibility Survey o [ ] Security Audit Results o [ ] KubeCon China 2024 o [ ] A new default bind address for the Collector o [ ] OpenTelemetry Getting Started Survey o [ ] Humans of OTel EU 2024 o [ ] Elastic Contributes Profiling Agent o [ ] New OTel features in Envoy and Istio o [ ] Collector vulnerability CVE-2024-36129 o [ ] LLM Observability o [ ] Go Contrib modules ownership o [ ] Java Metric Systems Compared o [ ] Collector container log parser o [ ] OTel Operator Q&A o [ ] OpenTelemetry Collector Survey o [ ] Collector Roadmap o [ ] Understanding OTel Errors o [ ] Collectors at scale with Ansible o [ ] Profiling support o [ ] Getting started with otelsql o [ ] OTel Collector Antipatterns o [ ] KubeCon EU '24 o [ ] Skyscanner using OTel Demo o [ ] Outreachy Internship + [ ] 2023 o [ ] Humans of OTel o [ ] Observe Spring Native o [ ] OTel in Focus Wrap-Up o [ ] Any Metric Receiver o [ ] Performance benchmarks o [ ] Python Logs Collection o [ ] OTel integration for Otterize network mapper o [ ] OpenTelemetry Protocol with Apache Arrow o [ ] Contribfest at KubeCon NA o [ ] OpenTelemetry in Cloud Foundry o [ ] Demo 1.6 Released o [ ] Tyk API Gateway's Native OpenTelemetry Integration o [ ] HTTP semconv are stable o [ ] Integrations Welcome! o [ ] OTel in Focus 2023/10 o [ ] 2023 GC Election Results o [ ] OpAMP Status o [ ] The Future of Observability Panel o [ ] 2023 GC Candidates o [ ] Synthetic HTTP testing o [ ] Go Metric SDK is Stable o [ ] KubeCon NA '23 o [ ] OTel in Focus 2023/09 o [ ] 2023 GC Election o [ ] Contributing to OTel o [ ] .NET Automatic Instrumentation v1.0.0 o [ ] Jaeger Collector Exporter Migration o [ ] PHP Release Candidate o [ ] OTel in Focus 2023/08 o [ ] OTel in Focus 2023/07 o [ ] Testing the OTel Demo o [ ] End-User Q&A: Migrating to OTel at Lightstep o [ ] OTel in Focus 2023/06 o [ ] End-User Q&A: OTel at Farfetch o [ ] K8s Runtime Observability o [ ] OTel in Focus 2023/05 o [ ] OTel Lambda Updates o [ ] Exponential Histograms o [ ] Histograms vs Summaries o [ ] End-User Discussions April 2023 o [ ] Why Histograms? o [ ] OTel in Focus 2023/04 o [ ] Sunsetting OpenCensus o [ ] OTel Demo Updates o [ ] ECS and OTel SemConv Convergence o [ ] KubeCon EU '23 o [ ] OTel in Focus 2023/03 o [ ] End-User Discussions Mar 2023 o [ ] PHP Auto-Instrumentation o [ ] End-User Q&A: OTel at Uplight o [ ] End-User Discussions Feb 2023 o [ ] OTel in Focus 2023/02 o [ ] New APAC Collector-SIG meetings o [ ] End-User Q&A: OTel with GraphQL o [ ] Submitting a CFP o [ ] Outreachy Call for participation '23 o [ ] OTel in Focus 2023/01 o [ ] HTTP semantic conventions o [ ] PHP Beta Release o [ ] End-User Discussions Jan 2023 o [ ] JMX Metric Insight + [ ] 2022 o [ ] eBay OpenTelemetry o [ ] OTel Demo App on Nomad o [ ] APAC End User Discussion Group o [ ] Front-end Overhaul Demo o [ ] Jaeger OTLP support o [ ] Project Update o [ ] Demo GA Release o [ ] 22 GC Election Results o [ ] OpAMP service usage o [ ] Collector builder with GCP o [ ] 2022 GC Candidates o [ ] Kubecon NA '22 o [ ] OTel Unplugged '22 o [ ] Community Manager o [ ] Tail Sampling o [ ] Debug OTel with OTel o [ ] 2022 GC Election o [ ] Exposing a Collector o [ ] Instrumenting Apache Kafka clients o [ ] Exponential Histograms o [ ] Go App Instrumentation o [ ] Instrument Nginx o [ ] OTel in Practice o [ ] .NET Auto-instrumentation Metrics o [ ] End User Resources o [ ] Kubernetes metadata o [ ] OpenTelemetry Community Demo o [ ] Instrument Apache Http Server o [ ] Metrics RCs o [ ] .NET Auto-instrumentation Beta o [ ] Tracing in Knative o [ ] Apache APISIX-Opentelemetry Integration o [ ] OpenTelemetry Tuesdays, Signing Off! o [ ] TroublesShooting Node.js Tracing Issues o [ ] Welcome o [ ] Erlang/Elixir, JS, and Ruby 1.0 + [ ] 2021 o [ ] Auto-instrumentation in Kubernetes o [ ] 2021 Governance Committee o [ ] C++ 1.0 o [ ] Trace-Based Testing with Malabi o [ ] 2021 GC election o [ ] Collector GA release o [ ] Swift 1.0 Beta o [ ] Python 1.0 o [ ] Women's day 2021 + [ ] 2019 o [ ] Governance Committee Explained View page source Edit this page Create child page Create documentation issue On this page * Production profiling for all * Standardizing the data representation * Frictionless insights with the eBPF Profiling Agent * Profiles in the OTel ecosystem * Getting started * Brought to you by… * What's next 1. Blog 2. 2026 3. Profiles Public Alpha OpenTelemetry Profiles Enters Public Alpha By Alexey Alexandrov (Google) Ivo Anjo (Datadog) Felix Geisendorfer (Datadog) Christos Kalkanis (Elastic) Florian Lehner (Elastic) Damien Mathieu (Elastic) | Thursday, March 26, 2026 Since OpenTelemetry first introduced Profiles, momentum has only grown towards building a unified industry standard for continuous production profiling, standing alongside traces, metrics, and logs. Today, the Profiling SIG is proud to announce that the Profiles signal has officially entered public Alpha, and we are ready for broader community use and feedback. Production profiling for all Continuously capturing low-overhead performance profiles in production is a technique that has been used for decades. It helps troubleshoot production incidents, improves user experience by making software faster and reduces computation costs by making the same work take less resources. Historically, the industry lacked a common framework and protocol for continuous profiling, even with formats like JFR and pprof being popular. With OpenTelemetry Profiles, we're introducing an industry-wide standard for production profiling, with true vendor neutrality and powered by community and ecosystem support. There are a few components to making this a reality: * Creating a unified data representation for profiling data, compatible with existing formats like pprof. * Introducing a novel reference eBPF-based profiler implementation. * Making Profiles an organic part of the OpenTelemetry ecosystem, such as integrating it with the OTel Collector. All of the above have been substantially improved in the Alpha release, so let's dive into what we've been working on! Standardizing the data representation Creating a unified profiling format is a significant challenge, as it must serve as the industry standard across diverse environments. The working group had to reconcile numerous requirements: sampling vs. tracing, native vs. interpreted runtimes, the tension between wire/ memory-size efficiency and data readability, and other similar aspects. The resulting Profiles Alpha format offers a balanced feature set that can efficiently capture profiling data: * The stack representation is deduplicated so that each unique callstack is stored only once, allowing efficient encoding of diverse profiling data. * The dictionary tables for other common entities also allow efficient data normalization. * While primarily focused on encoding aggregated data, the format also allows capturing timestamped event data to support use cases such as recording individual (even if sampled) off-CPU events. * Resource attributes allow augmenting the data model with additional information. String dictionary support enables efficient (40% smaller wire size) linking of profiling data to the same resource that emitted associated logs, metrics or traces. * Profile samples can be further associated with the Tracing trace_id / span_id attributes, enabling cross-signal correlation of the data. * Semantic conventions provide definition for the most common profiling-specific attributes. Originally inspired by the pprof format and developed in collaboration with pprof maintainers, OTLP Profiles has evolved into an independent standard that addresses the broad requirements of the OpenTelemetry ecosystem. Data in the original pprof format can be round-trip converted to/from OTLP Profiles with no loss of information. For that purpose a new native translator is now included to ensure seamless interoperability. To ensure data quality and ease of adoption, we are also releasing a conformance checker tool. This allows validating that the exported profiles adhere to the technical specifications and semantic conventions of OpenTelemetry Profiles. Frictionless insights with the eBPF Profiling Agent With the Elastic donation of its eBPF profiling agent to OpenTelemetry and its integration with the OTel Collector, low-overhead whole-system continuous profiling on Linux with support of the most widely-used language runtimes without any additional instrumentation is available to every OpenTelemetry user. A number of significant improvements are available with the Alpha release: * The eBPF agent now works as an OpenTelemetry Collector receiver, leveraging existing OpenTelemetry processing pipelines for metrics and K8s metadata, and is shipped as an official collector distribution. * Automatic on-target symbolization of Go executables * ARM64 support for Node.js V8 * Initial support for BEAM (Erlang/Elixir) * Support for .NET 9 and 10 * Fixes and improvements to Ruby unwinding and symbolization Profiles in the OTel ecosystem OpenTelemetry is a holistic ecosystem with many orchestrated parts. It's critical that a new signal like Profiles integrates ubiquitously, so that all signals can benefit from each other. The Alpha release brings multiple improvements in this area across many dimensions of the OTel universe. Some notable examples of the horizontal integration of Profiles include: * OTel Collector now includes support for receiving Profiles data in specific formats or augmenting profiles with infrastructure information. + A pprof receiver allows receiving profiles from pprof-formatted files. + The k8sattributesprocessor allows augmenting profiles with Kubernetes metadata. + OTTL support allows building custom rules to transform, or filter profiles. * OTLP Resource model was updated to allow efficient information sharing, including updating Collector to transparently support this optimization for Profiles signal. Getting started To learn more about OpenTelemetry profiles, you can visit the profiles concepts page that is part of the OpenTelemetry documentation. The easiest way to get started with an actual deployment is to use the OpenTelemetry eBPF profiler in combination with a backend that supports OTLP Profiles. As the signal is still under development, production-ready backends have not yet emerged but multiple vendors are working on supporting OpenTelemetry Profiles. To speed up development and experimentation, Elastic has open-sourced a desktop application named devfiler that reimplements the backend (collection, data storage, symbolization and UI) portion of the eBPF profiler. Note that devfiler is not a real production backend and should not be used as such. For further instructions, please refer to the eBPF profiler repository. Devfiler example Brought to you by… Projects like this involve many people. Thanks to everyone who made this possible, including: * Alexey Alexandrov (Google) * Ivo Anjo (Datadog) * Frederic Branczyk (Polar Signals) * Roger Coll (Elastic) * Dmitry Filimonov (Grafana Labs) * Felix Geisendorfer (Datadog) * Nayef Ghattas (Datadog) * Jonathan Halliday (Red Hat) * Dale Hamel (Shopify) * Joel Honer (Zymtrace) * Christos Kalkanis (Elastic) * Florian Lehner (Elastic) * Damien Mathieu (Elastic) * Greg Mefford (Adobe) * Tigran Najaryan (Splunk) * Tommy Reilly (Polar Signals) * Tim Ruhsen (Zymtrace) * Josh Suereth (Google) * Timo Teras (Elastic) * Brennan Vincent (Polar Signals) What's next We encourage teams building profiling tools and products to start using the OpenTelemetry Profiles. Here is how you can participate: * Add OTel Profiles as an export or receive option in your tool. This is already happening (e.g. async-profiler)! * Test the eBPF agent and OTel Collector (v0.148.0 or newer) support for Profiles and report issues. Or even send PRs! * Review the signal documentation and suggest what can be improved. Note that with the Alpha status of the release, the signal should not be used for critical production workloads. See the definition of the Alpha maturity level in OpenTelemetry for details. In the meantime and towards the next milestone, there is a lot of exciting work planned and in the works: * As correlation of signals is crucial for the success of observability, there is ongoing work on sharing information between eBPF based agents, like OBI and Profiling Agent. * Symbolization is a key component of every production profiling stack, so we are discussing standardizing the API, the storage format and publishing a reference implementation for it. * Sharing of runtime information between in-process SDK code and eBPF agents is important for cross-signal correlation to allow answering questions like "What were the off-CPU events for traces at the 99% latency?". Process context and thread context sharing OTEPs are in the works to enable this. And for all of this, we need your feedback! To reach us, file a GitHub issue in the OTLP or Profiling SIG repository. It will help make the signal fit the industry needs and steadily evolve it towards its next heights: Beta and GA releases! * -Previous * Next- Last modified March 26, 2026: Fix the post title to use the official signal name. (#9506) (6b3a5de5) * * * * * * * * * * * * * * (c) 2019-present OpenTelemetry Authors | Docs CC BY 4.0All Rights Reserved