Tag: Tracing API

OpenTelemetry is a Cloud Native Computing Foundation (CNCF) framework that is used to provide standardized APIs and SDKs to collect, process and export telemetry data across cloud-native systems.

As we know, Telemetry data is critical for monitoring performance, troubleshooting errors and optimizing software systems and OpenTelemetry has become something of a de facto standard in this space. 

Basking in the warmth of strong community collaboration, clear specifications and a growing ecosystem of language-specific SDKs and platform integrations, OpenTelemetry now turns its observability prowess towards Kotlin.

Popular throughout the cloud-native computing community since being created by JetBrains back in 2011 (although not in stable release until 2016), Kotlin is a cross-platform language designed for full Java interoperability, safety and concise syntax for Android and server-side deployments.

Kotlin Multiplatform

In recent years, client-side and mobile observability has become an area of increasing focus within the OpenTelemetry community, particularly for teams building applications in Kotlin and Kotlin Multiplatform (KMP), the latter being used by developers to share business logic across iOS, Android and web, all while keeping user interfaces native.

According to Jamie Lynch, senior software engineer at user-focused observability platform company Embrace (CNCF member company), in 2025, his firm opened a proposal to contribute a Kotlin implementation of the OpenTelemetry specification to the community.

“We’re now pleased to announce that the contribution of Embrace’s Kotlin API and SDK to OpenTelemetry has been accepted. The project expands vendor-neutral observability support across client- and server-side applications written in Kotlin. It establishes a foundation for a community-owned Kotlin SDK and allows KMP and Kotlin projects to capture telemetry using one API for many different platforms,” wrote Lynch, in a CNCF blog during KubeCon + CloudNativeCon Europe 2026 in Amsterdam.

Kotlin SDK will now fit into the OpenTelemetry ecosystem. Lynch and team say that Kotlin has become the default language for modern Android development and is increasingly used across backend, desktop, and web environments. With the growth of KMP, teams can now share significant portions of application logic across Android, iOS, and other targets using a single codebase.

In terms of where observability looks to next, this shift creates both an opportunity and a challenge, i.e., historically, most Kotlin applications have relied on the OpenTelemetry Java SDK through language interoperability. 

While this approach works well for JVM-based services, Lynch details several limitations:

• It does not support non-JVM targets used in KMP
• The API reflects Java design patterns rather than Kotlin idioms
• It makes backend-oriented assumptions about execution models and lifecycle

“As Kotlin adoption continues to expand beyond the JVM, these limitations become more significant. A native Kotlin implementation allows OpenTelemetry to support this ecosystem directly, rather than indirectly through Java,” he said. “Mobile and client-side observability have different constraints than backend systems. Client and mobile runtimes operate under very different performance, lifecycle and reliability constraints than traditional server environments.”

Fellow Embrace employee and Hanson Ho explained this technology development at the CNCF’s first Open Observability Summit, where he presented the talk, “Beyond Good Enough: Why We Want a Kotlin API and SDK.” The session addressed the constraints of mobile environments, such as battery power, network and storage. He then looked at how OpenTelemetry can be adapted accordingly.

Observability = Workflows + Context + Outcomes 

An Android architect at Embrace, Ho has said that observability “isn’t just about collecting more data” these days, i.e., it’s about understanding user workflows, context and outcomes in environments where performance, connectivity and lifecycle constraints are fundamentally different.

Applications in these environments must account for intermittent connectivity, frequent process termination by the operating system, limited CPU and memory budgets, highly asynchronous execution models, and user-driven workflows that may span multiple sessions.

“These realities affect how telemetry is generated, buffered, correlated, and exported. Backend-focused SDKs are not always optimized for these conditions,” advised Lynch. “A Kotlin implementation provides an opportunity to design APIs and runtime behavior that better match these environments while still conforming to the OpenTelemetry specification. This becomes increasingly important as organizations adopt OpenTelemetry for end-to-end observability across frontend, mobile, and backend systems.”

The Kotlin SDK Contribution

The contributed project is a KMP implementation of the OpenTelemetry specification, designed to support both JVM and non-JVM environments. The project participates in OpenTelemetry’s compliance review process, and it currently supports two primary modes of operation.

• Compatibility Mode: In this mode, the Kotlin API interoperates with the OpenTelemetry Java SDK. This allows Android and JVM users to adopt an idiomatic Kotlin interface while continuing to rely on the mature opentelemetry-java SDK. It provides a low-friction migration path for teams with existing OpenTelemetry instrumentation.
• Regular Mode: In this mode, the SDK runs on a Kotlin-native implementation of the specification. This enables support for non-JVM targets such as iOS and JavaScript and provides greater flexibility for client-focused optimizations.

Lynch notes that both modes are designed to follow the OpenTelemetry specification closely and remain interoperable with the broader ecosystem. At present, the project includes implementations of the Tracing and Logging APIs, which are being refined based on community feedback.

The Road Ahead

A Kotlin SDK expands OpenTelemetry’s coverage into modern client and multiplatform runtimes; the Embrace team sees it strengthening its role as a unified observability standard across the cloud-native stack. They say that OpenTelemetry’s growth has been driven by a commitment to interoperability, openness and practical engineering needs. Community feedback and real-world usage will remain central to shaping these efforts.

The team at Embrace is honored that the contribution of the Kotlin SDK has been accepted and remains committed to its long-term development within the OpenTelemetry community.