OTel News

May 2026

May 2026

Curated by:

Welcome to the May 2026 edition of the OpenTelemetry News!

OpenTelemetry reached a major milestone with its graduation from the CNCF, but that was only one of several significant developments across the project this month. The Collector gained new capabilities for cardinality management and GenAI telemetry normalization, while the Browser SIG shipped the first official release of the OpenTelemetry Browser SDK. Semantic conventions and specification work continued at a rapid pace, delivering substantial updates for GenAI, Kubernetes, and Prometheus compatibility. The community also accepted two proposals with long-term implications for the ecosystem: Semantic Convention Schema v2, and the Partial Reload RFC for the Collector.

Here's a closer look at the most notable updates from across the OpenTelemetry ecosystem.

Highlights

OpenTelemetry graduates in CNCF

OpenTelemetry is officially graduated within the Cloud Native Computing Foundation, reaching the highest maturity level in the CNCF project lifecycle. The OpenTelemetry team shared their thoughts on what this milestone means, framing it as a beginning rather than an endpoint.

None of this happened by accident. It took seven years of contributions spanning code, documentation, language SDKs, specification work, semantic conventions, bug reports, reviews, and real-world deployments. Thank you to every contributor, maintainer, end user, and organization that has been part of this journey. You can see the full scope of the project on its CNCF project page.

GenAI observability: The ecosystem converges on OTel

