Arconia OpenTelemetry enhances observability for Spring Boot by combining the standardization of OpenTelemetry with the robustness of Micrometer.

Nov 10, 2025 • 16 min read

Observability is essential for production-ready applications. It enables teams to understand and diagnose the internal state of their systems by analysing the signals they emit, such as logs, metrics, and traces. These signals are critical for monitoring, troubleshooting, and ensuring the reliability of Java applications in production.

OpenTelemetry, a CNCF-hosted project, has emerged as the industry standard for collecting and exporting these observability signals. It defines APIs and protocols (OTLP) that are widely supported by observability backends and cloud native platforms, making it easier to integrate telemetry across different technology stacks.

In the Java ecosystem, logging is typically handled via the SLF4J API, with implementations such as Logback or Log4J2. Metrics and traces are managed through Micrometer, which is an integral part of Spring Boot’s observability features, as well as many other Java libraries.

This article explores how Arconia OpenTelemetry bridges these worlds, combining the standardisation and reach of OpenTelemetry with the robustness and stability of Micrometer to deliver a unified observability solution for Spring Boot applications.

What is Arconia?

Arconia is an open-source framework that acts as an add-on for Spring Boot. I created Arconia to enhance the development of modern enterprise applications with Java. You can add Arconia to an existing Spring Boot application to boost the developer experience, reduce boilerplate code, and seamlessly adopt cloud native patterns.

Some of the key features Arconia aims to provide include:

• Developer Experience. Introducing first-class support for development and testing modes in Spring Boot applications for making local development and testing easier, more productive, and more fun. This includes Dev Services, which automatically provisions external services using containers (as covered in a previous article).
• Generative AI. Extending integration capabilities for Spring Boot applications to include AI observability and evaluation platforms, AI inference services, and AI document processors.
• Kubernetes. Simplifying the configuration and deployment of Spring Boot applications to Kubernetes, including the build of multi-architecture container images, support for the Service Binding specification, and automatic generation of Kubernetes manifests.
• Multitenancy. Offering built-in support for multitenant applications, including web, data, security, and configuration aspects.
• Observability. Providing unified observability for Spring Boot applications, combining full support for OpenTelemetry API, SDK, and Instrumentation with full support for Micrometer API and Instrumentation.

The framework is currently under active development and is working towards its first stable release, planned for early 2026. Many of the core features are already available, including Arconia OpenTelemetry.

Why Arconia OpenTelemetry?

Establishing observability in Spring Boot applications often means working with multiple libraries and configuration models.

OpenTelemetry provides a standard API for collecting and exporting logs, metrics, and traces. However, it does not reuse the extensive and robust Micrometer instrumentation already present in the Java and Spring ecosystems. As a result, some telemetry data may be missed, or effort is required to maintain separate instrumentation.

On the other hand, Micrometer is well-integrated with Spring Boot and offers a stable and mature API for metrics and traces. However, it only provides limited support for OpenTelemetry, which can lead to compatibility issues or require additional implementation effort to achieve full OpenTelemetry compliance.

Arconia OpenTelemetry addresses this by combining full support for both OpenTelemetry and Micrometer in a single dependency. The integration is designed to work out of the box, with a unified configuration for all observability signals.

As a developer, you can instrument your application using either the Micrometer API or the OpenTelemetry API, depending on your preference or specific requirements. Arconia ensures that all telemetry data is collected and exported consistently, regardless of the method used for instrumentation.

During development, Arconia Dev Services can automatically provision a Grafana LGTM observability platform, enabling the **local inspection of telemetry data **without additional setup.

In short, the goal of Arconia OpenTelemetry is to provide a single dependency you can add to your Spring Boot application to get unified observability with minimal configuration and maximum compatibility with both OpenTelemetry and Micrometer ecosystems. Let’s see how it works in practice.

Quick Start

Let’s build a practical example to demonstrate how Arconia OpenTelemetry can provide unified observability for your Spring Boot applications. We’ll create a simple Spring Boot application that uses Spring Web to expose a few endpoints.

Logs, metrics, and traces will be automatically collected and exported using Arconia OpenTelemetry. You’ll see how no extra code or configuration is required in your development environment to achieve that.

The complete source code for this example is available on GitHub.

1. Project Setup

