March 2026 | Datadog Open Source Hub

Welcome to the March 2026 edition of the OpenTelemetry News!

March was a busy month for OpenTelemetry. The Collector kept its steady release cadence, advancing credential management and Kubernetes observability. The Profiles signal officially entered public Alpha — a major milestone for the fourth signal. The community announced the deprecation of the Span Event API, converging on the Logs API as the single recommended way to emit events. A new Kotlin Multiplatform SDK entered active development, extending OpenTelemetry's reach to Android, iOS, JVM, and beyond. And the Collector SIG shared a 1.0 progress report, reflecting on two years of stability work and the road ahead.

Highlights

Span events are being deprecated

OpenTelemetry has had two overlapping ways to emit events correlated with traces: span events (via Span.AddEvent / Span.RecordException) and log-based events (via the Logs API). The community is now deprecating the Span Event API to unify around a single model: events are logs with names, emitted via the Logs API and correlated to traces through context.

This deprecates the API for recording span events — not the ability to see events on spans in trace views. A compatibility layer will allow log-based events to still surface in existing span-oriented UIs. OTEP 4430 outlines the full transition plan.

For most operators and application developers, no immediate action is required. Instrumentation authors should plan to migrate events and exceptions to the Logs API in their next major versions.

OpenTelemetry Profiles enters public Alpha

The fourth signal is here. The Profiling SIG announced that the Profiles signal has officially entered public Alpha, marking a major step toward a vendor-neutral industry standard for continuous production profiling.

The alpha brings three major pieces together:

A unified data format, compatible with pprof, with deduplicated stack representation and string dictionary support (40% smaller wire size) for efficient cross-signal correlation.
A reference eBPF profiling agent — originally donated by Elastic — now available as an OpenTelemetry Collector receiver, with support for Go (ARM64), Node.js, .NET 9/10, BEAM (Erlang/Elixir), and Ruby.
Full Collector integration: The k8s attributes processor can enrich profiles with Kubernetes metadata, and OTTL support enables custom transformation and filtering rules.

Cross-signal correlation is a first-class concern: profiles can reference trace_id and span_id, enabling questions like, "What was the CPU profile during the high-latency traces?"

Alpha means it's ready for experimentation and community feedback — not yet for critical production workloads. Collector v0.148.0 or newer is required. Several Datadog engineers contributed to this milestone, including Ivo Anjo, Felix Geisendörfer, and Nayef Ghattas.

Collector 1.0 progress report

At KubeCon Europe 2026, the Collector SIG reflected on stability, 1.0, and the updated roadmap. Collector stability has been a priority for the SIG during the past two years, which has been identified as a top concern in the 2024 and 2025 user surveys as well as during a roadmap survey at OTel Unplugged.

During 2024 and 2025, the Collector SIG focused on releasing an OTLP-only distro v1. Getting to a stable 1.0 version of the Collector would signal stability to the many users that depend on OTel Collectors for observability. The goal was to start with a small but well-defined set of use cases. In that time, the Collector SIG stabilized over 25 Go modules, including the foundational libraries for every kind of component. This period also saw some scope creep: important work happening in parallel with stability such as a restructure of batching, middleware and profiling support delayed some modules or raised new questions on existing efforts.

At the end of 2025 and after receiving feedback from end users, Collector leads shifted focus to more direct user impact by ensuring that the most used components are stable, while scaling back API stabilization efforts. After a rework of the component stability framework, the Collector SIG came up with a list of key components to focus on for stability, informed by user surveys and leads' experience. This list includes components such as the Prometheus receiver, the Kubernetes attributes processor, and the "transform" processor.

This more recent work has already shown tangible user impact, including performance improvements, documentation improvements, evolution of Kubernetes semantic conventions, specification stabilization efforts, and the promotion of the transform processor to beta. The work continues and will be visible, step by step, in every future release!

OpenTelemetry Kotlin Multiplatform SDK

OpenTelemetry now has a Kotlin Multiplatform SDK in active development. The announcement blog post details the motivation and current state of the project.

