New OpenTelemetry Kotlin SDK
The OpenTelemetry project now has an official Kotlin SDK under active development, donated by Embrace. This might seem redundant given that Kotlin runs on the JVM and OpenTelemetry already has a mature Java SDK, but the reality is more nuanced and worth understanding if you're operating Kotlin services or planning to adopt Kotlin Multiplatform.
The Java SDK works fine for traditional Kotlin JVM applications. You can instrument your Spring Boot or Ktor services today using the existing Java agent or SDK without significant friction. The problem emerges with Kotlin Multiplatform, which lets you write Kotlin code that compiles to multiple targets: JVM bytecode, native binaries, JavaScript, and WebAssembly. This is increasingly common for organizations building Android apps that share business logic with backend services or web frontends.
When you're running the same Kotlin code on Android, in a browser via Kotlin/JS, and on a server via JVM, the Java SDK becomes a non-starter for the non-JVM targets. You can't use Java libraries in Kotlin/Native or Kotlin/JS. This creates an observability gap where your shared business logic might be instrumented on the server but goes dark on mobile or in the browser, or requires maintaining separate instrumentation implementations per platform.
The new Kotlin SDK addresses this by providing a common API surface that works across all KMP targets. Under the hood, it delegates to platform-specific implementations: the Java SDK on JVM, native implementations for iOS and Android, and JavaScript-based exporters for browser environments. This means you can instrument your shared Kotlin code once and get telemetry from all platforms where it runs.
From an operational standpoint, this matters most if you're already using KMP or considering it. The value proposition is consistency in your instrumentation approach and the ability to trace requests that span multiple platforms. Imagine a mobile app making an API call where both the client-side business logic and server-side handler are written in shared Kotlin code. With platform-specific instrumentation, correlating these requires careful context propagation and compatible trace ID formats. With a unified SDK, you get this for free.
The SDK is still in active development, which means production adoption should wait. The project is explicitly looking for contributors and early adopters willing to provide feedback. If you're running Kotlin services exclusively on the JVM, there's no compelling reason to switch from the Java SDK right now. The Java agent's auto-instrumentation capabilities and maturity still make it the better choice for traditional server deployments.
Where this becomes interesting is for teams already committed to KMP who need observability across their entire stack. The alternative today is either accepting blind spots in your non-JVM environments or maintaining separate instrumentation code for each platform, neither of which scales well. The Kotlin SDK offers a third path, though you'll be an early adopter dealing with incomplete features and potential API changes.
If you're evaluating KMP for sharing code between mobile and backend, factor in that observability tooling is catching up but not yet mature. For pure JVM Kotlin shops, stick with what works.