You may know I'm a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language. master class for the YOW! conference In this post, I want to compare the different zero-code OpenTelemetry approaches on the JVM, covering the most widespread: Spring Boot with Micrometer Tracing
Spring Boot with the OpenTelemetry Agent
OpenTelemetry Spring Boot Starter
Quarkus
Quarkus with the OpenTelemetry Agent Spring Boot with Micrometer Tracing Spring Boot with the OpenTelemetry Agent OpenTelemetry Spring Boot Starter Quarkus Quarkus with the OpenTelemetry Agent Commonalities I keep the architecture pretty simple: I'm using Reactive data access on both the remote service and the database to spice up things a bit, more specifically, Kotlin coroutines. Here's the general structure: val products = coroutineScope {
    val ping = async {
        // Call the ping service
    }
    val products = async {
        // Query the database
    }
    println("Received ping response: ${ping.await()}")
    products.await()
} val products = coroutineScope {
    val ping = async {
        // Call the ping service
    }
    val products = async {
        // Query the database
    }
    println("Received ping response: ${ping.await()}")
    products.await()
} Here are the features for each stack: Quarkus

Spring Boot



Web

Mutiny

WebFlux



HTTP client

REST client

WebClient



Database access pattern

Record

Repository



Database access

Hibernate Reactive with Panache

R2DBC Quarkus

Spring Boot



Web

Mutiny

WebFlux



HTTP client

REST client

WebClient



Database access pattern

Record

Repository



Database access

Hibernate Reactive with Panache

R2DBC Quarkus

Spring Boot Quarkus Quarkus Spring Boot Spring Boot Web

Mutiny

WebFlux Web Web Mutiny Mutiny WebFlux WebFlux HTTP client

REST client

WebClient HTTP client HTTP client REST client REST client WebClient WebClient WebClient Database access pattern

Record

Repository Database access pattern Database access pattern Record Record Repository Repository Database access

Hibernate Reactive with Panache

R2DBC Database access Database access Hibernate Reactive with Panache Hibernate Reactive with Panache R2DBC R2DBC Running the OpenTelemetry Agent The OpenTelemetry Java Agent is the first approach I used regarding OpenTelemetry. The only necessary configuration is to set the agent when running the JVM: java -javaagent:opentelemetry-javaagent.jar -jar otel-boot-agent.jar java -javaagent:opentelemetry-javaagent.jar -jar otel-boot-agent.jar The agent supports lots of frameworks and libraries, including Spring Boot, Quarkus, Ktor, Spark, and many others. When the application flow finds a supported framework/library, it logs a span. lots of frameworks and libraries The Agent upholds the standard OpenTelemetry environment variables. services:
  otel-boot-agent:
    build: otel-boot-agent
    environment:
      OTEL_SERVICE_NAME: OTEL Boot Agent                             #1
      OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4318                #2
      OTEL_METRICS_EXPORTER: none                                    #3
      OTEL_LOGS_EXPORTER: none                                       #3 services:
  otel-boot-agent:
    build: otel-boot-agent
    environment:
      OTEL_SERVICE_NAME: OTEL Boot Agent                             #1
      OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4318                #2
      OTEL_METRICS_EXPORTER: none                                    #3
      OTEL_LOGS_EXPORTER: none                                       #3 OpenTelemetry service name
OpenTelemetry endpoint; Spring Boot uses HTTP
Neither metrics nor logs OpenTelemetry service name OpenTelemetry endpoint; Spring Boot uses HTTP Neither metrics nor logs Here's the Jaeger trace when calling the endpoint on the Spring Boot application: And here's the one on Quarkus: Spring Boot features an additional span that displays the repository call. There's no such thing available on Quarkus, as I'm using the Record pattern to access the data. The Agent outputs the SQL query in both frameworks, i.e., SELECT product.* FROM product. The Java Agent works out-of-the-box. i.e. SELECT product.* FROM product The Java Agent works out-of-the-box Micrometer Tracing on Spring Boot Spring Boot provides dedicated OpenTelemetry support via Micrometer Tracing. Micrometer Tracing Micrometer Tracing provides a simple facade for the most popular tracer libraries, letting you instrument your JVM-based application code without vendor lock-in. It is designed to add little to no overhead to your tracing collection activity while maximizing the portability of your tracing effort. Micrometer Tracing provides a simple facade for the most popular tracer libraries, letting you instrument your JVM-based application code without vendor lock-in. It is designed to add little to no overhead to your tracing collection activity while maximizing the portability of your tracing effort. Besides the Micrometer Tracing dependency itself, you need additional ones: The Spring Boot Actuator
A bridge–OpenTelemetry
An exporter–OpenTelemetry as well The Spring Boot Actuator A bridge–OpenTelemetry An exporter–OpenTelemetry as well Configuration doesn't follow the OpenTelemetry standard: services:
  otel-boot-micrometer:
    environment:
      SPRING_APPLICATION_NAME: OTEL Micrometer                       #1-2
      MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #1-3 services:
  otel-boot-micrometer:
    environment:
      SPRING_APPLICATION_NAME: OTEL Micrometer                       #1-2
      MANAGEMENT_OTLP_TRACING_ENDPOINT: http://jaeger:4318/v1/traces #1-3 Different values from the OpenTelemetry specification