Kotlin Multiplatform allows sharing Kotlin code across Android, iOS, JVM, and JS targets. The SDK brings a single OpenTelemetry API to all of them, designed to stay as platform-agnostic as possible while remaining mobile-friendly for common Android/iOS use cases. Initial implementations of the Logging and Tracing APIs are available, though not yet stable.

The SIG is actively seeking feedback from real users on API semantics and usability. Join the #otel-kotlin channel on the CNCF Slack or open an issue on the repository with your feedback.

New Collector releases

This news edition covers the OpenTelemetry Collector releases 0.147.0 and 0.148.0.

Security and Credential Management

processor/redaction: Added HMAC hash functions (hmac-sha256 and hmac-sha512) for GDPR-compliant pseudonymization (#45715)
HMAC functions are rainbow-table resistant by using a secret key, making it impossible to reverse-engineer original values. This enables true pseudonymization per GDPR Article 4(5) while maintaining consistency for pattern analysis. Configure with hash_function: hmac-sha256 and hmac_key: "${env:REDACTION_SECRET_KEY}".
extension/basicauth: Added username_file and password_file options, enabling file-based credentials with live rotation via fsnotify (#46227)
extension/headers_setter: Added value_file configuration option for file-based credentials that are automatically updated on change (#46473)
Useful for Kubernetes secrets and other rotated credentials.

Kubernetes Observability

processor/k8s_attributes: ReplicaSet handling now uses PartialObjectMetadata, reducing cold-start memory by ~57–59% compared to typed informers (#44407)
receiver/k8s_cluster: Entities and relationships for Kubernetes resources are now defined in metadata.yaml (#41080)
exporter/loadbalancing: Changed default timeout for the k8s resolver from 1 second to 1 minute (#33004)
The previous 1s default caused watch connections to reconnect every second, generating a large number of requests to the Kubernetes API server. The new 1m default significantly reduces API server load while maintaining reasonable endpoint discovery latency. The timeout remains configurable for users who need different behavior.

Metric Units Alignment

all: Metric units are now singular to match the OTel specification — for example, {requests} → {request} (#14753)
This is a breaking change that may affect dashboards and alerts that match on unit strings.

Known Issue in v0.148.0

The collector's internal Prometheus metrics endpoint (:8888) now emits OTel service labels with underscore names (service_name, service_instance_id, service_version) instead of dot-notation names (service.name, service.instance.id, service.version). As a workaround, add the following to your Prometheus receiver scrape configuration:

metric_relabel_configs:
  - source_labels: [service_name]
    target_label: service.name
  - source_labels: [service_instance_id]
    target_label: service.instance.id
  - source_labels: [service_version]
    target_label: service.version
  - regex: service_name|service_instance_id|service_version
    action: labeldrop

See #14814 for details and updates.

processor/datadogsemantics: Removed (#46893)
This processor was deprecated in v0.146.0. If you rely on it, please contact Datadog support.
extension/datadog: Now sets the os.type resource attribute if not already present, improving Fleet Automation metadata (#46896)

Datadog News

Explore Kubernetes with native OpenTelemetry data

Datadog announced a preview of native OpenTelemetry support in the Kubernetes Explorer. Teams standardizing on OTel pipelines have often hit a frustrating wall: many platforms require translating telemetry into vendor-specific formats, leading to blank dashboards and uncertainty about data fidelity.

The Kubernetes Explorer now ingests OTel data directly. It handles semantic normalization — for example, reconciling CPU metrics that arrive in nanoseconds from one collector and seconds from another — and maps them to the correct Kubernetes entities regardless of how they were collected. From there, users get the same unified resource navigation (clusters, nodes, namespaces, pods, workloads) and cross-signal correlation across metrics, logs, and traces that Datadog users are familiar with, without a translation layer in between.

Get Involved

Want to contribute to OpenTelemetry? Here are some ways to get started:

Join a Special Interest Group (SIG).
Contribute code to one of OpenTelemetry repositories.
Share your OTel story with the community.

Resources

Did we miss something? If you have news to share or want to contribute to the next edition, please reach out to us via otel-news@datadoghq.com.