Blog on OpenTelemetry

OTel-Arrow Phase 2: From Efficient Transport to Efficient Telemetry Pipelines

Fri, 12 Jun 2026 17:47:46 -0700

Phase 1 of OTel-Arrow established OTAP, the OpenTelemetry Arrow Protocol, as an efficient transport protocol for OpenTelemetry. Apache Arrow is a language-independent, columnar in-memory format designed to move and process structured data efficiently across systems. We demonstrated that telemetry could be transported with significantly lower network overhead while preserving compatibility with the OpenTelemetry data model.

Phase 2 asked a different question: what happens if Arrow is used not only on the wire, but also as the representation the pipeline works with internally?

OpenTelemetry is a CNCF Graduated Project

Thu, 21 May 2026 07:27:48 -0700

Today, the Cloud Native Computing Foundation (CNCF) announced that OpenTelemetry has graduated.

Graduation is an important milestone for the project and reflects the strength of the OpenTelemetry community and ecosystem. Since the merger of OpenTracing and OpenCensus, thousands of contributors, maintainers, end users, and organizations have helped shape OpenTelemetry into an open, vendor-neutral observability framework used across the industry.

This milestone belongs to the community.

We want to thank everyone who has contributed code, documentation, specifications, language SDKs, semantic conventions, bug reports, reviews, community support, advocacy, and end-user experiences. OpenTelemetry exists because of the people who continue to invest their time and expertise in the project every day.

Applying OpenTelemetry Security Practices in Legacy Environments

Tue, 19 May 2026 09:38:41 -0400

OpenTelemetry is gaining traction in manufacturing and other legacy environments as organizations explore modern observability approaches. However, applying these practices in traditional systems introduces a different set of security challenges. The constraints of legacy infrastructure fundamentally change where and how security controls must be applied.

Legacy and industrial environments often include:

Systems that cannot be modified or instrumented
Long equipment life cycles and limited patching windows
Flat or weakly segmented networks
Sensitive operational data that is not typical PII

This article focuses on what is different about securing OpenTelemetry in these environments, and how to adapt your approach accordingly.

Inside the LLM Call: GenAI Observability with OpenTelemetry

Thu, 14 May 2026 23:05:07 +0800

Your AI agent just took 45 seconds to answer a simple question. Was it the model? A slow tool call? A retry loop? Every time an application calls an LLM, a chain of model calls, tool invocations, and token exchanges happens behind the scenes — and without observability, you are guessing.

The OpenTelemetry Semantic Conventions for Generative AI give you that visibility. They standardize how GenAI operations are recorded — the model being called, input and output token counts, and when opted in, the full content of prompts, completions, tool calls, and tool results.

Introducing OTel Blueprints and Reference Implementations

Tue, 12 May 2026 16:04:58 +0100

It’s not uncommon for end users adopting OpenTelemetry to, at some point in their journey, ask themselves: “Why is this stuff so complex?”. Full adoption normally requires understanding the different ways of configuring SDKs, multiple Collector deployments, data pipelines, instrumentation libraries, semantic convention registries, APIs for manual instrumentation across many different programming languages, and many other moving pieces.

These moving pieces don’t operate in isolation either. They need to work well together as part of a consolidated solution to describe an organization’s software systems using standard, high-quality telemetry. Failing to do so risks ending up with the very problem that OpenTelemetry was designed to solve: disjointed telemetry with disparate semantic conventions in use across the stack, lack of context propagated between services and signals, unnecessarily high data volumes… In general, poor quality telemetry, the opposite of what we need.

Introducing the Ecosystem Explorer Project

Thu, 30 Apr 2026 05:23:27 -0400

OpenTelemetry is vast. The Java agent alone includes over 240 different auto-instrumentations. The Collector has hundreds of components. Python, JavaScript, Go, and .NET each have their own ecosystems of instrumentation libraries, each with its own patterns and conventions.

In our 2025 Developer Experience Survey, users said that “documentation is difficult to navigate, requiring users to switch between the OpenTelemetry website and GitHub repositories” and that they often have to “piece together information from various sources.” Only about half of users rely on opentelemetry.io as their primary resource; the rest turn to GitHub, vendor documentation, or wherever they can find answers.

OpenTelemetry Japanese Community Survey

Tue, 28 Apr 2026 16:18:07 +0200

This report presents findings from the OpenTelemetry Japanese Community Survey, conducted to understand the current landscape of OTel awareness, adoption, and community engagement among developers and engineers in Japan. The survey targeted practitioners across roles such as development, SRE, DevOps, and Platform Engineering, distributed through CNCF community channels and Japanese social platforms like X (formerly Twitter), Qiita, and Zenn. The goal was to develop data-driven strategies that can meaningfully grow OTel usage and engagement within Japan’s tech ecosystem.

Deprecating OpenTracing compatibility requirements

Thu, 23 Apr 2026 00:54:39 -0700

On March 19, 2026, the OpenTelemetry Specification project merged PR #4938, deprecating OpenTracing compatibility requirements in the specification.

This change updates the specification to match where the ecosystem already is: OpenTracing has been archived for years, and new integrations are expected to use native OpenTelemetry APIs and SDKs instead of building on OpenTracing shim requirements.

This is a deprecation of specification requirements, not an immediate removal of compatibility material and not a requirement to remove existing shim artifacts right away.

How Skyscanner scales OpenTelemetry: managing collectors across 24 production clusters

Tue, 21 Apr 2026 09:54:19 +0200

The Developer Experience SIG is publishing a series of blog posts featuring real-world OpenTelemetry deployments from companies across different industries and scales. This post features Skyscanner, a global travel search platform based in Edinburgh, Scotland.

With 1,400 employees worldwide running over 1,000 microservices across 24 production Kubernetes clusters, Skyscanner’s journey with OpenTelemetry offers valuable lessons for organizations operating at scale.

Organizational structure

The Hubble team, consisting of six platform engineers, manages most of Skyscanner’s collectors. As part of the wider platform engineering organization, they handle the compute platform that runs Skyscanner’s primarily Java-based microservices architecture.

OpenTelemetry Accepted Elastic's PHP Distro Donation

Thu, 16 Apr 2026 08:49:17 -0700

The OpenTelemetry community accepted the donation of the OpenTelemetry PHP Distro project. This post summarizes what the donation enables, how it relates to existing PHP instrumentation paths, and where contributors can help next.

Why this donation matters

OpenTelemetry provides a common observability standard, but OpenTelemetry PHP adoption can still be difficult in environments where installing or compiling native extensions is restricted. Common blockers include:

Restricted or hardened systems where native extensions cannot be built during deployment.
Runtime images that are not rebuilt frequently.
Operational workflows that rely on OS package managers.

The PHP Distro addresses these constraints by focusing on an operations-first installation model.

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:

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.