The Spring application name serves as the OpenTelemetry service name
Full path to the API endpoint Different values from the OpenTelemetry specification The Spring application name serves as the OpenTelemetry service name Full path to the API endpoint The above setup doesn't register the database call. To fix it, we need an additional dependency: R2DBC Proxy. R2DBC Proxy The new trace contains the database span: You might notice another issue: calls to the service and the database are sequential, where they should be parallel. It stems from Spring Boot not handling context propagation properly to the coroutine scope. It's an underlying work from the Spring team. Subscribe to the GitHub issue if you're interested. GitHub issue OpenTelemetry Spring Boot Starter The OpenTelemetry project provides a Spring Boot starter. You need only a single dependency, and like other starters, Spring Boot magic takes care of configuration: Spring Boot starter <dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency> <dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency> The result is very similar to the previous one, including the not-parallel-but-serial issue. Quarkus We saw the results of using the OpenTelemetry Agent in the first section. It's quite straightforward to use OpenTelemetry without the Agent; you need a single dependency: <dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-opentelemetry</artifactId>
</dependency> <dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-opentelemetry</artifactId>
</dependency> Quarkus prefixes regular OpenTelemetry environment variable names with QUARKUS_: QUARKUS_ services:
  otel-quarkus:
    environment:
      QUARKUS_OTEL_SERVICE_NAME: OTEL Quarkus                        #1
      QUARKUS_OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: http://jaeger:4317 #2 services:
  otel-quarkus:
    environment:
      QUARKUS_OTEL_SERVICE_NAME: OTEL Quarkus                        #1
      QUARKUS_OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: http://jaeger:4317 #2 OpenTelemetry service name
OpenTelemetry endpoint; Quarkus uses gRPC OpenTelemetry service name OpenTelemetry endpoint; Quarkus uses gRPC Results are as expected: Discussion OpenTelemetry approaches vary widely in both configuration and results. Unless you're prevented from using Java agents for technical or organizational reasons, I recommend using the OpenTelemetry Agent first. It handles everything you can throw at it out of the box, including the most common libraries. Barring that, you need deep knowledge of the stack you're using, lest results don't represent what happens in reality. The complete source code for this post can be found on GitHub. GitHub To go further: To go further: OpenTelemetry Java Agent
Kotlin Coroutines and OpenTelemetry tracing
Add support for Micrometer context propagation in Kotlin coroutines OpenTelemetry Java Agent OpenTelemetry Java Agent Kotlin Coroutines and OpenTelemetry tracing Kotlin Coroutines and OpenTelemetry tracing Add support for Micrometer context propagation in Kotlin coroutines Add support for Micrometer context propagation in Kotlin coroutines Originally published at A Java Geek on August 3rd, 2025 Originally published at A Java Geek on August 3rd, 2025 A Java Geek

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

What to Know About OpenTelemetry Configuration Gotchas

Understanding Git Push and Rebase Defaults: A Hands-On Guide

Read all my posts!

A Guide to OpenTelemetry Tracing for the JVM

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

First Steps With Kotlin Coroutines

Learning the Fundamentals of Coroutines: Part 1

Mastering Unity's Coroutines

GlobalScope in Kotlin Coroutines: Is It Really Worth the Risk?

OpenTelemetry: Unraveling @WithSpan in Kotlin Coroutines and the JVM

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

First Steps With Kotlin Coroutines

Learning the Fundamentals of Coroutines: Part 1

Mastering Unity's Coroutines

GlobalScope in Kotlin Coroutines: Is It Really Worth the Risk?

OpenTelemetry: Unraveling @WithSpan in Kotlin Coroutines and the JVM

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps