Arconia OpenTelemetry

Arconia OpenTelemetry simplifies observability for Spring Boot applications by combining the standardization of OpenTelemetry with the robustness of Micrometer to deliver a unified solution that covers all your telemetry needs.

Need to collect, process, and export logs, metrics, and traces from your Spring Boot applications? Add the Arconia OpenTelemetry Spring Boot Starter to your project and get everything you need in one dependency.

Observability is not just for production. If you’re looking to enhance your development and testing experience, Arconia Dev Services offers a zero-code and zero-config integration with Grafana LGTM, providing a complete OpenTelemetry observability platform right in your development environment.

If you’re currently using OpenTelemetry Spring Boot Starter or Spring Boot OpenTelemetry/OTLP, check out our Migration Guides for a seamless migration to Arconia OpenTelemetry.

Quick Start

Let’s see how you can get started with Arconia OpenTelemetry in your Spring Boot application.

You can refer to our sample application for a minimal example of how Arconia OpenTelemetry works.

Dependencies

If you already have a Spring Boot application and want to add OpenTelemetry support, you can add the Arconia OpenTelemetry Spring Boot Starter dependency to your project. This will automatically configure OpenTelemetry, Micrometer, and Spring Boot Actuator for you.

Gradle
Maven

dependencies {
    implementation 'io.arconia:arconia-opentelemetry-spring-boot-starter'
}

<dependency>
    <groupId>io.arconia</groupId>
    <artifactId>arconia-opentelemetry-spring-boot-starter</artifactId>
</dependency>

Arconia publishes a BOM (Bill of Materials) that you can use to manage the version of the Arconia libraries. It is highly recommended to use the BOM to ensure that all dependencies are compatible.

Gradle
Maven

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.arconia</groupId>
            <artifactId>arconia-bom</artifactId>
            <version>0.18.2</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Dev Services

Arconia Dev Services streamline your development workflow by automatically provisioning external services your application depends on during development and testing. No manual setup is required.

With Arconia OpenTelemetry, you can leverage the Grafana LGTM Dev Service to automatically start a complete Grafana observability platform based on OpenTelemetry, allowing you to visualize and explore your application’s telemetry data during development and testing.

To enable the Grafana LGTM Dev Service, add the following dependency to your project:

Gradle
Maven

dependencies {
    testAndDevelopmentOnly "io.arconia:arconia-dev-services-lgtm"
}

<dependency>
    <groupId>io.arconia</groupId>
    <artifactId>arconia-dev-services-lgtm</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <includeOptional>false</includeOptional>
            </configuration>
        </plugin>
    </plugins>
</build>

Arconia also provides the Arize Phoenix Dev Service if you’re looking for an AI Observability and Evaluation platform based on OpenTelemetry.

Running the Application

You can run your Spring Boot application using your preferred method.

CLI
Gradle
Maven

arconia dev

./gradlew bootRun

./mvnw spring-boot:run

If you have enabled the Grafana LGTM Dev Service, Arconia will automatically start a Grafana instance pre-configured to accept OpenTelemetry logs, metrics, and traces from your application when running in development or test mode.

By default, when running the application in development mode, the Grafana LGTM Dev Service will be shared across multiple applications so that you can have a single observability platform for all your applications running in your development environment.

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

...o.t.grafana.LgtmStackContainer: Access to the Grafana dashboard: http://localhost:<port>

Learn more about the Grafana LGTM Dev Service in the dedicated documentation.

Enabling/Disabling Telemetry

The Arconia OpenTelemetry Spring Boot Starter provides sensible defaults for configuring observability signals. By default, logs, metrics, and traces are enabled and exported via OTLP to an OpenTelemetry-compatible backend.

You can disable individual observability signals or even disable the entire OpenTelemetry support via configuration properties.

Table 1. Observability Signals Configuration Properties
Property	Default	Description
`arconia.otel.enabled`	`true`	Whether OpenTelemetry support should be enabled.
`arconia.otel.logs.enabled`	`true`	Whether support for OpenTelemetry logs is enabled.
`arconia.otel.metrics.enabled`	`true`	Whether support for OpenTelemetry metrics is enabled.
`arconia.otel.traces.enabled`	`true`	Whether support for OpenTelemetry traces is enabled.

Exporting Telemetry

By default, all observability signals are exported via OTLP. If you set the exporter type to none, the observability signals will be disabled from exporting.

Table 2. Exporter Type Configuration Properties
Property	Default	Description
`arconia.otel.exporter.type`	`otlp`	The type of OpenTelemetry exporter to use for observability signals. Options: `console`, `otlp`, `none`.

You can change the type of the exporter in use for each observability signal using the arconia.otel.<signal>.exporter.type property, where <signal> is one of logs, metrics, or traces.

Table 3. Specific Exporter Type Configuration Properties
Property	Default	Description
`arconia.otel.logs.exporter.type`	(inherited from arconia.otel.exporter.type)	The type of OpenTelemetry exporter to use for logs. Options: `console`, `otlp`, `none`.
`arconia.otel.metrics.exporter.type`	(inherited from arconia.otel.exporter.type)	The type of OpenTelemetry exporter to use for metrics. Options: `console`, `otlp`, `none`.
`arconia.otel.traces.exporter.type`	(inherited from arconia.otel.exporter.type)	The type of OpenTelemetry exporter to use for traces. Options: `console`, `otlp`, `none`.

