Blog on OpenTelemetry

Lambda-powered functions land in OTTL

Wed, 22 Jul 2026 22:04:49 +0200

As telemetry pipelines become more sophisticated, so do the transformations they need to perform: sanitizing sensitive data, normalizing inconsistent schemas, and enforcing attribute contracts. While OTTL provides a rich set of transformation functions, expressing collection operations has required dedicated functions with hardcoded behavior for each new use case.

OpenTelemetry Collector Contrib v0.157.0 changes that by introducing lambda expressions to OTTL. Lambdas let users pass inline logic directly to generic higher-order functions, making complex collection transformations both reusable and concise. The release includes eight new functions that leverage this capability: Filter, MapEach, MapKeys, Any, All, Find, Reduce, and When.

CocoaPods Deprecation Notice for OpenTelemetry Swift

Mon, 20 Jul 2026 07:05:37 -0700

As it was announced via CocoaPods Support Plan and via CocoaPods Spec Repository, CocoaPods is transitioning their project to maintenance mode, and cocoapods trunk is going to be read-only in a few months.

The OpenTelemetry Swift maintainers are planning to deprecate CocoaPods support for all the pods published under opentelemetry-swift and opentelemetry-swift-core.

Swift Package Manager (SPM) is now the recommended and preferred installation method for all new integrations.

We encourage existing CocoaPods users to begin planning a migration to SPM.

Announcing v1 of OpenTelemetry Go Compile-Time Instrumentation

Thu, 16 Jul 2026 21:04:14 +0200

If you write Java, Python, Node.js, or .NET, you have been able to add OpenTelemetry to an application without editing its code for years: attach an agent at startup and telemetry starts flowing. Go has been the exception. A Go program compiles to a single static binary with no runtime to hook into at startup, so Go developers have had to instrument by hand or reach for an out-of-process eBPF agent.

OpenTelemetry Has Graduated… Now what?

Wed, 15 Jul 2026 14:59:02 -0400

In case you missed it: OpenTelemetry (OTel) has officially achieved CNCF graduated status! It now stands proudly alongside amazing open source projects such as Kubernetes and Prometheus, to name just a few. It’s been a long journey, and we’re very excited… But, now what? To understand where we’re going, it’s important to understand where we came from.

History

In the not-so-distant past, telemetry signals were not standardized. This meant telemetry formats differed from tool to tool, with each telemetry vendor creating and maintaining its own instrumentation libraries. Vendor lock-in was a huge problem: If you wanted to switch vendors, you had to strip out the previous vendor’s libraries from your code and replace them with the new vendor’s libraries. As a result, switching vendors was a nontrivial task.

The Voyage of a Small Environment Variable

Tue, 14 Jul 2026 09:47:36 +0200

The OpenTelemetry Spring Boot starter gained declarative-configuration support starting in version 2.26.0 — the same YAML schema the Java agent introduced in late 2025, now embedded inside application.yaml. This post traces what one env var, OTEL_SERVICE_NAME=petclinic, does in that new world, and where the seams are.

In a hurry?

Jump straight to the Spring Boot starter declarative-config docs, paste your application.properties into the interactive converter, or pick your SDK setup in the Ecosystem Explorer with the Spring Boot starter target selected. Come back for the story when you have a coffee.

Call for Contributors: OpenTelemetry for Dart and Flutter

Mon, 13 Jul 2026 10:20:00 +0200

Why OpenTelemetry for Dart and Flutter?

Dart is a full-stack language and the language of Flutter, one of the most popular frameworks for building cross-platform applications. Data shows over 20% of current app store submissions are Flutter apps. Dart is null safe and type safe, compiles to fast binaries, and is increasingly used for backend services as well. Yet Dart remains the last top-15 programming language without an officially maintained OpenTelemetry SDK. Earlier community implementations are no longer maintained, leaving Dart and Flutter developers without a supported path to capture telemetry from their servers and apps.

Don't Wrap OpenTelemetry — You're Probably Hurting More Than Helping

Wed, 24 Jun 2026 14:12:08 +0530

There’s a pattern I’ve seen across many teams adopting OpenTelemetry, and it’s well-intentioned every single time. An engineer wants to make things easier for the team. They build a thin abstraction over the OTel API — an IMetric interface, a TelemetryHelper class, a MetricsWrapper module — and ship it as the team’s standard. “Just use this,” they say. “It’s simpler.”

The intention is genuine. The outcome is usually not good.

Deprecating OpenCensus compatibility requirements

Fri, 19 Jun 2026 15:53:47 -0700

On June 12, 2026, the OpenTelemetry Specification project merged PR #5138, deprecating OpenCensus compatibility requirements in the specification.

This change updates the specification to match where the ecosystem already is: OpenCensus has been archived since July 31, 2023, and the OpenTelemetry shims for OpenCensus have provided a stable migration bridge for more than three years.

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.

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.