Pain points. Slow requests. Failing calls that vanish into thin air. You might know this feeling — an error pops up in your Spring Boot application, and you have no clue where, when, or even why it happened. In medium to large systems, what seems like a tiny visibility problem blooms into chaos.

That’s how teams end up chasing symptoms instead of finding causes. Years ago, I lost a weekend debugging a cascade of errors stitched together by HTTP calls, struggling to see the full picture. If only I had a clear trace from end to end. Today, we don’t have to fly blind.

Enter OpenTelemetry. It promises an open, standardized approach to visibility across cloud-native systems — especially for frameworks like Spring Boot. Since the stable release of the OpenTelemetry Spring Boot starter in 2024 (see the announcement), adding rich traces, metrics, and logs is more accessible than ever.

Why OpenTelemetry matters for Spring Boot

Spring Boot quietly powers large slices of the modern web. Its magic is productivity and rapid start. But this ease can lull us into neglecting monitoring until — one day — a critical bug slips into production. As systems scale, distributed tracing becomes… well, necessary.

OpenTelemetry offers several key things for Spring Boot apps:

  • Standardized tracing, metrics, and logs across languages or frameworks.
  • Vendor-agnostic support (think Jaeger, Zipkin, Prometheus, and more).
  • A clearer view from the user’s browser down to your database call.

Don’t let silent errors win.

That’s why forward-thinking communities, like Arthur Raposo, integrate observability into every step — not as an afterthought.

OpenTelemetry trace visualized across Spring Boot microservices Getting started: the integration paths

There isn’t a single magic method to wire up OpenTelemetry with Spring Boot. You have a choice, and it does depend on your needs. Broadly, as the official OpenTelemetry docs highlight, you can pick:

  1. Zero-code instrumentation (Java agent): Attach a Java agent at runtime (no code changes required).
  2. Spring Boot starter: Add dependencies directly in your app, suited for when you want “native image” support or finer control.
  3. Manual instrumentation: Write traces, spans, and logs in your business code for extra detail.

Which should you choose? If you want tracing everywhere and don’t want to spend much time, Java agent is easy and fast. But for more control (and future-proofing against changes like moving to GraalVM native images), go with the Spring Boot starter.

Setting up the OpenTelemetry Java agent

If you prefer adding no dependencies to your codebase at first, you can use the Java agent approach. The community has widely used this with good results.

  1. Download the latest Java agent JAR from the OpenTelemetry GitHub releases.
  2. Start your Spring Boot app with an extra argument:

Java -javaagent:path/to/opentelemetry-javaagent.jar -jar your-app.jar

  1. Configure environment variables, such as OTEL_EXPORTER_OTLP_ENDPOINT, to point to your telemetry backend (Jaeger, Zipkin, etc.).

No code changes. Immediate traces.

Sometimes, though, you need more than the basics. Auto-instrumentation can’t always see inside custom business logic or edge scenarios.

Using the OpenTelemetry Spring Boot starter

In 2024, the OpenTelemetry Spring Boot starter hit a promising milestone by offering better support, performance, and auto-configuration (learn more here).

  1. Add dependencies to your pom.xml:
  • Io.opentelemetry:opentelemetry-exporter-otlp
  • Io.opentelemetry:opentelemetry-sdk-extension-autoconfigure
  • Io.opentelemetry.instrumentation:opentelemetry-spring-boot-autoconfigure-starter
  1. Configure exporter settings in application.properties:

Otel.exporter.otlp.endpoint=http://localhost:4317

  1. (Optional) Add spring-boot-starter-actuator and micrometer-tracing-bridge-otel for enhanced tracing, as described in the Spring Boot reference.

The starter supports automatic context propagation, meaning every HTTP call and database query is tracked across services. This creates connected traces, invaluable for debugging microservices.

Telemetry dashboard showing traces, metrics, and logs Customizing and manual spans

Sometimes, you want to follow business logic: what happens in a specific method, or between two external service calls. That’s where manual instrumentation comes in.

