Blog on OpenTelemetry

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.

Join us for OpenTelemetry Talks and Activities at KubeCon NA 2026

Tue, 20 Oct 2026 19:58:06 +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.

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.

Dual-exporting .NET metrics with OTLP and Prometheus

Fri, 18 Sep 2026 12:07:36 +0000

Many applications export their metrics directly to Prometheus. If you’re unfamiliar with Prometheus, in a nutshell it’s a time-series database for storing metrics, like counters and histograms. Applications that store their metrics in Prometheus typically use a popular Prometheus client as part of the integration.

Now that OpenTelemetry is a graduated CNCF project, many companies are now increasingly looking to move to OpenTelemetry to add more signals beyond metrics to their observability architecture. Logs and traces are popular additions for getting further insight into how applications behave. Profiles are also starting to become a popular fourth telemetry signal for even deeper understanding.

Kubernetes attributes processor reaches v1.0.0 milestone

Wed, 16 Sep 2026 04:59:27 +0000

The Kubernetes attributes processor, which enriches your telemetry with Kubernetes metadata, has officially moved to v1.0.0! You can try it out on your custom distro, and it is also available as part of the latest opentelemetry-collector-contrib and opentelemetry-collector-k8s distro releases.

Being v1.0.0 means the component is now verified to fulfill the ‘stable’ stability criteria including requirements around testing, benchmarking, documentation and telemetry stability. It also ensures you can redistribute it as a Go library or as part of your binaries without API breakage.

Help us stabilize environment variable context propagation

Fri, 11 Sep 2026 11:01:22 +0000

A trace does not always cross a network boundary. A workflow runner starts a shell, the shell launches a build tool, and the build tool starts test processes. Batch and data-processing systems create similar chains of child processes. Without a shared way to pass trace information across these boundaries, spans from each process can end up in separate traces.

If context propagation is new to you, it is the mechanism that carries information from one service or process to the next. For tracing, this includes the trace and span identifiers that let new spans join the same trace. It can also carry baggage: application-defined key-value pairs that are passed to downstream work.

OpenTelemetry Go Logs API and SDK reach release candidate status

Mon, 31 Aug 2026 15:40:58 +0000

OpenTelemetry Go v1.47.0-rc.1 is here. This release promotes the Logs API and SDK to release candidate (RC), the final stage before we provide stable v1 compatibility guarantees. We believe the design is ready, and now we need the community to test it in real applications and integrations before those guarantees take effect.

What is included in the release candidate?

The RC covers these two modules:

go.opentelemetry.io/otel/log
go.opentelemetry.io/otel/sdk/log

These modules move from v0.22.0, with beta stability, to v1.47.0-rc.1. The version aligns them with the other stable OpenTelemetry Go modules, which share a coordinated version number. The log exporters and logtest modules remain experimental and are not covered by this RC’s stability scope.

What can you do with OpenTelemetry entity events?

Fri, 14 Aug 2026 07:10:08 +0000

Metrics, logs, and traces tell you how your systems behave. They are much quieter about what actually exists: which hosts, interfaces, switches, services, and volumes are out there right now, and, crucially, how that picture changed over the last hour, day, or quarter. That living inventory has stayed a blind spot in the open observability stack.

OpenTelemetry’s entity events, coming out of the Entities SIG and described in the Entity Data Model, are the piece that starts to close it. Entity events are a stream. The interesting question is “what do I do once they arrive?” This post walks through one answer, using an open source consumer as a worked example.

Metric cardinality limits in OpenTelemetry: a practical guide

Thu, 06 Aug 2026 00:43:47 -0700

OpenTelemetry metrics are designed to be safe to use in production. One part of that safety is the cardinality limit in the metrics SDK. The limit protects your process from unbounded memory growth when a metric receives too many unique attribute combinations.

That protection is useful, but it has a consequence many users do not expect: when a metric stream overflows, the total value remains correct, while queries that filter or group by attributes can undercount. This can affect dashboards, service-level objectives (SLOs), and alerts that looked correct before overflow started.

We broke the OTel demo

Tue, 28 Jul 2026 12:15:19 +0200

If you’ve been running the Demo for some time, you may have seen a couple of structural changes lately, and you may even have gotten mad about things not working as expected. We feel your pain and we totally understand it. Unfortunately there was no better way to change things without breaking the existing flow.

Some of what you knew is gone. New services were added. Attribute names have changed. If you had dashboards with custom metrics, everything is broken now.