Start by creating a new Spring Boot project. You can use Spring Initializr or set it up manually. From the Spring Initializr, choose the following options: Spring Web.

For this example, I’ll use Spring Boot 3.5, Gradle, and Java 25. Here’s how the dependencies section of your build.gradle file should look:

dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'

testImplementation 'org.springframework.boot:spring-boot-starter-test'
testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

That’s a standard Spring Boot setup for an application of this type. Spring Web will provide a web server and HTTP handling capabilities.

Additionally, we add Arconia OpenTelemetry. You could specify the version directly in the dependency declaration, but I recommend using a BOM to manage versions consistently across your project:

dependencies {
implementation 'io.arconia:arconia-opentelemetry-spring-boot-starter'
testAndDevelopmentOnly 'io.arconia:arconia-dev-services-lgtm'
}

dependencyManagement {
imports {
mavenBom "io.arconia:arconia-bom:0.18.0"
}
}

The Arconia OpenTelemetry starter brings unified support for OpenTelemetry and Micrometer. The LGTM Dev Service dependency provisions a local Grafana observability stack for development and testing only.

💡

Notice the testAndDevelopmentOnly scope for the Arconia Dev Service dependency. That ensures the service is only available during development and testing, and is wholly excluded from production builds: precisely what you want for a development tool.

If your project utilises Spring Boot DevTools for live-restart support during development, Arconia will ensure the Grafana LGTM service remains running between code changes, eliminating the need for a restart every time.

2. Define an HTTP Router

For an initial, simple example, let’s define a basic HTTP router that responds to requests at the root path /. In the main application class, register a RouterFunction bean to implement that.

@SpringBootApplication
public class Application {

static void main(String[] args) {
SpringApplication.run(Application.class, args);
}

@Bean
RouterFunction<ServerResponse> routerFunction() {
return RouterFunctions.route()
.GET("/", _ -> ServerResponse.ok().body("Observability Rocks!"))
.build();
}

}

💡

You might have been expecting a @RestController with @GetMapping methods to implement the HTTP endpoint. While that approach works perfectly fine, I wanted to demonstrate the use of functional routing with RouterFunction, which is another way to define HTTP endpoints in Spring Web, and a very convenient one in cases like this where we want to keep things simple and we don’t have complex controller logic to implement. You can learn more about functional endpoints in the Spring Framework documentation.

3. Run the Application

It’s time to see the first example in action. Fire up your app using the standard Spring Boot command for Gradle:

./gradlew bootRun

Or, if you prefer using the Arconia CLI:

arconia dev

By default, Arconia OpenTelemetry enables the collection and export of logs, metrics, and traces to an OTLP endpoint via HTTP/Protobuf.

💡

Refer to the documentation for more information on how to configure telemetry exporters, including how to use gRPC instead of HTTP.

When you run the application, Arconia Dev Services will automatically start a local Grafana LGTM observability stack using Testcontainers and configure the application to export logs, metrics, and traces to it. That means you can inspect telemetry data locally with no manual setup required.

💡

If you’d like to learn more about Arconia Dev Services and how it works, refer to the dedicated article.

The application logs will display the URL where you can access the Grafana observability platform and begin exploring your application’s telemetry data.

... Access to the Grafana dashboard: http://localhost:<port>

If you have multiple Spring Boot applications running in your development environment with the Grafana LGTM Dev Service, Arconia will reuse the same instance across applications so that you can visualise telemetry data across all your local services from a single UI. You can read more about sharing dev services in the Arconia documentation.

4. Call the Application

Let’s verify the application is working as expected. For this example, I’ll use httpie, a command-line HTTP client that makes it easy to interact with HTTP APIs.

From a Terminal window, call the root endpoint:

http GET :8080/

You should see the response:

Observability Rocks!

5. Inspect the Telemetry

Under the hood, Arconia OpenTelemetry automatically captures logs, metrics, and traces for your application. You can explore this telemetry data in the Grafana LGTM stack, which Arconia Dev Services provisioned.

Open the Grafana URL from the application logs in your web browser. In Grafana, navigate to the “Drilldown” sections to query and visualise the logs, metrics, and traces generated by your application.

The entire Spring portfolio is instrumented to emit metrics and traces, that will be exported out-of-the-box when using Arconia OpenTelemetry.

6. Production Configuration

