OTel News

January 2026

January 2026

Curated by:

Welcome to the January 2026 edition of the OpenTelemetry News! In this month's edition, we cover project updates from December 2025 and January 2026.

Highlights

OTel Unplugged EU at FOSDEM 2026

On February 2 (Monday after FOSDEM), the OpenTelemetry community will gather in Brussels for OTel Unplugged EU. This event is a fantastic opportunity to connect with maintainers and other users to get your questions answered and give feedback to the project. This is also an opportunity to give suggestions and vote on OTel's roadmap for 2026.

There will also be an opportunity to engage with Datadogs working actively on OpenTelemetry. Find us at our community booth for some good discussions and great swag!

FOSDEM 2026

FOSDEM is a free event for software developers to meet, share ideas and collaborate. This year, FOSDEM will take place on January 31 and February 1 in Brussels, Belgium.

Two OTel related sessions in two different devrooms will be delivered by Datadog engineers:

OTLP HTTP/GRPC Exporter Renaming (Not a Breaking Change)

With the release of the OTel Collector version 0.144.0, as part of ongoing efforts to improve clarity and usability within the OpenTelemetry Collector, the OTLP exporters have been renamed.

The otlp exporter is now referred to as otlp_grpc, while the otlphttp exporter has been renamed to otlp_http. Deprecated aliases for the previous names have been added to ensure backward compatibility. This change aims to provide a clearer distinction between the two exporters and enhance the overall user experience.

Most of demos and documentation online may still refer to the old names, so please be aware of this change when configuring your OTel Collector using versions >= 0.144.0.

You can read more about it in this GitHub issue.

New Collector Releases

This news edition covers the OpenTelemetry Collector releases 0.142.0, 0.143.0 and 0.144.0.

Below, we highlight selected changelog entries from the core and contrib distributions.

General Updates

  • exporter/debug: Added logging of dropped attributes, events, and links counts in detailed verbosity (#14202)

  • extension/health_check: Added extension.healthcheck.useComponentStatus feature gate to enable v2 component status reporting in healthcheckextension while maintaining backward compatibility by default. (#42256)

  • processor/lookup: Added the initial skeleton for a lookup processor that performs external lookups to enrich telemetry signals. (#41816)

  • processor/resourcedetection: Added container.image.name and container.name as optional resource attributes with the docker detector. (#44898)

  • processor/tail_sampling: Provided an option, decision_wait_after_root_received, to make quicker decisions after a root span is received. (#43876)

  • processor/transform: New Transform Processor function set_semconv_span_name() added to overwrite the span name with the semantic conventions for HTTP, RPC, messaging, and database spans. (#43124)
    Usage example:

    processors:
  # prevent high-cardinality span names
  transform/sanitize_span_name:
    error_mode: ignore
    trace_statements:
      - set_semconv_span_name("1.37.0")

  • exporter/datadog:

    • Introduced a container tags buffer in the stats writer, which is disabled by default. It defers writing of payloads for new containers until tags are resolved or the container is older then 10s. This buffer is applied to spans post sampling and to aggregated APM stats. (#44661)

    • Updated the Datadog exporter to support the Orchestrator Explorer by accepting receiver/k8sobjects logs and sending Kubernetes data to the Datadog endpoint. (#44523)
      The Cluster name field in Orchestrator Explorer Configuration has been removed. Use the k8s.cluster.name attribute instead.

  • extension/datadog:

Community Proposals

[Donation Proposal]: Dart SDK and API for OpenTelemetry

A proposal has been submitted to donate a full OpenTelemetry API and SDK for Dart to the OpenTelemetry project.

The OTel Governance Committee has discussed the proposal and indicated openness to establishing a Dart SIG, contingent on multiple maintainers from different companies committing sustained time. A formal Call for Contributors via the OpenTelemetry blog has been suggested to help build a cross-company maintainer base.

If you are interested in contributing to the Dart SDK and API for OpenTelemetry, join the discussion on the GitHub issue.

Opt-In Metrics Advisory Parameter Proposed

A new OptIn advisory parameter has been proposed for OpenTelemetry metrics, allowing instrumentation authors to define metrics that are disabled by default. When marked as OptIn, the SDK drops these metrics unless users explicitly enable them via Views (using a new enabled=true option, including wildcard views).

You can read more about it in this GitHub issue.

View-based Metric Levels Proposed

A proposal has been made to introduce view-based metric levels in OpenTelemetry. This feature would allow users to categorize metrics into different levels (e.g., basic, detailed) and control their collection and export based on these levels using Views.

You can read more about it in this GitHub issue.

Proposed roadmap for cAdvisor

The Kubernetes Node SIG has proposed a roadmap to transition cAdvisor away from its current role in Kubernetes and standalone usage, aligning container and node metrics collection more closely with OpenTelemetry. The roadmap is currently under discussion and requires agreement across communities.

You can read more about it in this GitHub issue.

Semantic Conventions 2026 Roadmap Proposed

The Semantic Conventions community is gathering early input on potential 2026 priorities, with a focus on stability, decentralization, and future areas for standardization. This is a work-in-progress discussion, not a final roadmap, and feedback from all semconv sub-SIGs is explicitly requested.

You can read more about it in this GitHub issue

OpenTelemetry Blog Posts

Below are some highlights from recent OpenTelemetry blog posts published in December 2025 and January 2026.

You can check out all the posts on the OpenTelemetry blog.

Demystifying OpenTelemetry: Why You Shouldn’t Fear Observability in Traditional Environments

The author debunks common myths about observability in legacy, industrial, and Windows-based environments, showing how OpenTelemetry can incrementally turn unstructured logs, MQTT streams, SQL Server databases, and classic Windows systems into actionable metrics and traces without ripping and replacing existing infrastructure.
Read the post >

Reducing Log Volume with the OpenTelemetry Log Deduplication Processor

The blog explains how the OpenTelemetry Collector’s log deduplication processor reduces log noise and storage costs by aggregating repetitive log entries into a single enriched record, while preserving frequency information.
Read the post >

Improving Async Workflow Observability in Dapr

The authors describe how cross-project collaboration improved Dapr’s OpenTelemetry integration by restoring trace context across asynchronous workflows, producing coherent end-to-end traces and laying the groundwork for better semantic conventions and modeling of async behavior across the CNCF ecosystem.
Read the post >

Datadog Blog Posts

Datadog LLM Observability natively supports OpenTelemetry GenAI Semantic Conventions

Datadog’s native support for OpenTelemetry GenAI Semantic Conventions was released, enabling teams to instrument GenAI applications once with OTel. Users can enforce governance through the Collector, and analyze standardized GenAI spans for performance, quality, and cost directly in Datadog LLM Observability without code changes.
Read the post >

Manage all your OpenTelemetry collectors with Datadog Fleet Automation

Datadog Fleet Automation is available for preview as a way to centrally manage and troubleshoot OpenTelemetry Collector fleets at scale, providing unified visibility into Collector inventory and live configurations to reduce drift, simplify governance, and accelerate issue resolution.
Read the post >

Centralize and govern your OpenTelemetry pipeline with the DDOT gateway

DDOT gateway is available for preview as a centralized, scalable OpenTelemetry gateway that lets platform teams standardize governance, apply advanced processing and routing, and manage OTel pipelines at enterprise scale with consistent visibility and control.
Read the post >

Get Involved

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

Resources