The new processor/gen_ai_normalizer (#46069) normalizes GenAI telemetry attributes from OpenInference and OpenLLMetry to official OTel semantic conventions. Organizations already running pipelines from either framework can migrate to OTel-native conventions without touching their instrumentation. Semantic conventions v1.41.0 also shipped major GenAI additions alongside: streaming support, reasoning token tracking, time-to-first-chunk metrics, and updated tool definitions.

Taking this convergence a step further, Arize has submitted a Donation Proposal to grant the OpenInference instrumentation code directly to the OpenTelemetry project. The proposal covers Python, JavaScript, Java, and Go instrumentations for frameworks like LangChain, OpenAI, Anthropic, and others, collectively seeing millions of downloads per month. The OpenInference specification and its own semantic conventions are explicitly out of scope: OTel's GenAI semconv remains the canonical vocabulary. If accepted, this would give the OTel project a head start on instrumentation coverage for a large portion of the GenAI ecosystem.

OpenTelemetry Browser SDK: First release and a live sandbox

The Browser SIG just shipped the first release of the OpenTelemetry Browser SDK, the official entry point for instrumenting web applications in a vendor-neutral way. This initial release establishes the core API surface and a baseline set of automatic instrumentations, giving the community a single, standards-based foundation for browser telemetry rather than the patchwork of competing approaches that has historically existed in this space. To make the SDK easier to evaluate, the SIG also published a live sandbox that exercises every instrumentation currently shipped with the SDK in a single interactive page, useful both for newcomers kicking the tires and for contributors validating changes end-to-end.

Work over the next few weeks is focused on deepening the browser-native instrumentations: improving the fidelity of Resource Timing capture so that asset, fetch, and XHR timings line up cleanly with the semantic conventions, and adding instrumentation for browser.document.url.full, which will give backends a reliable, full-fidelity view of the page URL associated with each signal.

If you build or operate browser observability, this is a good moment to weigh in on the early shape of the SDK.

New Collector releases

This news edition covers the OpenTelemetry Collector releases 0.152.0, 0.152.1, and 0.153.0.

Important fix: Snappy compression memory corruption

A memory corruption and fatal error in gRPC Snappy decompression was fixed (#15237, #15320). If you use gRPC receivers with Snappy compression, upgrading is recommended.

New components

  • extension/mcp: Initial HTTP server foundation for the Collector's MCP server extension (#48072). The actual MCP tool and resource definitions will follow in subsequent releases. This is tracked as a dedicated Collector MCP project, and the SIG is actively defining what capabilities to expose first.

  • processor/cardinality_guardian: Dynamically caps per-metric cardinality using a two-phase HyperLogLog++ estimator (#47368). Instead of dropping entire datapoints when cardinality spikes, it strips only the offending high-cardinality labels (e.g., an accidental user_id or request_id), preserving the aggregate metric value. A tag_only mode injects an overflow attribute instead of dropping labels, making the truncation visible downstream.

Component naming convention

The snake_case rename wave continued across v0.152.0 and v0.153.0. Deprecated aliases are maintained; existing configurations keep working, but plan to update your component names to the new format to ensure compatibility with future releases. The full list of renames is as follows:

Type Name New name PR
Receiver awslambda aws_lambda #48163
Receiver cloudfoundry cloud_foundry #47932
Receiver googlecloudspanner google_cloud_spanner #47958
Receiver kafkametrics kafka_metrics #47520
Receiver kubeletstats kubelet_stats #47957
Receiver tcpcheck tcp_check #47507
Processor metricstransform metrics_transform #47960
Processor resourcedetection resource_detection #48525
Exporter bmchelix bmc_helix #47961
Exporter loadbalancing load_balancing #48533
Connector otlpjson otlp_json #48019
Connector roundrobin round_robin #48021
Connector slowsql slow_sql #48020
Connector metricsaslogs metrics_as_logs #48016

OTTL & processing improvements

  • OTTL context path prefixes are now supported across several more connectors and processors. Rather than relying on implicit context inference, you can now write paths like span.attributes["env"] or resource.attributes["host"] to make the context explicit. This eliminates ambiguity in components that handle multiple telemetry types, and makes OTTL expressions easier to read and maintain. Newly covered: connector/count (#48316), connector/signal_to_metrics (#48357), connector/sum (#48329), processor/log_dedup (#48266), and processor/tail_sampling (#48330).

  • processor/attributes and processor/resource now support default values for attribute operations (#45352).

  • A new otelcol_exporter_in_flight_requests UpDownCounter tracks concurrent export requests per exporter, useful for diagnosing back-pressure and export bottlenecks (#15009).

Breaking changes

  • OTTL context type errors now propagate: Setting a datapoint context field on an incompatible type now returns an error instead of silently failing. Pipelines relying on the no-op behavior will need to add type guards (#48384).

  • Filter and transform processors: Default error_mode changed to ignore: The previous default was propagate. If you relied on the old default behavior for error propagation, explicitly set error_mode: propagate (#47232, #48415).

  • pprof receiver restructured: Top-level fields moved under remote, file, self, and server subsections. The receiver also gains HTTP push ingestion at POST /v1/pprof (#48276).

  • HTTP check receiver timing in nanoseconds: Timing metrics now report in nanoseconds instead of milliseconds (#47257).

  • Kafka receiver Sarama removal: The Sarama client implementation was removed. franz-go is now the only supported Kafka client (#41480).

  • exporter/datadog:
    • Added Kubernetes host alias provider that automatically creates a nodeName-clusterName alias in Kubernetes environments (#47199).
    • Fixed tls.insecure_skip_verify not being honored for logs (#48523).
    • Fixed percentile aggregations collapsing to 0 for OTLP explicit-bucket histograms (#48478).

OpenTelemetry specification v1.57.0

The v1.57.0 release focused on Prometheus exporter stabilization and includes a set of config property renames that are action-required for operators.

Prometheus exporter property renames

Action required if you configure the Prometheus exporter via YAML.

Several Prometheus exporter configuration properties were renamed to eliminate double-negatives and inconsistent prefixes (#5071):

  • without_scope_info → scope_info_enabled
  • without_target_info → target_info_enabled
  • with_resource_constant_labels → resource_constant_labels

Update your exporter configuration when your SDK implementation adopts v1.57.0.

Prometheus compatibility stabilization

Continuing from prior releases, v1.57.0 stabilizes:

  • otel_scope_* label translation to OTLP Instrumentation Scope (#5004)
  • OTel Gauge and Sum → Prometheus transformations (#5034)
  • OTel Instrumentation Scope → Prometheus labels (#5052)
  • Prometheus exporter temporality, version and format, port configuration, and scope_info_enabled (#5024, #5083, #5026, #5056)

Semantic conventions v1.41.0

The v1.41.0 release is one of the most substantive semconv updates in months.

GenAI

The GenAI conventions gain comprehensive vocabulary for LLM operational telemetry:

  • time.to_first_chunk and per-chunk metrics for streaming support (#3113, #3598).
  • Reasoning output token tracking (#3194).
  • Response model attribute for embeddings (#3499).
  • Client operation exception events (#3436).
  • Breaking: GenAI tool call spans now require the tool name for span naming (#3595).

Kubernetes

  • PersistentVolume and PersistentVolumeClaim entity definitions with associated metrics (#3375)
  • CPU metrics for in-place container resize handling (#3558)
  • Container attributes promoted to release_candidate stability (#3491, #3380)

Stabilizations

  • deployment.environment.name reaches stable, with enum values added (Production, Staging, Test, Development) (#3339, #2910).
  • otel.event.name reaches stable (#2913).
  • telemetry.distro.* attributes promoted to stable (#3650).

Other breaking changes

  • process.executable separated into a dedicated entity (#3535).
  • client.address and client.port removed from RPC server spans (#3487, #3488).

Accepted proposals

Semantic convention schema v2

OTEP 4815 proposes a new schema format (manifest/2.0) that turns the Schema URL into a queryable endpoint for a fully resolved registry, rather than a list of version-to-version transformation diffs. The resolved registry is a single compiled file containing all attributes and signal definitions with full metadata, enabling use cases like telemetry data validation, cost-saving (dropping non-essential metrics based on schema annotations), and sanitization (redacting sensitive data based on declared attribute sensitivity). The old file format 1.1.0 and its transformation-based approach will be retired.

Beyond enriching the Schema URL payload, the proposal formalizes support for decentralized convention registries: Collector components, instrumentation libraries, and third-party organizations can publish their own conventions with a dedicated Schema URL, taking a dependency on OTel's central registry. The Schema URL pattern is extended to carry component and maturity information (e.g., opentelemetry.io/schemas/collector/1.0.0), and Weaver will provide tooling to package and publish these registries.

Partial reload for the OpenTelemetry Collector

Today, any configuration change to the Collector triggers a full pipeline teardown and rebuild, restarting every component regardless of whether it was affected. The Partial Reload RFC proposes diffing old and new configurations and restarting only the components that changed, along with any upstream components in the same pipeline. This directly addresses three costly categories of disruption: expensive reinitialization (the k8s_cluster receiver, for example, can take several minutes to resync on startup), in-memory state loss (processors like tail_sampling, deltatocumulative, and interval lose accumulated context on every restart), and cursor and checkpoint disruption (file_log re-reads files from the beginning; kafka triggers a consumer group rebalance).

The feature will be gated behind a service.partialReload flag and rolled out in phases: receivers first, then processors, exporters, pipelines, and connectors. When a partial reload fails or a component type is not yet covered by the current phase, the Collector falls back to a full reload transparently.

Datadog news

  • General availability of DDOT gateway mode: The Datadog Distribution of the OpenTelemetry Collector (DDOT) can now be deployed as a gateway to centralize telemetry ingestion across a fleet. Rather than distributing processing logic across every node, a gateway deployment applies tail-based sampling, batching, and tagging policies in a single layer before forwarding enriched data to Datadog and other destinations. This makes it easier to enforce consistent schema and sampling rules across teams without configuration drift among node-level collectors. Gateway deployments scale horizontally and integrate with Datadog Fleet Automation for discovery and configuration alongside existing DDOT Collectors and Datadog Agents.

  • DDOT FIPS compliance for Kubernetes: DDOT is now FIPS-compliant for Kubernetes environments. Built with Federal Information Processing Standard (FIPS) 140-2 validated cryptographic modules, it enables OTel-native telemetry collection in regulated environments and allows teams to maintain a consistent observability strategy across regulated and non-regulated deployments while meeting FedRAMP® security standards. It is available with Datadog Agent v7.79 and can be deployed via Fleet Automation.

Community blog posts

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.