When you deploy your Spring Boot application to production, you can rely on a single property to configure the OpenTelemetry endpoint where logs, metrics, and traces should be exported to:

arconia.otel.exporter.otlp.endpoint=http://<observability-host>:4318

Arconia OpenTelemetry provides full support for the OpenTelemetry Environment Variable Specification, which unifies the environment variable names used across different OpenTelemetry implementations, independently of language, framework, or technology stack.

💡

Learn more about Arconia support for OpenTelemetry Environment Variable Specification in the documentation.

Besides using the Arconia-specific configuration properties, your application can be configured via such environment variables. For example:

OTEL_EXPORTER_OTLP_ENDPOINT=http://<observability-host>:4318

When is that useful? Since OpenTelemetry became the industry standard for observability, many platforms might want to unify the configuration of telemetry exporters across different services. Using standard environment variables is a great way to achieve that. Imagine you deploy your applications on Kubernetes. You can define the OTLP endpoint as an environment variable (OTEL_EXPORTER_OTLP_ENDPOINT) in your Deployment specification, and all your services, independently of the technology stack used, will be able to pick it up automatically.

💡

If you’d like to turn off the telemetry export from OpenTelemetry, you can do so via configuration properties: arconia.otel.exporter.type=none. If you’d rather turn off OpenTelemetry support completely, use arconia.otel.enabled=false (or OTEL_SDK_DISABLED=true).

Micrometer Support

Micrometer is a “vendor-neutral application observability facade” that lets you instrument your Java applications and export telemetry data without any vendor lock-in. Many Java libraries and frameworks are instrumented with Micrometer, including Spring Boot, Quarkus, Micronaut, Tomcat, Kafka, Camel, and more.

One of the main strengths of Micrometer is the **robustness and stability **of its instrumentation and APIs, which make it a perfect choice for enterprise applications running in production. Another strength is the Observation API, which allows you to capture contextual data in a way that is decoupled from how it is modeled as logs, metrics, or traces. That’s actually my preferred way to instrument a Java application, as I’ll explore in an upcoming article. It’s also how the entire Spring portfolio is instrumented.

🙏

I would like to thank the Micrometer team for maintaining such a great library, which is focused on stability and production readiness. I appreciate the team’s efforts to provide a solid foundation for observability in the Java ecosystem and for always being open to helping, discussing, and collaborating with the community.

What happens if we use Micrometer for instrumenting our Spring Boot application while pursuing OpenTelemetry compliance? The Arconia OpenTelemetry Starter includes everything you need to get full Micrometer support, without any configuration required. If you’re curious about how this is achieved, this section will elaborate on the details.

When it comes to tracing, the Micrometer Tracing project includes an OpenTelemetry Bridge, which ensures that the OpenTelemetry API is used whenever spans are created/configured via the Micrometer API. Arconia relies on this bridge and its Spring Boot auto-configuration to offer transparent support for OpenTelemetry traces instrumented via Micrometer.

When it comes to metrics, the Micrometer Metrics project doesn’t provide any OpenTelemetry Bridge. Instead, it offers the possibility to export metrics created/configured via the Micrometer API to an OTLP endpoint (using the Micrometer Metrics Registry OTLP), without going through the OpenTelemetry API. That means that only the metrics instrumented via Micrometer are exported. If you use a library instrumented via the OpenTelemetry API, those metrics will be ignored (a feature request to solve this issue in Spring Boot has been rejected).

That’s why Arconia combines the use of Micrometer Metrics Registry OTLP with the OpenTelemetry Metrics Exporter API, ensuring that all metrics, regardless of how they are instrumented, are handled consistently and exported to an OpenTelemetry backend.

💡

You can find more information about exporting metrics in the Arconia documentation.

The Micrometer Metrics Registry OTLP is a stable and robust library maintained by the Micrometer team, so it’s a great fit for enterprise applications that run in production. However, it has some drawbacks. First, it leads to having two separate metrics exporters in your applications: one for metrics instrumented via the Micrometer API and another for metrics instrumented via the OpenTelemetry API (though it has been suggested to switch its implementation to support the OpenTelemetry API natively in Micrometer, similar to what happens with traces). Second, it doesn’t currently support exemplars (a feature request for this has been raised and might be implemented in the future). Finally, it triggers a JVM warning when running on Java 25 due to its transitive usage of Google Protobuf Java library (more details here).

