OTel News

April 2026

April 2026

Curated by:

Welcome to the April 2026 edition of the OpenTelemetry News!

April brought steady progress across the project. The Go Compile-Time Instrumentation SIG shared its first-year progress report and set a June 1 target for v1.0.0. A new Global OTel Nights initiative is bringing practitioner events to Amsterdam and New York, with more cities to follow. Three Collector releases landed in quick succession, introducing a critical security fix in the azure_auth extension, profiles signal promotion to alpha, a broad rename wave aligning component types to snake_case, and three new components including a log clustering processor. The specification formally deprecated OpenTracing and continued its Prometheus compatibility stabilization work.

Highlights

OpenTelemetry Go compile-time instrumentation: Progress report

The past year was foundational for the OpenTelemetry Go Compile-Time Instrumentation SIG. The SIG shipped three releases on a monthly cadence: v0.1.0 in December 2025, v0.2.0 in February 2026, and v0.3.0 in March 2026. The latest release added join point support, metaprogramming directives, Redis and MySQL instrumentation, incremental builds, and the CLI rename from otel to otelc. The SIG also documented the release process, recorded architectural decisions, and added automated consistency checks—the routine work that a stable 1.0 requires. Real-world validation came early: Orchestrion's instrumentation had already reached 57 organizations before the SIG formed, and an early type-matching engine rework delivered 5–8x faster matching than the original approach.

The v1.0.0 milestone is due June 1, 2026. The v1 board tracks four open items: feature parity with the original projects, join point completeness, documentation, and release automation. Once feature parity is reached, the SIG will port integrations from both Orchestrion and Alibaba's tool into the community-owned project, covering HTTP, gRPC, SQL databases, Redis, message queues, and AI/LLM frameworks. This brings automatic instrumentation within reach of any Go application, with no source code changes required. Datadog plans to migrate its Go tracer integrations to the OpenTelemetry tool as part of this effort. This matters especially in Go: Unlike Java or Python, Go compiles to a static native binary with no virtual machine to intercept at runtime and no bytecode to rewrite at load time. Compile-time rewriting is the only production-safe path to zero-code observability in Go, and this SIG is building the open standard for it.

OpenTelemetry page refreshed

The OpenTelemetry page on the Datadog Open Source Hub has been restructured to give a fuller picture of how Datadog engages with the project. The updated page is organized around four areas: built-in product support (ingestion paths, DDOT and Collector management, OTel-native features, and interoperability with Datadog SDKs), code contributions and governance roles across the OTel ecosystem, active participation in SIGs, and community efforts such as the DevEx case studies, and event sponsorships. If you are looking for a single reference that captures where Datadog stands in the OpenTelemetry project today, this page is a good starting point.

Global OTel Nights

A new community initiative is taking shape: Global OTel Nights. Organized by Juraci Paixão Kröhling, who has been running OTel Nights in Berlin as a CNCF Ambassador, the initiative aims to bring small, practitioner-focused events to cities around the world.

The format is intentionally constrained: no vendor pitches, presentations must focus on OTel-centric topics that are reproducible with open source tools, and hosts and presenters should be practitioners rather than vendor representatives. The goal is to surface real adoption stories and create spaces where engineers can get questions answered by peers and contributors.

Amsterdam and New York are the first expansions, with editions planned for the end of May and June respectively. Interest has also been expressed from Dublin and the Bay Area. If you are interested in hosting or attending an OTel Night in your city, join the discussion on this GitHub issue.

New Collector releases

This news edition covers the OpenTelemetry Collector releases 0.149.0, 0.150.0, and 0.151.0.

Security: Critical fix in azure_auth extension

Action required if you use extension/azure_auth under a receiver auth: block.

A server-side authentication bypass was fixed in v0.151.0 (#47823).
Bearer tokens were not previously validated as OIDC JWTs with server-pinned issuer and audience, meaning authentication could be bypassed. This issue affects versions v0.124.0 through v0.150.0.

The fix introduces two new required fields in the azure_auth configuration when used under a receiver:

  • server.issuer_url
  • server.audience

Update to v0.151.0 or later and add these fields to your configuration.

Profiles support reaches alpha in core components

Following the profiles signal's public alpha announcement in March, core Collector components completed the corresponding stability upgrade in v0.149.0: pdata/pprofile, connector/forward, exporter/debug, receiver/nop, exporter/nop, exporter/otlp_grpc, and exporter/otlp_http all had their profiles support promoted from development to alpha (#14817).

Component naming convention

A sustained effort to align component type names to snake_case conventions produced a large batch of renames across v0.150.0 and v0.151.0. Deprecated aliases are maintained for backward compatibility, so existing configurations continue to work. Plan to migrate at your own pace.

Notable renames:

  • connector/servicegraph → connector/service_graph (#47971)
  • connector/spanmetrics → connector/span_metrics (#47963)
  • receiver/filelog → receiver/file_log (#45339)
  • receiver/hostmetrics → receiver/host_metrics (#45449)
  • receiver/httpcheck → receiver/http_check (#45339)
  • receiver/windowseventlog → receiver/windows_event_log (#45339)
  • receiver/logdedup → receiver/log_dedup (#45339)
  • receiver/k8sobjects → receiver/k8s_objects (#47440)

New components

Three new components landed across these releases:

  • processor/drain: A log clustering processor that annotates log records with a derived template string (log.record.template), grouping similar log lines into patterns. Supports passthrough and buffer warmup modes and has been promoted to alpha stability (#47235). Useful for reducing high-cardinality log noise and surfacing recurring error patterns.

  • receiver/azure_functions: Ingests logs from Azure Functions triggered by Event Hub (#43507).

  • receiver/osquery: Enables scraping metrics and telemetry from osquery queries(#30375).

OTTL & processing improvements

  • pkg/ottl: New Coalesce converter returns the first non-nil value from a list of arguments (#46847). Useful for normalizing attributes across sources that use different names for the same field.

  • processor/transform: New extract_percentile_metric function extracts percentiles as gauge metrics from histograms (#44316).

  • processor/k8s_attributes: Added processor.k8sattributes.ShareProcessorBetweenPipelines feature gate, allowing the same processor instance to be shared across multiple pipelines—reducing resource overhead in multi-pipeline configurations (#36234).

Breaking changes

  • Internal metric label cleanup: service_name, service_instance_id, and service_version are no longer emitted as constant labels on every internal metric series (#14811). These were previously duplicated for OpenCensus backward compatibility and are now only present in the target_info metric. Update any Prometheus queries that filter or group by these labels on individual metrics to use target_info joins instead.

  • Kubeletstats deprecated attributes disabled: Deprecated resource attributes aws.volume.id, fs.type, gce.pd.name, glusterfs.endpoints.name, glusterfs.path, and partition are now disabled by default in receiver/kubeletstats (#47184).

  • k8s_cluster label prefixing: Kubernetes resource labels in entity events are now prefixed per OTel semconv (e.g. k8s.pod.label.<key>) instead of being emitted verbatim (#47491).

  • exporter/datadog:

    • Fixed a use-after-free bug that could cause corrupted quantile sketches when exporting ExponentialHistogram metrics with multiple attribute sets (#47338).
    • Promoted the DisableAllMetricRemapping feature gate to beta (#47212).
    • Added service.instance.id to the OTLP resource attribute to Datadog metric tag mapping (#47936).
    • Fixed a dual shipping issue for the Orchestrator Explorer (#47877).

  • extension/datadog: Added gateway_service and gateway_destination configuration fields for the gateway topology view in Fleet Automation (#47471).

  • connector/datadog and exporter/datadog: Removed stable feature gates connector.datadogconnector.NativeIngest, exporter.datadogexporter.UseLogsAgentExporter, and exporter.datadogexporter.metricexportnativeclient (#47580, #47583).

OpenTelemetry specification v1.56.0

The v1.56.0 specification release includes several noteworthy stabilizations and one significant deprecation.

OpenTracing compatibility deprecated

The specification formally deprecates OpenTracing compatibility requirements (#4938). While OpenTracing has effectively been superseded since the OpenTelemetry merger, this marks the official end in the spec itself. SDK maintainers can begin planning the removal of OpenTracing shims.

Prometheus compatibility stabilization continues

Building on the counter and gauge mapping stabilizations from February, v1.56.0 stabilizes a much broader set of Prometheus/OTLP conversions:

  • Prometheus Classic Histogram → OTLP Explicit Histogram (#4874)
  • Prometheus timestamps and start timestamps (#4953)
  • Dropped types transformation (#4952)
  • OTel Attributes → Prometheus labels (#4963)
  • Exemplar conversions in both directions (#4962, #4964)
  • Metric metadata transformations (#4954, #4966)

Combined with the February stabilizations, the core Prometheus-to-OTLP and OTLP-to-Prometheus conversion paths are now stable across virtually all metric types.

Traces

Two tracing APIs reached stable status, useful for SDK implementors:

  • Tracer.enabled operation stabilized (#4941)
  • AlwaysRecord sampler stabilized (#4934)

Event-to-span event bridge

Connecting to the span event deprecation announced in March, the specification adds an event-to-span event bridge (#5006). This is the compatibility layer that allows log-based events to continue surfacing in span-oriented UIs during the transition period, without requiring changes to existing tooling.

Datadog news

Pipeline visualization for OTel collectors in Fleet Automation

You can now easily validate telemetry routing between OTel components and identify abnormal data flow patterns with traffic data directly in-app. Add the Datadog Connector to your OTel Collector configuration to start sending traffic data to Datadog and visualize it in the Fleet Automation topology view.

Datadog Extension docs >

Runtime metrics support for OTel SDKs

Datadog now supports OpenTelemetry runtime metrics for Java, .NET, Go, Node.js, and Python. Customers using OTel SDKs will see their runtime metrics light up out-of-the-box dashboards and the APM Service Page automatically, with no additional configuration beyond enabling the runtime metrics package for their language.

Runtime Metrics docs >

SQL Server and PostgreSQL OTel integrations

Customers sending SQL Server or PostgreSQL metrics from OTel sources can now take advantage of the same out-of-the-box dashboards available to users of Datadog's Agent-based integrations.

SQL Server metrics are collected via the OTel Collector's SQL Server receiver, surfacing data in the SQL Server Overview and SQL Server Metrics dashboards. PostgreSQL metrics are collected via the PostgreSQL receiver, with 40+ metrics including connections, buffer hits, deadlocks, replication lag, and checkpoint activity. Metric name mapping between OTel and Datadog naming conventions is handled automatically.

SQL Server docs > | PostgreSQL docs > | Integrations docs >

Get involved

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

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.