Blog on OpenTelemetry

Keycloak's observability journey: a guide for project maintainers

Mon, 02 Nov 2026 15:39:10 +0000

As part of an ongoing series, the Developer Experience SIG interviews organizations about their real-world OpenTelemetry deployments to share practical lessons with the broader community. This post features Keycloak, a CNCF project, and looks at the journey from the perspective of project maintainers who add native OpenTelemetry support to the software they ship.

If you have ever needed an Identity and Access Management (IAM) solution, there is a good chance Keycloak was on your radar: a widely used, community-driven open source IAM system that secures applications by authenticating both human and non-human users through industry-standard protocols such as OpenID Connect (OIDC), OAuth 2.0, and SAML.

OpenTelemetry eBPF Instrumentation reaches v1.0.0

Fri, 30 Oct 2026 15:42:24 +0000

We’re excited to announce v1.0.0 of OpenTelemetry eBPF Instrumentation—OBI!

OBI brings OpenTelemetry observability to running Linux applications without requiring changes to their source code. It uses eBPF, together with runtime-specific instrumentation, to capture application metrics and traces across services, languages, and frameworks. You can start with request rates, errors, latency, and service dependencies, then build deeper visibility as your needs grow.

This release fulfills the flagship goal we set for 2026: establishing a stable foundation for OBI. It represents a year of expanding instrumentation coverage, improving correctness, strengthening release tooling, and building the compatibility and telemetry migration practices that users need to operate OBI over time.

Announcing the 2026 Governance Committee Election Results

Thu, 29 Oct 2026 16:31:20 +0000

We are delighted to announce the results of the 2026 OpenTelemetry Governance Committee Election!

The OpenTelemetry project continues to bring together an exceptionally vibrant community, who are shaping the future of observability with their contributions. This year, active contributors have shown their commitment again by participating in our election process, and they’ve done it in great numbers.

836 contributors were eligible to vote this year, and 345 of them cast their ballot. With a participation rate of 41%, it is in line with last year’s participation rate, where 273 ballots were cast with 702 eligible voters. (39%)

Only include resource detectors you need by building your own Collector

Thu, 29 Oct 2026 15:39:27 +0000

There are many reasons for building your own OpenTelemetry Collector distribution. The existing distributions are designed to be broadly useful, which means they include many more components than what an individual deployment uses. Building your own gives you the ability to select only the components you care about, add your own custom components, and control exactly what ends up in the binary you run in production.

One of the reasons I prefer to build my own distribution is to limit the size of the binary I have to ship around and to ensure that the least amount of dependencies are included. Fewer dependencies means a smaller binary, a smaller attack surface, and fewer third-party modules to track when a vulnerability is disclosed. The OpenTelemetry Collector Builder (ocb) makes this possible: you write a manifest file in YAML to select the components you care about, and ocb compiles them into the resulting binary.

Join us for OpenTelemetry Talks and Activities at KubeCon NA 2026

Wed, 28 Oct 2026 20:29:41 +0000

The OpenTelemetry project maintainers, members of the governance committee, and technical committee are thrilled to be at KubeCon NA in Salt Lake City from November 9 - 12, 2026. Register today to join us!

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

OpenTelemetry Contribfest

Join the OpenTelemetry maintainers for the OpenTelemetry Contribfest to make the project better for everyone. You can choose between several opportunities to contribute, and you can count on maintainers from different project areas to help you on your first steps. The Contribfest takes place on Tuesday, November 10 • 11:30 - 12:50.

Faster, smaller checkpoints: the File Log receiver now uses protobuf

Wed, 28 Oct 2026 18:28:33 +0000

If you run the File Log receiver with a storage extension, the Collector writes a checkpoint every time it polls your log files. That checkpoint is how the receiver remembers where it stopped reading, so a restart does not lose or duplicate logs. For years that checkpoint format was JSON.

Starting with OpenTelemetry Collector Contrib v0.164.0, checkpoints are always written as protobuf. On our benchmarks, saving a checkpoint is almost 5 times faster, loading one is more than 5 times faster, and the checkpoint itself is about 35% smaller.

OpenTelemetry Transformation Language reaches v1

Tue, 27 Oct 2026 15:00:47 +0000

The OpenTelemetry Transformation Language (OTTL) is now v1. Starting with opentelemetry-collector-contrib v0.164.0, OTTL is stable for traces, metrics, and logs.

The release of v1 means OTTL meets the Collector’s ‘stable’ stability criteria for testing, benchmarking, documentation, and telemetry. It also comes with a compatibility promise for all of 1.x. If you write OTTL statements, the syntax and the standard functions stay backward compatible. If you build your own components on top of OTTL, the Go API will also remain compatible.

The case for OpenTelemetry maintainership