If that’s not an acceptable trade-off for you, Arconia offers an alternative way to support Micrometer Metrics in OpenTelemetry. Instead of the Micrometer Metrics Registry OTLP, you can rely on the Micrometer Metrics OpenTelemetry Bridge from the OpenTelemetry Java Instrumentation project. It bridges the metrics via the OpenTelemetry API, so they are handled in a standard and unified manner, alongside all other metrics produced directly from the OpenTelemetry API. However, this library is still experimental and maintained outside the Micrometer project, which might lead to compatibility issues whenever new Micrometer versions are released.

💡

You can find more information about Micrometer Metrics support for OpenTelemetry in the Arconia documentation.

You can opt out of the Micrometer Metrics Registry OTLP and replace it with the Micrometer Metrics OpenTelemetry Bridge in your build.gradle file:

dependencies {
implementation("io.arconia:arconia-opentelemetry-spring-boot-starter") {
exclude group: "io.arconia", module: "arconia-opentelemetry-micrometer-metrics-registry-otlp"
}
implementation("io.arconia:arconia-opentelemetry-micrometer-metrics-bridge")
}

The Micrometer Metrics OpenTelemetry Bridge doesn’t offer the possibility to read metrics, which is a key operation supported by Micrometer and relied upon by Spring Boot Actuator. Therefore, if you choose this option, Arconia configures a secondary Metrics Registry just for reading metrics, which is something to consider before enabling this feature.

The following table summarises the main differences between Micrometer Metrics Registry OTLP (the default option used by Arconia) and Micrometer Metrics OpenTelemetry Bridge (for which opt-in support is available in Arconia).

Aspect	Micrometer Metrics Registry OTLP	Micrometer Metrics OpenTelemetry Bridge
Stable	✅	❌
OpenTelemetry API	❌	✅
Support non-OTLP exporters	❌	✅
Support exemplars	❌	✅
Support reading metrics	✅	❌
Maintained by the Micrometer team	✅	❌

SLF4J Support

We typically handle logging in Java applications via the SLF4J API, backed by implementations like Logback (the default in Spring Boot) or Log4J2.

For example, let’s expand the previous HTTP Router to log a message every time an HTTP call is received. We’ll use the org.slf4j.LoggerFactory to build a org.slf4j.Logger, which is what provides the possibility to create a log message.

@SpringBootApplication
public class Application {

private static final Logger logger = LoggerFactory.getLogger(Application.class);

static void main(String[] args) {
SpringApplication.run(ObservabilitySignalsApplication.class, args);
}

@Bean
RouterFunction<ServerResponse> routerFunction() {
return RouterFunctions.route()
.GET("/", _ -> {
logger.info("Calling root endpoint");
return ServerResponse.ok().body("Observability Rocks!");
})
.build();
}

}

Unlike metrics and traces, OpenTelemetry doesn’t offer an API to create logs. Instead, it recommends using the logging library that makes sense based on the technical stack in use, combined with a bridge from native logs to OpenTelemetry logs.

The Arconia OpenTelemetry Starter comes built-in with the Logback OpenTelemetry Bridge from the OpenTelemetry Java Instrumentation project. It captures any log message created via SLF4J/Logback and exports it via the OpenTelemetry API. If you restart your application and call the root endpoint, you’ll be able to see the log message from your local Grafana instance (Drilldown > Logs) without requiring any custom configuration.

💡

You can find more information about SLF4J support for OpenTelemetry in the Arconia documentation.

This library is still experimental, so keep that in mind if you decide to use it. You can turn off this feature by setting the configuration property: arconia.otel.logs.logback-bridge.enabled=false.

💡

Log4J2 is not currently supported in Arconia OpenTelemetry, but it’s on its way. You can track the progress of that feature on GitHub.

Arconia OpenTelemetry vs. Alternatives

The goal of Arconia OpenTelemetry is to provide a single dependency you can add to your Spring Boot application to get unified observability with minimal configuration and maximum compatibility with both OpenTelemetry and Micrometer ecosystems.

The primary reason Arconia OpenTelemetry exists is that no other option offers this level of integration and support for both OpenTelemetry and Micrometer in a single, unified solution. This section compares Arconia OpenTelemetry with other solutions available in the Spring Boot ecosystem.

