# Blog on OpenTelemetry Recent content in Blog on OpenTelemetry This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Kubernetes attributes processor reaches v1.0.0 milestone DevFeed: [Kubernetes attributes processor reaches v1.0.0 milestone]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-16T04:59:27Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [releases](), [Kubernetes](), [Go Language]() Tags: [api](), [go](), [kubernetes](), [opentelemetry](), [releases](), [stable](), [telemetry]() ### AI overview The Kubernetes attributes processor has reached version 1.0.0 and fulfills OpenTelemetry's stability criteria for testing, benchmarking, documentation, and telemetry. The release also supports redistribution as a Go library or in binaries without API breakage. ### Source excerpt 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. ## Inside the LLM Call: GenAI Observability with OpenTelemetry DevFeed: [Inside the LLM Call: GenAI Observability with OpenTelemetry]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-14T16:56:42Z Content type: tutorial Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [agent observability](), [telemetry](), [AI Agent](), [Large Language Model]() Tags: [agent](), [ai-agent](), [claude-code](), [codex](), [observability](), [opentelemetry](), [token](), [tool](), [visibility]() ### AI overview This tutorial explains how OpenTelemetry Semantic Conventions for Generative AI record LLM calls, tool invocations, token counts, and related events. It demonstrates exporting telemetry from an LLM-powered application, viewing it with Aspire Dashboard, and considering sensitive-data implications of optional content capture. ### Source excerpt 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. ## OpenTelemetry proposes environment variables for context propagation across processes DevFeed: [OpenTelemetry proposes environment variables for context propagation across processes]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-11T11:01:22Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [context](), [tracing](), [OpenTelemetry](), [Processes](), [CI/CD](), [data-processing]() Tags: [ci-cd](), [data-processing](), [environment-variables](), [opentelemetry](), [processes](), [spans](), [tracing](), [w3c]() ### AI overview The OpenTelemetry Specification has a release candidate for using environment variables to carry trace context and baggage between processes. The article explains how this can connect spans across workflow runners, shells, build tools, test processes, and similar workloads when protocol headers or message metadata are unavailable, and requests feedback before the specification becomes Stable. ### Source excerpt 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 DevFeed: [OpenTelemetry Go Logs API and SDK reach release candidate status]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-31T15:40:58Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Go Language](), [releases](), [SDKs](), [Logging]() Tags: [api](), [beta](), [experimental](), [go](), [opentelemetry](), [release](), [sdk](), [version]() ### AI overview OpenTelemetry Go v1.47.0-rc.1 promotes the Logs API and SDK to release candidate status. The release moves these modules from beta stability toward stable v1 compatibility guarantees, while log exporters and logtest remain experimental and outside the RC scope. ### Source excerpt 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. ## Consuming OpenTelemetry Entity Events with an Event-Sourced Consumer DevFeed: [Consuming OpenTelemetry Entity Events with an Event-Sourced Consumer]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-14T07:10:08Z Content type: tutorial Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [observability](), [telemetry](), [systems]() Tags: [logs](), [metrics](), [observability](), [open-source](), [opentelemetry](), [services](), [systems](), [traces](), [volumes]() ### AI overview This post explains how to consume OpenTelemetry entity events, which represent the inventory and lifecycle changes of hosts, interfaces, switches, services, and volumes. It presents an open source consumer as a worked example and recommends an event-sourced pipeline that preserves both current state and history. ### Source excerpt 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 DevFeed: [Metric cardinality limits in OpenTelemetry: a practical guide]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-06T07:43:47Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [SDK](), [telemetry](), [dashboards]() Tags: [cardinality](), [dashboards](), [filter](), [guide](), [memory](), [metric](), [metrics](), [opentelemetry](), [practical](), [production]() ### AI overview This practical guide explains how OpenTelemetry metric cardinality limits protect process memory from unbounded growth. When a metric stream overflows, total values remain correct, but attribute-based filtering and grouping can undercount, affecting dashboards, SLOs, and alerts. ### Source excerpt 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. ## OpenTelemetry Demo 3.0 introduces breaking changes to attributes, dashboards, and local deployment DevFeed: [OpenTelemetry Demo 3.0 introduces breaking changes to attributes, dashboards, and local deployment]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-28T10:15:19Z Content type: opinion Language: en Sources: [Blog on OpenTelemetry]() Topics: [Demo](), [OpenTelemetry](), [Maintainability](), [dashboards](), [Kafka]() Tags: [changes](), [dashboards](), [demo](), [maintainability](), [opentelemetry](), [services]() ### AI overview This article explains intentional breaking changes in OpenTelemetry Demo 3.0, including renamed custom telemetry attributes, broken dashboards and queries, and a revised local-run configuration split across multiple files. The changes aim to improve maintainability and make forks easier to manage. ### Source excerpt 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. ## OpenTelemetry @ KubeCon + CloudNativeCon Japan 2026 DevFeed: [OpenTelemetry @ KubeCon + CloudNativeCon Japan 2026]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-23T17:40:46Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [agent observability]() Tags: [2026](), [conference](), [japan](), [kubecon](), [opentelemetry]() ### AI overview A guide to OpenTelemetry-related sessions at KubeCon + CloudNativeCon Japan 2026, including Japan Community Day and the main conference program in Yokohama. The schedule includes sessions on agent observability, industrial IoT, metrics migration, traces as test data, trust, Wasm, and Prometheus exporters. ### Source excerpt KubeCon + CloudNativeCon Japan takes place July 28-30, 2026, in Yokohama, Japan. Register today to join us! Here are all the OpenTelemetry-related sessions, up to date at the time of writing. Session details can change, so confirm dates and times in the official schedule. Community Day Japan Community Day is on Tuesday, July 28, ahead of the main conference. It's a great way to engage with fellow attendees and with members of local meetup communities, special interest groups, and subgroups within Cloud Native Community Japan. ## One-command OpenTelemetry setup on Linux hosts DevFeed: [One-command OpenTelemetry setup on Linux hosts]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-23T16:51:56Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Linux](), [Automation](), [systems]() Tags: [automation](), [aws-lambda](), [environment-variables](), [installation](), [java](), [linux](), [monitoring](), [net](), [node-js](), [opentelemetry](), [packaging](), [processes](), [python](), [setup]() ### AI overview OpenTelemetry introduces a package-based setup for instrumenting Java, .NET, Node.js, and Python applications running directly on Linux hosts. The package installs the OpenTelemetry Injector, SDKs, and auto-instrumentation packages, which activate instrumentation at process startup without application code or deployment-script changes. ### Source excerpt OpenTelemetry as system dependency Setting up OpenTelemetry for your applications and systems depends on where those apps and systems run. Some are very automated, especially Kubernetes, thanks to the OpenTelemetry Operator, or AWS Lambda, with the OpenTelemetry Lambda layers. But the countless Java, .NET, Node.js, and Python apps running directly on Linux hosts have had no such automation. Instrumenting those has meant downloading agents by hand and wiring up environment variables yourself. At OTel Unplugged EU in Brussels this February, one ask kept coming up: clear packaging, installation, and usage paths. You asked for: ## Announcing v1 of OpenTelemetry Go Compile-Time Instrumentation DevFeed: [Announcing v1 of OpenTelemetry Go Compile-Time Instrumentation]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-23T06:20:13Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [Go Language](), [OpenTelemetry](), [Instrumentation](), [telemetry]() Tags: [go](), [instrumentation](), [opentelemetry](), [release](), [telemetry](), [zero-code]() ### AI overview OpenTelemetry announces the first stable release of Go Compile-Time Instrumentation. The project injects OpenTelemetry instrumentation during the Go build process, allowing traces and metrics for applications, dependencies, and supported standard-library packages without source-code changes or a separate runtime agent. ### Source excerpt 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. ## Lambda-powered functions land in OTTL DevFeed: [Lambda-powered functions land in OTTL]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-22T20:04:49Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [sensitive data](), [data]() Tags: [collection-operations](), [experimental](), [functions](), [lambda](), [opentelemetry](), [pipelines](), [release](), [sensitive-data](), [telemetry](), [transformation]() ### AI overview OpenTelemetry Collector Contrib v0.157.0 introduces lambda expressions to OTTL, enabling reusable inline logic in generic higher-order functions. The release adds eight experimental functions for collection transformations, including filtering, mapping, finding, reducing, and conditional operations. ### Source excerpt 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 DevFeed: [CocoaPods Deprecation Notice for OpenTelemetry Swift]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-20T14:05:37Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [cocoapods](), [Swift](), [swift-package-manager](), [migration](), [Package manager](), [maintenance](), [Maintainers]() Tags: [cocoapods](), [maintenance](), [migration](), [opentelemetry](), [release](), [releases](), [swift](), [swift-package-manager]() ### AI overview OpenTelemetry Swift maintainers plan to deprecate CocoaPods support for the opentelemetry-swift and opentelemetry-swift-core pods as CocoaPods moves into maintenance mode. Swift Package Manager is the recommended installation method, and existing CocoaPods users are encouraged to plan migration. ### Source excerpt 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. ## OpenTelemetry Has Graduated... Now what? DevFeed: [OpenTelemetry Has Graduated... Now what?]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-15T18:59:02Z Content type: opinion Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [Open Source](), [vendor lock-in](), [Instrumentation](), [Traces]() Tags: [cncf](), [instrumentation](), [open-source](), [opentelemetry](), [telemetry](), [traces](), [tracing](), [vendor-lock-in]() ### AI overview This article discusses OpenTelemetry's CNCF graduated status, its history as a unified standard for traces, logs, and metrics, and the role of standardized APIs, language implementations, and the Collector in reducing vendor lock-in. ### Source excerpt 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. ## OpenTelemetry Spring Boot Starter Adds Declarative YAML Configuration in Version 2.26.0 DevFeed: [OpenTelemetry Spring Boot Starter Adds Declarative YAML Configuration in Version 2.26.0]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-14T07:47:36Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Spring Boot](), [YAML](), [configuration](), [Environment Variables](), [telemetry](), [tracing]() Tags: [configuration](), [environment](), [java](), [opentelemetry](), [schema](), [setup](), [spring-boot](), [telemetry](), [traces](), [yaml]() ### AI overview The article explains how declarative configuration in the OpenTelemetry Spring Boot starter, available from version 2.26.0, embeds the SDK's YAML schema in application.yaml. It contrasts this approach with environment-variable configuration and describes how the YAML schema can represent telemetry pipelines and options beyond the fixed environment-variable catalog. ### Source excerpt 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 DevFeed: [Call for Contributors: OpenTelemetry for Dart and Flutter]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-07-13T08:20:00Z Content type: opinion Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Dart](), [Flutter](), [telemetry](), [SDKs](), [cross-platform]() Tags: [contributors](), [cross-platform](), [dart](), [flutter](), [opentelemetry](), [sdk](), [telemetry]() ### AI overview OpenTelemetry is seeking contributors to establish an official Dart and Flutter SIG and develop a maintained OpenTelemetry SDK. An existing implementation, dartastic_opentelemetry and its API package, is being considered for donation and supports traces, metrics, and logs across multiple targets. ### Source excerpt 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 DevFeed: [Don't Wrap OpenTelemetry -- You're Probably Hurting More Than Helping]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-06-24T08:42:08Z Content type: opinion Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Instrumentation](), [telemetry](), [SDKs]() Tags: [api](), [cache](), [concurrency](), [instrumentation](), [opentelemetry](), [traces]() ### AI overview This opinion article argues that thin abstractions wrapping the OpenTelemetry API can harm application instrumentation by hiding allocation-free SDK designs and adding repeated lookup, hashing, comparison, or locking costs. It distinguishes API wrappers from shared helpers for SDK configuration. ### Source excerpt 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 DevFeed: [Deprecating OpenCensus compatibility requirements]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-06-19T22:53:47Z Content type: news Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [deprecated](), [migration](), [SDKs]() Tags: [deprecated](), [java](), [javascript](), [migrate](), [migration](), [opentelemetry](), [python](), [sdks]() ### AI overview The OpenTelemetry Specification project deprecated OpenCensus compatibility requirements on June 12, 2026. New SDKs and implementations no longer need to add OpenCensus compatibility, while existing shims may continue receiving maintenance during the deprecation period. New work should use native OpenTelemetry APIs, SDKs, and OTLP-based workflows. ### Source excerpt 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 DevFeed: [OTel-Arrow Phase 2: From Efficient Transport to Efficient Telemetry Pipelines]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-06-13T00:47:46Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [Structured-data](), [systems](), [Rust](), [Instrumentation]() Tags: [apache-arrow](), [memory](), [opentelemetry](), [overhead](), [pipelines](), [processors](), [rust](), [telemetry]() ### AI overview This article presents Phase 2 of OTel-Arrow, which uses Apache Arrow not only for transport through OTAP but also as the internal representation of telemetry pipelines. It describes the Rust-based OTel-Arrow Dataflow Engine and reports substantially lower transport and processing costs when telemetry remains on the OTAP path end to end. ### Source excerpt 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 DevFeed: [OpenTelemetry is a CNCF Graduated Project]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-05-21T14:27:48Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [observability](), [Cloud Native Ecosystem](), [Maintainers](), [SDKs]() Tags: [cloud-native](), [cncf](), [community](), [contributors](), [observability](), [opentelemetry](), [sdks](), [specifications]() ### AI overview The Cloud Native Computing Foundation announced that OpenTelemetry has graduated. The article presents the graduation as a milestone reflecting the strength of the project's community and ecosystem, and describes its continued commitment to interoperable observability standards and tooling for cloud native software. ### Source excerpt 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 DevFeed: [Applying OpenTelemetry Security Practices in Legacy Environments]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-05-19T13:38:41Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Security](), [observability](), [telemetry](), [systems](), [Architecture & Design](), [Networks](), [Instrumentation]() Tags: [architectures](), [legacy](), [observability](), [opentelemetry](), [security](), [systems](), [telemetry]() ### AI overview This article explains how securing OpenTelemetry in legacy and industrial environments differs from securing cloud-native systems. It focuses on applying controls at appropriate points in the telemetry pipeline when source systems cannot be modified, instrumented, patched regularly, or protected with modern authentication and TLS. ### Source excerpt 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.