June 2026

Welcome to the June 2026 edition of the OpenTelemetry News!

The OTel Arrow Protocol project published a Phase 2 update this month, moving beyond an efficient wire format toward a full columnar pipeline runtime, with two sessions at the Observability Summit covering different angles of that work. The Observability Summit recordings are now available on YouTube. On the Collector side, releases 0.154.0 and 0.155.0 bring the cardinality guardian processor graduating to alpha, Schema v2 file format support, and several practical OTTL additions. Specification v1.58.0 merges context-scoped attributes and wraps up Prometheus stabilizations. In semantic conventions, v1.42.0 moves all GenAI conventions to a dedicated repository.

Highlights

Observability Summit session recordings available

The Observability Summit session recordings are now available on YouTube, covering a broad range of topics across the OpenTelemetry ecosystem.

Zach Groves from Datadog presented OpenTelemetry GenAI in Practice: What the Spec Says Vs. What You Actually See, exploring the gap between what the OTel GenAI specification defines and what practitioners actually encounter when instrumenting AI workloads.

OTel Arrow Protocol (OTAP) advances to Phase 2

The OTel Arrow project published a Phase 2 update, shifting focus from OTAP as a wire format to OTAP as the primary data representation throughout an entire telemetry pipeline. Phase 1 established the protocol; Phase 2 explores keeping telemetry in columnar Arrow batches across the full decode, transform, and encode cycle, eliminating the per-operation overhead that today's pipelines pay when converting between representations for every attribute removal, rename, or routing decision.

The team built the OTel-Arrow Dataflow Engine, a Rust runtime designed around OTAP as its native representation. Two sessions at the Observability Summit covered the protocol from different angles: Cijo Thomas and Joshua MacDonald presented The Invisible Tax: How Data Format Conversions Drive up Telemetry, and Amanda Sopkin from Datadog presented Every Byte Counts: How Protocol Design Shapes the Cost. The project remains in incubation and is actively seeking community feedback on runtime semantics, APIs, and operational models.

.NET Instrumentation SIG update

The OpenTelemetry .NET Instrumentation project has entered a relatively stable state, with most releases coinciding with updates to the OpenTelemetry .NET SDK. A large focus in the past 6 months has been the improvement of library loading at the runtime level. Release v1.15.0 (April 2026) introduced isolation for StartupHook-only deployments, a unified OTEL_DOTNET_AUTO_REDIRECT_ENABLED configuration for .NET Framework and .NET Core-based runtimes, and the removal of the legacy DOTNET_ADDITIONAL_DEPS workaround.

The project continues to add instrumentations for updated .NET libraries such as MongoDb.Driver 3.7.0+, Microsoft.Data.Sqlite 8.0.0+, and MySqlConnector 2.6.0+, and to add new experimental OpenTelemetry capabilities such as "NoCode" instrumentation via Declarative Configuration and OpAmp client support.

Collector exporter internals: sequential calls, parallel delivery

Juraci Paixão Kröhling published Are OpenTelemetry Collector Exporters Called Sequentially or in Parallel?, a deep-dive into how the Collector's fan-out consumer works. Exporters are called sequentially, but the sending queue makes delivery behave as if it were parallel. A past queuebatch refactor flipped the default overflow behavior in a way that much of the existing advice online still gets wrong. If you run the Collector under high load or with multiple exporters, this one is worth your time.

New Collector releases

This news edition covers the OpenTelemetry Collector releases 0.154.0 and 0.155.0.

Breaking changes