Aspect	Arconia	Spring Boot 3	Spring Boot 4	OpenTelemetry Java
OpenTelemetry Logging API	✅	✅	✅	✅
OpenTelemetry Metrics API	✅	❌	❌	✅
OpenTelemetry Tracing API	✅	✅	✅	✅
Logback Logging Bridge for OpenTelemetry API	✅	❌	❌	✅
Log4J2 Logging Bridge for OpenTelemetry API	🚧	❌	❌	✅
Micrometer Metrics Bridge for OpenTelemetry API	✅	❌	❌	✅
Micrometer Tracing Bridge for OpenTelemetry API	✅	✅	✅	❌
OpenTelemetry OTLP Logs Exporter	✅	❌	✅	✅
OpenTelemetry OTLP Metrics Exporter	✅	❌	❌	✅
OpenTelemetry OTLP Traces Exporter	✅	✅	✅	✅
OpenTelemetry Environment Variables	✅	❌	⚠️*	✅
Micrometer Metrics OTLP Exporter	✅	✅	✅	❌
OpenTelemetry Java Instrumentation	🔶	❌	❌	✅
Micrometer Instrumentation	✅	✅	✅	❌
Single Dependency	✅	❌	⚠️**	✅
Unified Configuration	✅	❌	❌	✅
Spring Boot Conventional Patterns	✅	✅	✅	⚠️*
Maintained by the Spring team	❌	✅	✅	❌

🚧 Support is under development and coming soon. 🔶 When both Micrometer and OpenTelemetry Java instrumentation available, only the Micrometer one is included. ⚠️* Only a subset is supported. ⚠️** Single dependency, but still with partial support for OpenTelemetry, so you’ll need to add more dependencies yourself.

Arconia vs. Spring Boot OpenTelemetry/OTLP

The Spring Boot project provides observability based on Micrometer with partial support for exporting telemetry for OpenTelemetry.

For logs, it supports the OpenTelemetry Logging API, but no bridges are provided to reuse existing logging instrumentation (I raised a feature request for adding this capability natively in Spring Boot).

For traces, it supports the OpenTelemetry Tracing API via a bridge from Micrometer Tracing.

For metrics, Spring Boot doesn’t provide support for the OpenTelemetry Metrics API. Instead, it offers an option to export Micrometer metrics via OTLP using the Micrometer Metrics Registry OTLP module.

A key difference between Arconia OpenTelemetry and Spring Boot is that the latter doesn’t provide full support for OpenTelemetry APIs, SDKs, and Environment Variables. The level of support is not clear from the documentation, but a more detailed description should be provided in the context of this improvement.

In particular, by not supporting the OpenTelemetry Metrics API, Spring Boot misses out on the ability to collect metrics using the standard OpenTelemetry APIs and instrumentation, which some Java libraries use.

Additionally, configuration for each observability signal is segregated rather than unified under a single OpenTelemetry configuration model to benefit from consistency and common defaults across all signals. That should be partially addressed in the context of this improvement.

For example, if you wanted to configure the OTLP endpoint, you would have to specify it three times in your application.yml file:

management:
otlp:
logging:
endpoint: http://<observability-host>:4318/v1/logs
tracing:
endpoint: http://<observability-host>:4318/v1/traces
metrics:
export:
url: http://<observability-host>:4318/v1/metrics

I hope the Spring Boot project will eventually offer a similar experience to Arconia OpenTelemetry natively. Until then, Arconia OpenTelemetry can fill that gap and provide a unified observability solution with full support for both Micrometer and OpenTelemetry.

Arconia vs. OpenTelemetry Spring Boot Starter

The OpenTelemetry Spring Boot Starter is built on top of the OpenTelemetry Java SDK and Instrumentation libraries. It provides support for OpenTelemetry APIs and SDKs, including logging, metrics, and tracing.

A key difference between Arconia OpenTelemetry and the OpenTelemetry Spring Boot Starter is that the latter doesn’t reuse most of the existing, stable Micrometer instrumentation available across the Spring and Java ecosystem. Each Spring library comes with built-in instrumentation based on the Micrometer Observation API, implemented and maintained by the same authors.