Mon, 26 Oct 2026 17:00:03 +0000

I believe OpenTelemetry’s primary constraint isn’t ideas, code contributions, or adoption, but maintainers.

About me

I’ve been working on OpenTelemetry since early 2021. I’m a maintainer of opentelemetry-java, opentelemetry-configuration, and opentelemetry-injector, and a member of the Technical Committee. In that time I’ve worked at two observability companies, New Relic and now Grafana Labs, in roles with a charter to work on OpenTelemetry while also engaging in internal engineering efforts that depend on it. This post is my opinion, informed by involvement in a lot of different OpenTelemetry projects and by watching various contributors come and go.

Help us understand how you use OpenTelemetry's ecosystem lists

Fri, 23 Oct 2026 16:07:27 +0000

Do you use OpenTelemetry’s registry or ecosystem lists? Comment on the issue and tell us which pages you need and why.

We are reviewing the future of these pages. Understanding how people use them will help us focus our efforts within the maintainer time available.

Which pages are affected?

We have frozen new entries and updates to the following lists while we consider retiring or changing them:

Registry: libraries, Collector components, and other tools for using and extending OpenTelemetry.
Vendors: organizations offering solutions that consume OpenTelemetry.
Distributions: third-party distributions of OpenTelemetry components.
Integrations: software with OpenTelemetry support.
Adopters: organizations using OpenTelemetry.

The issue describes the current direction for each list, including retiring the registry in favor of the OpenTelemetry Ecosystem Explorer. The future of the other lists is still being discussed.

Strengthening OpenTelemetry security while preserving API stability

Thu, 22 Oct 2026 14:59:07 +0000

OpenTelemetry has updated its client versioning policy to make room for security fixes that need to change behavior. Stable SDKs and Contrib components, such as instrumentation libraries and exporters, can now make narrowly scoped, necessary security changes in minor or patch releases, even when those changes affect existing users. Public API compatibility remains protected.

The intent is to help users receive security improvements within the major version they already use. Some upgrades may require configuration or operational changes. In such cases, release notes must explain the impact and what to do.

The Humans of OpenTelemetry - KubeCon Japan 2026

Wed, 21 Oct 2026 11:33:27 +0000

We’re back with our fifth edition of Humans of OpenTelemetry, and for the first time, from Japan! At KubeCon + CloudNativeCon Japan 2026 in Yokohama, I interviewed OpenTelemetry end users and practitioners from the Japanese cloud native community, and learned how they got involved with OTel:

Yuzuru Ohira (LayerX)
Chikahisa Mikata (Loglass)
Yoshiki Fujikane (CyberAgent)
Takashi Okamoto (NTT DATA)
Kohei Sugimoto (MIXI)

The interviews were conducted in Japanese, and the transcript below is an English translation. We’ll add the video recording to this post once it’s published.

Announcing the 2026 OpenTelemetry Governance Committee Election Candidates

Mon, 19 Oct 2026 10:59:07 +0000

The OpenTelemetry Election Committee is excited to announce the final list of candidates for the 2026 OpenTelemetry Governance Committee election!

Eligible voters can help fill four Governance Committee seats through Helios Voting.

Voting opens: 26 October 2026 at 12:00 UTC.
Voting closes: 28 October 2026 at 23:59 Anywhere on Earth (AoE), equivalent to 29 October 2026 at 11:59 UTC.

For candidate photos, GitHub profiles, and statements, see the candidates page.

Antoine Toulme
Dan Gomez Blanco
Huxing Zhang
Josh Suereth
Juliano Costa
Kemal Akkoyun
Matthew Cascio
Pablo Baeyens Fernández
Trask Stalnaker
Vibhanshu Singh

To check your eligibility, see the voter roll. If the automated eligibility check doesn’t account for your contributions to the OpenTelemetry ecosystem, you can request an exception before 23 October 2026 at 23:59 AoE to vote.

Versioned metrics: Shipping the first Release Candidate metrics in hostmetrics

Tue, 13 Oct 2026 23:35:21 +0000

OpenTelemetry Collector Contrib v0.160.0 adds the ability to emit release candidate (RC) process semantic conventions metrics to the hostmetrics receiver’s process scraper, the last stage before a stable v1. The System SIG has worked on this for the better part of a year, and we think that the process metrics are in a good shape – but RC exists so the community can prove that. If you collect process metrics, we’d like you to try the new versioned output and tell us what breaks.

Prometheus and OpenTelemetry interoperability in 2026: Survey results

Mon, 12 Oct 2026 06:51:10 +0000

We ran a survey asking users of OpenTelemetry and Prometheus how they collect, process, and store metrics. The goal was to understand, with real usage data rather than assumptions, how far the ecosystem has moved and whether the interoperability still causes friction.

