Blog on OpenTelemetry

OpenTelemetry.io 2025 review

Fri, 10 Apr 2026 12:43:42 -0400

As 2025 has come to an end, we’re taking a moment to look back at everything the community accomplished across the website, documentation, and localization efforts. The year was another exciting chapter for OpenTelemetry.io, and we are thrilled to share some of the highlights with you.

Highlights of 2025

Where 2024 introduced the foundation of multilingual documentation, 2025 is when localization became a core pillar of OpenTelemetry.io. This means more contributors, more translations, more supported languages, and more visibility for localized content.

OBI Gives Incident Response the Request Context It Needs

Fri, 10 Apr 2026 00:41:53 -0700

When incidents are active, traces usually tell you that something is wrong. The harder problem is figuring out who is affected and why, quickly.

OpenTelemetry eBPF Instrumentation (OBI) v0.7.0 adds HTTP header enrichment so spans can carry request context like tenant or user segment. That context is often exactly what helps you move from “error rate is up” to “this is isolated to one customer cohort”.

The best part: this is a config change on OBI itself. You do not need to rebuild or redeploy your existing applications.

Inside Adobe's OpenTelemetry pipeline: simplicity at scale

Wed, 08 Apr 2026 16:29:48 +0200

As part of an ongoing series, the Developer Experience SIG interviews organizations about their real-world OpenTelemetry Collector deployments to share practical lessons with the broader community. This post features Adobe, a global software company whose observability team has built an OpenTelemetry-based telemetry pipeline designed for simplicity at massive scale, with thousands of collectors running per signal type across the company’s infrastructure.

Organizational structure

Adobe’s central observability team is responsible for providing observability infrastructure across the company. However, as Bogdan Stancu, Senior Software Engineer, explained, Adobe’s history of acquisitions means the landscape is not fully consolidated. Some large product groups have their own dedicated observability teams, while the central team serves as the primary provider.

OpenTelemetry Profiles Enters Public Alpha

Thu, 26 Mar 2026 08:12:06 -0700

Since OpenTelemetry first introduced Profiles, momentum has only grown towards building a unified industry standard for continuous production profiling, standing alongside traces, metrics, and logs. Today, the Profiling SIG is proud to announce that the Profiles signal has officially entered public Alpha, and we are ready for broader community use and feedback.

Production profiling for all

Continuously capturing low-overhead performance profiles in production is a technique that has been used for decades. It helps troubleshoot production incidents, improves user experience by making software faster and reduces computation costs by making the same work take less resources. Historically, the industry lacked a common framework and protocol for continuous profiling, even with formats like JFR and pprof being popular.

New OpenTelemetry Kotlin SDK

Mon, 23 Mar 2026 12:59:28 +0000

Following a donation from Embrace and a call for contributors, OpenTelemetry now has a Kotlin SDK in active development.

The project is looking for contributors and folks who are interested in using the library in their application.

Why launch OpenTelemetry for Kotlin?

Kotlin Multiplatform (KMP) allows running Kotlin code on many different platforms, such as browser, server, and desktop environments. Traditionally Kotlin has been most popular on Android and the JVM, but with the advent of KMP the number of folks using it to share code between different platforms has been steadily growing.

Beyond the good first issue - How to make your contributions sustainable

Thu, 19 Mar 2026 15:14:35 +0100

OpenTelemetry provides the tools and standards to collect metrics, logs, and traces from applications and services. Getting started with contributions can feel overwhelming, so here are some lessons from hands-on experience.

Most guides explain how to find a “good first issue,” fork a repository, or join a SIG meeting. That advice is useful, and many resources cover it well. What often receives less attention is the broader context around contributing: understanding the ecosystem, navigating community dynamics, and building long-term engagement in a large open source project.

How Mastodon Runs OpenTelemetry Collectors in Production

Wed, 18 Mar 2026 18:10:54 +0100

At the beginning of 2025, the OpenTelemetry Developer Experience SIG published the results of its first community survey. One of the strongest themes was clear: teams want more real-world examples of how the OpenTelemetry SDKs and the OpenTelemetry Collector are actually used in production.

To help close that gap, the SIG began collecting stories directly from end users—across industries, architectures, and company sizes. This post kicks off a new series focused specifically on organizations’ real world stories, starting with a small but uniquely challenging case.