By not reusing the existing Micrometer instrumentation, the OpenTelemetry Spring Boot Starter misses out on a significant amount of telemetry data, which needs to be implemented and maintained separately by the OpenTelemetry community. That may also lead to compatibility issues whenever new Spring Boot versions are released.

Additionally, the configuration model is not as streamlined as you’d expect from a Spring Boot library, primarily due to the use of an auto-configuration design specific to the OpenTelemetry Java SDK, which doesn’t always follow the usual Spring Boot conventions.

For example, imagine you wanted to provide your own OtlpHttpSpanExporter bean which is responsible for exporting traces to an OTLP endpoint via HTTP/Protobuf. In Spring Boot, you would simply define your custom bean, and the auto-configuration will back-off.

@Bean
OtlpHttpSpanExporter exporter() {
return OtlpHttpSpanExporter.builder()
.addHeader("Authorization", "Bearer " + getToken())
.build();
}

With the OpenTelemetry Spring Boot Starter, you would need to use the APIs from the OpenTelemetry Java SDK Autoconfigure module (example adapted from here).

@Bean
AutoConfigurationCustomizerProvider customizer() {
return p ->
p.addSpanExporterCustomizer(
(exporter, config) -> {
if (exporter instanceof OtlpHttpSpanExporter) {
return OtlpHttpSpanExporter.builder()
.addHeader("Authorization", "Bearer " + getToken())
.build();
}
return exporter;
});
}

Finally, it doesn’t offer support for Spring Boot development-time services (e.g., Testcontainers or Docker Container), which makes the local development and testing experience less convenient.

Arconia vs. OpenTelemetry Java Agent

The OpenTelemetry Java Agent is built on top of the OpenTelemetry Java SDK and Instrumentation libraries. It provides support for OpenTelemetry APIs and SDKs, including logging, metrics, and tracing.

As a Java agent, it’s provided as a JAR you can attach to your application at deployment time to “dynamically inject bytecode to capture telemetry from many popular libraries and frameworks”.

It shares similar drawbacks with the OpenTelemetry Spring Boot Starter. Furthermore, it might impact the performance of your Java application due to startup overhead. Since the instrumentation is injected dynamically as bytecode, you have limited control over it. And if you’re considering compiling your Spring Boot application as a native executable with GraalVM, this option will not be available. Therefore, you’ll have to use one of the other options.

From a developer experience point of view, having to attach the Agent at deployment time has a negative impact, especially in development and testing scenarios. On the other hand, it might be the only option for observing Java applications for which you can’t change the source code.

If you decide to use the OpenTelemetry Java Agent for your containerised applications, you can take advantage of the OpenTelemetry Buildpack that I contributed to the Paketo project, allowing** the Agent to be packaged together with your application out of the box**.

For a Spring Boot project, you can configure the native Buildpacks integration as follows:

tasks.named('bootBuildImage') {
buildpacks = [
"docker.io/paketobuildpacks/java",
"docker.io/paketobuildpacks/opentelemetry"
]
environment = [
"BP_OPENTELEMETRY_ENABLED": "true"
]
}

When you package your Spring Boot application as a container image, it will include the OpenTelemetry Java Agent and have it enabled for injection at deployment time.

Conclusion

In this article, I introduced Arconia OpenTelemetry, an open-source library that provides unified observability for Spring Boot applications by combining full support for OpenTelemetry and Micrometer. The key takeaway is that you can add a single dependency to your project and have everything you need to collect and export logs, metrics, and traces using either the OpenTelemetry API or the Micrometer API, without sacrificing compatibility or stability. Additionally, you can utilise a unified configuration model and enjoy a seamless local development experience with Arconia Dev Services.

If your project is currently using Spring Boot’s partial OpenTelemetry/OTLP support or the OpenTelemetry Spring Boot Starter, I encourage you to try Arconia OpenTelemetry. You might find it simplifies your observability setup and enhances your application’s telemetry capabilities. You can find migration guides and more detailed documentation on the Arconia website.

Are you using Arconia OpenTelemetry? What’s your current experience with setting up OpenTelemetry in Spring Boot applications? I’d love to hear from you! Share your experience on Bluesky or LinkedIn. And if you’d like to contribute to the Arconia framework, feel free to reach out on our GitHub project!

First version published on November 9th, 2025.

Cover picture from Pexels.