Key takeaways

Interoperability has measurably improved since our 2024 survey: the average ease-of-use rating rose from 3.1 to 3.6, the equivalent of one in two respondents rating a whole category higher, and the share of respondents finding the two hard to use together fell from 29% to 10%.
In infrastructure instrumentation, Prometheus exporters remain the most-used method (72%) with OTel receivers close behind (57%), and nearly half of respondents run both at once rather than migrating from one to the other.
In application instrumentation, OTel SDKs are the most-used method at 65% with Prometheus SDKs at 52%, and 41% use only the OTel style of application instrumentation.
Prometheus relabeling rules (54%) and the open source OTel Collector (53%) are the two most common processing steps, and 65% of respondents run a “vanilla stack” of one or both with no vendor transformation or custom Collector build anywhere in the pipeline.

Demographics

From 186 people who responded, 81 passed our screening for active OpenTelemetry-for-metrics users on a Prometheus-adjacent backend. We also filtered out observability vendor employees to focus on end users. In the analyzed sample:

OTel-Native by Design - Building Products That Export to Any Observability Stack

Fri, 09 Oct 2026 15:50:03 +0000

With contributions from Dan Gomez Blanco (New Relic).

If you’re building self-hosted software or a SaaS product, your users will eventually ask to send logs, traces, and metrics to their own observability stack, whether to satisfy compliance, manage costs, or centralize all their observability data in one place.

Locking them into your built-in dashboards or limiting exports to certain vendors creates unnecessary friction. Instead, supporting export to any OpenTelemetry (OTel)-compatible backend is a vendor-neutral, future-proof practice that gives users the freedom to choose their observability stack.

OpenTelemetry Community Awards 2026

Wed, 07 Oct 2026 14:01:16 +0000

We are delighted to announce the 3rd annual OpenTelemetry Community Awards this year!

This project and its newly minted status as a graduated CNCF project would not be possible without many, many awesome humans who contribute their time, knowledge, and skills to further develop and improve the field of observability.

Whether it’s through code, documentation, project management, outreach, content creation, adoption, or simply helping others answer technical questions on our CNCF Slack, we want to recognize these contributions and the people behind them.

The OpenTelemetry Java agent 3.0 is almost here — preview it today

Tue, 06 Oct 2026 16:43:08 +0000

The 2.32.0 release of the OpenTelemetry Java agent is now out and serves as the release candidate for 3.0, which is targeted for October 2026. Some behavior may still change before 3.0, but you can preview the new behavior now, before it becomes the default.

3.0 changes telemetry, configuration, and instrumentation defaults. Database and code conventions become stable defaults, messaging adopts newer conventions that are still experimental, and some capture settings and instrumentation defaults change. What to check covers each area.

Zero-code trace-log correlation with OBI

Tue, 06 Oct 2026 10:19:48 +0000

You get paged. A trace shows a request failing in one of your services, and you know the answer is in the logs — but which log lines belong to that request? If the service never adopted structured logging with trace context, the honest answer is: you grep by timestamp and hope.

OpenTelemetry eBPF Instrumentation (OBI) can now add that missing trace context to the logs your services already write. Your applications don’t change: no SDK, no logging-library configuration, no application rebuild or redeploy.

Exploring the OpenTelemetry Instrumentation Ecosystem

Fri, 25 Sep 2026 11:24:23 +0000

OpenTelemetry has a lot of pieces: APIs, SDKs, a protocol, semantic conventions, instrumentation, and tools like the Collector. The APIs and protocol define how telemetry is created and exchanged, while instrumentation is what actually observes what happens inside an application and turns it into telemetry. Semantic conventions give the people writing that instrumentation a shared way to describe what they’re observing.

The beauty of this approach is that completely separate authors can instrument different libraries, in different languages, and still produce telemetry that follows the same contract. An HTTP request looks like an HTTP request, regardless of which library or language produced it. Users can then build queries, dashboards, and other tooling around that shared understanding. Once we’ve agreed on the conventions, everything should line up.

Announcing the 2026 OpenTelemetry Governance Committee Election

Mon, 21 Sep 2026 17:09:33 +0000

The OpenTelemetry project is excited to announce the 2026 OpenTelemetry Governance Committee (GC) election. Nominations are due by 16 October 2026 23:59 AoE. The list of eligible candidates will be shared on 19 October 2026. Voting will take place between 26 October 2026 12:00 UTC and 28 October 2026 end of day AoE (29 October 2026 11:59 UTC), and the final election results will be announced 30 October 2026.

Vote!

If you are a member of standing in the OpenTelemetry community, we invite you to participate with your vote in this election to ensure that the community is well-represented in the Governance Committee. In this election four people must be elected, each with two-year terms.