Deprecating Span Events API

Wed, 18 Mar 2026 10:28:12 +0100

OpenTelemetry is deprecating the Span Event API. This post explains why we’re making this change, what it means at a high level, and how you can prepare. In short:

We want to remove confusion and duplication caused by having two overlapping ways to emit events: span events and log-based events.
New code should write events as logs that are correlated with the current span.
The older “span events” style will be phased out over time, but existing data and views that show events on spans will keep working.

Why deprecate the Span Event API?

Today, OpenTelemetry offers two main ways to emit events that are correlated with traces:

Kubernetes attributes promoted to release candidate in OTel Semantic Conventions

Mon, 16 Mar 2026 17:14:23 +0200

Over the past few months, the K8s (Kubernetes) Semantic Conventions SIG focused on stabilizing Kubernetes attributes used by OpenTelemetry Collector processors such as k8sattributes and resourcedetection. That work has now paid off: Kubernetes attributes have been promoted to release candidate status. Users can try this new schema via feature gates and provide feedback before the final stable release. Read on to discover how we reached this milestone and what’s on the horizon.

Declarative configuration is stable!

Thu, 05 Mar 2026 15:01:29 -0600

What happened?

Key portions of the declarative configuration specification have been marked stable, including

The JSON schema for the data model, as defined in opentelemetry-configuration which released a stable 1.0.0 release
The YAML representation of the data model in files (spec link)
The in-memory representation of the data model (spec link)
The generic representation of a YAML mapping node, ConfigProperties (spec link)
The mechanism for referencing custom plugin components in the data model, PluginComponentProvider (spec link)
The SDK operations for parsing a YAML file and instantiating SDK components, Parse and Create (spec link)
The standard env var to indicate that declarative config should be used and to point to the path of a config file OTEL_CONFIG_FILE (spec link)

What’s the status of language implementations?

As of now, there are implementations available in five languages:

KubeCon + CloudNativeCon Europe 2026

Wed, 04 Mar 2026 01:17:41 +0800

The OpenTelemetry project maintainers, members of the governance committee, and technical committee are thrilled to be at KubeCon EU in Amsterdam from March 23 - 26, 2026. Register today to join us!

Read on to learn about all the events related to OpenTelemetry during KubeCon.

Talks and maintainer sessions

We Deleted Our Observability Stack and Rebuilt It With OTel: 12 Engineers to 4 at 20K+ Clusters
by Yash Sharma, DigitalOcean; Kunju Perath, DigitalOcean
Tuesday March 24, 2026 11:15 - 11:45CET

OTTL context inference comes to the Filter Processor

Mon, 02 Mar 2026 13:04:59 +0000

Last year, the OpenTelemetry project introduced OTTL context inference for the transform processor. The goal was to allow users to write OTTL statements without worrying about internal telemetry contexts.

Starting with collector-contrib v0.146.0, context inference is available in the Filter Processor through four new top-level config fields: trace_conditions, metric_conditions, log_conditions, and profile_conditions.

In this post, we’ll look at what context inference means specifically for filtering: how it simplifies configuration and how evaluation works.

What's Up, OTel? It's us, your community managers!

Thu, 26 Feb 2026 10:16:47 -0800

Hi, community! We are your newly appointed Community Managers. We’ve begun the initial transitional work behind the scenes, and we look forward to seeing more of you all in the very near future (KubeCon EU, anyone?). With great power comes great responsibility, and we want to hear from you as we look into expanding both the project and the community.

In the meantime, we wanted to (re-)introduce ourselves, and invite you to connect with us! Feel free to find us over on CNCF’s Slack; for now, you can ping us directly in #opentelemetry (we’re working on creating one single @ so you can easily reach all of us).

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

Tue, 24 Feb 2026 07:56:51 -0500

For decades, traditional technology environments, ranging from on-premises data centers to legacy applications and industrial control systems, have powered the core of many organizations. These systems are battle-tested and deeply woven into business operations, but they also present unique challenges when it comes to modernizing IT practices, especially observability.

Challenges of implementing observability in traditional environments:

Noisy, unstructured logs make it hard to extract meaningful information.
Siloed monitoring data across different tools or systems leads to fragmented visibility.
Limited instrumentation in legacy apps and systems hinders collection of modern metrics and traces.
Teams are often concerned about the potential performance impact from adding new observability tooling.
Bridging legacy protocols or hardware with modern platforms can be difficult to integrate.

To make this practical, let’s follow a fictional manufacturing company with a busy production line. Here, a fleet of robotic arms equipped with sensors reports operational data via MQTT to a central broker. A legacy application logs production events and errors to disk, while a collection of SQL Servers and Windows machines support production, analytics, and inventory. Sound familiar? This is the reality for many organizations trying to bridge the old and new worlds.

Welcoming New Community Managers to OpenTelemetry

Fri, 06 Feb 2026 12:09:03 -0500

Back in October 2022, I wrote about becoming OpenTelemetry’s first community manager. At the time, the project had just over 5000 contributors. Since then, those numbers have grown considerably – almost 20,000 people have contributed to the project! As our community grows, the role and scope of community management must grow with it.

Community management matters a lot in open source, and while I’m proud of what we’ve accomplished together over the past few years, I’ve reached a point where I can no longer dedicate the time and focus this work demands. The role deserves someone who can give it their full attention.

OpenTelemetry Collector Follow-up Survey

Wed, 28 Jan 2026 19:23:38 +0100

In 2024, the End User SIG conducted a Collector Survey to gather feedback on how the OpenTelemetry Collector is used in practice and the user experience. Insights from that survey informed several development and prioritization decisions within the community.

As a follow-up, we conducted another survey in 2025 to understand how deployment practices, usage patterns, and implementation challenges have evolved since then. This blog post presents an analysis of the results, highlighting notable changes compared to the previous year.

Reducing Log Volume with the OpenTelemetry Log Deduplication Processor

Mon, 26 Jan 2026 18:47:07 -0500

Your logs are probably at least 80% repetitive noise. Connection retries, health checks, heartbeat messages: the same log line repeated thousands of times per minute. You pay storage costs for each one while the signal drowns in noise. The OpenTelemetry Collector’s log deduplication processor offers an elegant solution to this problem.

The repetitive log problem

Modern distributed systems generate enormous volumes of logs, but much of that volume provides diminishing returns. Consider a typical microservice that logs connection errors when a downstream dependency is unavailable. If the service retries every 100 milliseconds for 30 seconds, that’s 300 nearly identical log entries for a single incident. Each entry consumes storage, network bandwidth, and processing capacity in your logging backend.

OpenTelemetry eBPF Instrumentation 2026 Goals

Fri, 23 Jan 2026 07:56:48 -0800

As we kick off 2026, the OpenTelemetry eBPF Instrumentation SIG has come together to set an ambitious roadmap for the year. Our focus is on achieving production readiness with a stable 1.0 release while expanding protocol and language support to serve a broader range of use cases. We’re also strengthening integration with OpenTelemetry APIs and SDKs to support hybrid instrumentation approaches. For those new to OBI, check out the documentation link above to learn more about zero-code observability using eBPF.

Improving Async Workflow Observability in Dapr

Wed, 21 Jan 2026 20:54:34 +0100

This post tells the story of how contributors from across the cloud native community worked together to enhance Dapr’s OpenTelemetry integration, particularly around asynchronous workflows. It also highlights the ongoing effort to align Dapr with the OpenTelemetry semantic conventions using OpenTelemetry Weaver, and explores how this collaboration can serve as a useful example for other CNCF projects. None of this work started as a formal initiative. It emerged through discussion, experimentation, and a shared goal of making telemetry easier to understand and more consistent across the ecosystem.

OpenTelemetry JS Statement on Node.js DOS Mitigation

Thu, 15 Jan 2026 16:35:52 -0500

You may have seen a recent Node.js security advisory and related coverage discussing a potential denial-of-service issue involving async_hooks. OpenTelemetry (and other APM tools) were mentioned because we rely on AsyncLocalStorage for context propagation.

To be clear: this is not a bug or vulnerability in OpenTelemetry. The issue ultimately lies in applications and frameworks that rely on unspecified stack space exhaustion behavior for availability. In Node.js versions before 24.x, AsyncLocalStorage is implemented on top of async_hooks, which - when combined with this unsafe assumption — made the edge case easier to reproduce.