You can annotate methods with @WithSpan for automatic span creation. Or, for total control, use the OpenTelemetry API to start and end spans wherever you need.

    @WithSpan  public void processOrder(Order order) {      // Your business logic  }

This creates a custom trace segment, with full visibility in your backend viewer (Jaeger, Zipkin, Tempo, etc.). You can also attach custom tags or error signals.

Balancing trace data and performance

There’s a tradeoff. More traces means more storage and, sometimes, a touch more latency. For teams using Arthur Raposo or any robust production guide, tuning collection rates becomes a habit.

  • Adjust management.tracing.sampling.probability to only trace a fraction of requests.
  • Prune noisy or redundant spans.
  • Routinely review span sizes and retention periods.

Thoughtful configuration avoids the telemetry trap: “Too much signal, not enough insight.” There’s some beauty in hand-curated signals over mountains of logs.

Visualizing and using your data

With traces, metrics, and logs flowing, the real value kicks in via visual tools. The backend doesn’t matter as much — whether it’s Grafana Tempo, Jaeger, or Zipkin — but the insight does.

See a trace from front-end to database. Follow a failing request through HTTP hops and microservice calls. Combine logs, spans, and metrics on one screen and feel like you understand why something broke — not just that it did.

Observability isn’t luxury. It’s sanity.

The difference, for me, is sleeping through the night when the pager stays silent.

What you learned (and what’s next)

Building observable Spring Boot apps is suddenly… attainable. With OpenTelemetry now stable and standard, early-morning fire drills become rare. Teams like ours, at Arthur Raposo, are seeing stronger architectures, faster recovery, and — honestly — more confident developers.

If your current tracing is “just logs,” pick a path: Java agent for speed, Spring Boot starter for control, manual spans for detail. Wire them up. Tune the sample rate. And start seeing your system.

Ready to stop guessing? Check out the in-depth guides, live repositories, and case studies from the community gathered at Arthur Raposo. Join us — build robust, observable software, and shape a community where knowledge isn’t secret… but shared.

Frequently asked questions

What is OpenTelemetry in Spring Boot?

OpenTelemetry in Spring Boot means integrating the OpenTelemetry observability standard to collect traces, metrics, and logs directly from your Java application. It works by automatically recording events during request processing and forwarding them to backends like Jaeger or Tempo for easy visualization. Recent stable support for Spring Boot (see announcement) makes setup straightforward, with out-of-the-box tracing for HTTP, database, and more.

How to set up OpenTelemetry tracing?

Start with two main approaches. Either attach the OpenTelemetry Java agent as a JVM argument (zero-code, fast for getting started), or add the OpenTelemetry Spring Boot starter and dependencies to your project (preferred for production and container-friendly environments). Then, point your configuration to a telemetry backend, like Jaeger, and configure sample rates or exporters in your application.properties. You’ll quickly start seeing traces for every request and operation (find setup details here).

Which dependencies are needed for integration?

For the starter method, add:

  • io.opentelemetry:opentelemetry-exporter-otlp
  • io.opentelemetry:opentelemetry-sdk-extension-autoconfigure
  • io.opentelemetry.instrumentation:opentelemetry-spring-boot-autoconfigure-starter
  • (Optional) spring-boot-starter-actuator and micrometer-tracing-bridge-otel

Make sure versions match the latest stable releases from the OpenTelemetry project. Is OpenTelemetry worth it for small apps?

For very small or demo apps, it could feel like overhead. But if there’s any chance your app will grow, rely on other services, or handle production traffic, instrumenting with OpenTelemetry early sets you up for fewer surprises later. Lightweight sampling and minimal configuration mean you can start basic and scale up only when you need it (read more here).

How can I view collected telemetry data?

Your traces, metrics, and logs flow to the backend system of your choice — common options are Jaeger, Grafana Tempo, Zipkin, or even cloud-native solutions. Simply configure otel.exporter.otlp.endpoint in your application. View traces via dashboards, search for request IDs, and get timelines of requests as they hop through your services. Spring Boot Actuator and Micrometer Tracing also help visualize in more familiar interfaces (read the official guide).