• Prometheus exporter: DisableAddMetricSuffixes feature gate reaches beta: The deprecated add_metric_suffixes field is now ignored by default. To retain the previous no-suffix behavior, switch to translation_strategy: UnderscoreEscapingWithoutSuffixes in your exporter configuration (#48930).

• connector/span_metrics validates dimension names at startup: Duplicate dimension names in calls_dimensions or histogram.dimensions now cause the Collector to refuse to start, rather than proceeding silently with undefined behavior (#48097).

New components

• processor/awsecsattributes: Initial skeleton for a processor that will enrich telemetry with AWS ECS metadata (#44476).

• receiver/active_directory_inv: Collects inventory data from Windows Active Directory (#48733).

• processor/cardinality_guardian is promoted to alpha stability and is now included in the contrib distribution (#47368). The processor caps per-metric cardinality dynamically, stripping high-cardinality labels rather than dropping entire datapoints when a cardinality spike occurs.

Component naming convention

The snake_case rename wave continued across v0.154.0 and v0.155.0. Deprecated aliases are maintained so existing configurations keep working, but plan to update your component names to ensure compatibility with future releases.

OTTL & processing improvements

• A new substring function provides UTF-8 safe string slicing via an optional utf8_safe parameter, avoiding incorrect byte-boundary splits in multi-byte characters (#48436).

• The new ottlexemplar context enables per-exemplar field access in OTTL expressions, useful for filtering or transforming exemplar data attached to metrics (#47490).

• stringify_all is a new OTTL editor that converts non-string values in a map to their string representations, useful for normalizing attribute maps before export (#48044).

• processor/transform gains a limit_buckets method for reducing histogram bucket count before export, letting you trade precision for cardinality without losing the overall shape (#48527).

• processor/tail_sampling now supports "not" policy nesting inside and_sub_policy, enabling more expressive exclusion rules in sampling configurations (#47313).

• processor/log_dedup adds metadata_keys and metadata_cardinality_limit configuration, giving multi-tenant pipelines control over which log attributes participate in deduplication (#47521).

• Two new log parsing functions land in pkg/stanza: ParseLEEF for IBM's Log Event Extended Format (#44908) and ParseCLF for Common Log Format HTTP access logs (#48349).

• processor/schema gains support for Schema v2 file formats (manifest/2.0 and resolved/2.0) (#48189), the first Collector-side implementation of OTEP 4815. Operators can now experiment with v2 schemas for telemetry validation and convention enforcement directly in their pipelines.

For a practical introduction to writing and using OTTL, Reese Lee presented Devs, Transform (Your Data) and Roll Out!: Learning and Leveraging OTTL at the Observability Summit. If you are new to OTTL or want to get more out of your existing statements, it is worth watching.

Community call: k8s_attributes seeks stable graduation

The processor/k8s_attributes has opened a graduation request to stable, making it the first component in the collector-contrib repository to formally pursue stable status. The processor enriches telemetry with Kubernetes metadata and is among the most widely deployed components in the ecosystem.

The promotion PR (#49152) is in progress. Because this is the first-ever run of the component graduation guidelines, the maintainers are actively seeking community input to ensure the process and criteria hold up before they set a precedent for future graduations.

Security model and open issues

The OpenTelemetry Security SIG merged a security model document in May, clarifying when OTel projects will request CVEs. In line with similar policies from Prometheus and Envoy, availability-related attacks from authenticated inputs, such as resource exhaustion and DoS, are not considered CVE-worthy, but they are still tracked and fixed as bugs.

This policy is now visible in practice: a batch of issues filed on June 22 covers resource exhaustion, memory amplification, and injection concerns across components including fluent_forward, jaeger, AWS S3 and Firehose receivers, and the OpenSearch and file exporters. If you run any of these components in an environment where untrusted data can reach the Collector, these issues are worth reviewing.

OpenTelemetry specification v1.58.0

The v1.58.0 release merges a long-discussed OTEP on context-scoped attributes, continues Prometheus compatibility stabilization, and formally deprecates OpenCensus compatibility requirements.

Context-scoped attributes

OTEP #4931 introduces context-scoped attributes, a mechanism for attaching attributes to an active context so that all telemetry signals emitted within that context automatically inherit them.

This fills a gap that has existed since OTel's early days: Resource attributes apply at process scope (too broad), while span or metric attributes require explicit attachment to each individual signal (too narrow). Context-scoped attributes sit in between, think of them as a way to say "every signal emitted in this scope carries these attributes" without modifying Resource or changing instrumentation call sites. The proposal explicitly notes they "should be thought of as equivalent to adding the attribute directly to each single telemetry item" within the context.

The feature is opt-in by default, and the original idea traces back to OTEP #207. SDK implementations will follow as they adopt the spec.

Prometheus stabilizations and OpenCensus deprecation

v1.58.0 also stabilizes several more Prometheus exporter behaviors: OTLP Summary to Prometheus Summary conversion (#5107), client library guidance (#5106), default aggregation configuration (#5113), and OTel Histogram to Prometheus Histogram transformation with optional custom buckets (#5091).

OpenCensus compatibility requirements are deprecated in the specification (#5138). If you are still relying on OpenCensus bridge compatibility in an SDK implementation, this is the formal signal that it is time to complete the migration to native OpenTelemetry instrumentation.

In discussion: Composable view matching mode

PR #5173 proposes a view_matching_mode parameter on MeterProvider with two modes: independent (default, current behavior) and composable. In composable mode, multiple Views matching the same instrument merge into a single stream rather than creating separate ones. The merge rules are: first-wins for name, description, and aggregation; set intersection for attribute_keys.include; set union for attribute_keys.exclude.

This makes it practical to layer a global policy ("drop this sensitive attribute from everything in this scope") with a per-instrument override ("rename this histogram") without the two Views conflicting with each other. The proposal surfaced in the spec SIG meeting on June 23 and has an early Go prototype. It is open for discussion and not yet merged.

Semantic conventions v1.42.0

The v1.42.0 release brings a major organizational change alongside the usual attribute and metric updates.

GenAI conventions move to a dedicated repository

All gen_ai.* attributes, metrics, events, and spans are migrating out of the core semconv repo into a dedicated opentelemetry-semantic-conventions-genai repository (#3696). The definitions previously in model/gen-ai/, model/openai/, and model/mcp/ are now deprecated in the main repo and will remain as stubs pointing to the new home.

With a dedicated repository, the GenAI SIG can iterate at its own pace without waiting for the core convention release cycle. If your tooling, Weaver configurations, or documentation reference GenAI semconv paths directly, now is the time to update those references.

Kubernetes

• Core Kubernetes and container registry resource attributes graduate to stable status, providing a stable foundation for Kubernetes observability tooling to build on (#3382).
• A new k8s.container.ephemeral_storage.usage metric tracks ephemeral storage consumption at the container level (#3681).

Breaking: HTTP metrics cardinality change

The network.peer.address attribute requirement level is reduced from Recommended to Opt-In on http.client.open_connections and http.client.connection.duration metrics (#3279). If you collect these metrics and rely on network.peer.address in dashboards or alert queries, the attribute may now be absent unless you explicitly opt in.

Datadog news

Here is what's new from Datadog with direct relevance to OpenTelemetry practitioners. Several items below were announced at Dash 2026.

• OTel compliance in Datadog SDKs: Datadog SDKs can now export traces in OTLP to DDOT or any OTel Collector, and fully support the OTel APIs for traces, logs, and metrics. Teams can send telemetry via OTel pipelines while still benefiting from Datadog products and capabilities. See the docs to get started.

• Kubernetes Explorer with native OTel support: The Kubernetes Explorer now works directly with OpenTelemetry data, removing the need for vendor-specific format translation. Teams running OTel pipelines can navigate cluster health, investigate resource issues, and correlate metrics, logs, and traces from their existing instrumentation. Read more in Explore Kubernetes with native OpenTelemetry data.

• OTel gateway topology view in Fleet Automation: Fleet Automation gains a topology visualization for OpenTelemetry gateway architectures, showing how telemetry flows through collector networks, surfacing traffic anomalies, and letting teams isolate problematic collectors using component-level alerts. Read more in Accelerate OTel gateway resolutions with Datadog Fleet Automation.

• Manage DDOT pipeline configurations at scale with Fleet Automation: Platform teams can now remotely configure the Datadog Distribution of the OpenTelemetry Collector (DDOT) from Fleet Automation, editing YAML, applying changes to selected collectors, and reviewing deployment history directly in Datadog. This helps standardize OpenTelemetry pipeline operations, reduce configuration drift, and roll out changes for filtering, routing, and sampling with greater control. Sign up for the preview.

• OTel-native in-app experiences: Teams running fully OTel pipelines can now access curated product experiences across infrastructure and APM, including the Host List view with Host Metrics Receiver support and APM RED metrics from spans sent directly via OTLP without the Datadog Exporter. Sign up for the preview.

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

• Datadog OpenTelemetry Documentation
• OpenTelemetry Documentation
• Getting Started Guide
• CNCF OpenTelemetry Slack

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.