OTLP

Global properties are available to configure the OTLP exporters for logs, metrics, and traces.

Table 4. OTLP Exporter Configuration Properties
Property	Default	Description
`arconia.otel.exporter.otlp.compression`	`gzip`	Compression type to use for OTLP requests. Options: `none`, `gzip`.
`arconia.otel.exporter.otlp.connect-timeout`	`10s`	The maximum waiting time for the exporter to establish a connection to the endpoint.
`arconia.otel.exporter.otlp.endpoint`	`http://localhost:4317` (gPRC) or `http://localhost:4318` (HTTP)	The endpoint to which telemetry data will be sent.
`arconia.otel.exporter.otlp.headers`	-	Additional headers to include in each request to the endpoint.
`arconia.otel.exporter.otlp.metrics`	`false`	Whether to generate metrics for the exporter itself.
`arconia.otel.exporter.otlp.protocol`	`http-protobuf`	Transport protocol to use for OTLP requests. Options: `grpc`, `http-protobuf`.
`arconia.otel.exporter.otlp.timeout`	`10s`	The maximum waiting time for the exporter to send each telemetry batch.
`arconia.otel.exporter.memory-mode`	`reusable-data`	Whether to reuse objects to reduce allocation or work with immutable data structures. Options: `reusable-data`, `immutable-data`.
`arconia.otel.exporter.otlp.retry.max-attempts`	`5`	Maximum number of retries.
`arconia.otel.exporter.otlp.retry.backoff-config.first-backoff`	`1s`	Initial backoff time.
`arconia.otel.exporter.otlp.retry.backoff-config.max-backoff`	`5s`	Maximum backoff time.
`arconia.otel.exporter.otlp.retry.backoff-config.multiplier`	`1.5`	Backoff multiplier.

You can override any of these properties for each observability signal using the arconia.otel.<signal>.exporter.* prefix, where <signal> is one of logs, metrics, or traces. For more details, refer to the dedicated documentation for Logs, Metrics, and Traces.

HTTP

By default, the OpenTelemetry SDK uses HTTP/Protobuf for OTLP communication. In particular, it relies on the JDK Http Client to send telemetry data to the endpoint.

gRPC

You can switch to gRPC by changing the arconia.otel.exporter.otlp.protocol property to grpc. Additionally, you need to add the following dependencies:

Gradle
Maven

dependencies {
    implementation "io.opentelemetry:opentelemetry-exporter-sender-grpc-managed-channel"
    runtimeOnly "io.grpc:grpc-netty-shaded"
}

<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-sender-grpc-managed-channel</artifactId>
</dependency>
<dependency>
    <groupId>io.grpc</groupId>
    <artifactId>grpc-netty-shaded</artifactId>
</dependency>

The opentelemetry-exporter-sender-grpc-managed-channel requires a transport implementation. The grpc-netty-shaded dependency is one choice, but you can use any other gRPC transport implementation that fits your needs.

Console

Instead of OTLP, you can use the console exporter to print the telemetry data to the console. This is useful for debugging and testing purposes. Besides setting the exporter type to console for the observability signals you want to export, you also need to add the following dependency:

Gradle
Maven

dependencies {
    implementation "io.opentelemetry:opentelemetry-exporter-logging"
}

<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-logging</artifactId>
</dependency>

This exporter option is not recommended for production.

The console exporter doesn’t support exporting metrics defined using the Micrometer APIs when using the Micrometer Metrics Registry OTLP module instead of the OpenTelemetry Micrometer Metrics Bridge.

OpenTelemetry Environment Variables

Arconia supports the OpenTelemetry Environment Variable Specification for configuring the OpenTelemetry integration. If both the OpenTelemetry Environment Variables and the Arconia configuration properties are set, the OpenTelemetry Environment Variables will take precedence.

This support is especially useful during deployment, where you can use the same set of standard environment variables to configure OpenTelemetry across different languages and frameworks.

You can disable this support by setting the arconia.otel.compatibility.environment-variable-specification configuration property to false.

Comparisons

Arconia provides unified observability for Spring Boot applications, combining full support for OpenTelemetry API, SDK, and Instrumentation with full support for Micrometer API and Instrumentation. The goal is to provide a single, unified observability solution for Spring Boot applications that can give you the best of both worlds: the standardization and ubiquity of OpenTelemetry and the robustness and stability of Micrometer.

Arconia provides full support for OpenTelemetry and Micrometer

The main reason why Arconia OpenTelemetry exists is that no other option provides 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 (see the comparison table below).

Table 5. Differences between Arconia OpenTelemetry and other solutions
Aspect	Arconia OpenTelemetry	Spring Boot 3	Spring Boot 4	OpenTelemetry Spring Boot Starter
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	✅	❌	⚠️**	✅
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 OpenTelemetry vs Spring Boot OpenTelemetry

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. 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.

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.

Arconia OpenTelemetry 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.

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.