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

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.
dependencies {
implementation 'io.arconia:arconia-opentelemetry-spring-boot-starter'
}
Arconia publishes a BOM (Bill of Materials) that you can use to manage the version of the Arconia OpenTelemetry libraries. Whether not required, it is recommended to use the BOM to ensure that all dependencies are compatible.
dependencyManagement {
imports {
mavenBom "io.arconia:arconia-bom:0.10.0"
}
}
Dev Services
Building on top of Spring Boot support for Testcontainers, Arconia provides zero-code dev services for a superior developer experience. When working with OpenTelemetry, you can use the OpenTelemetry LGTM Dev Service to automatically start a full Grafana observability platform based on OpenTelemetry, giving you the possibility to visualize and explore your application’s telemetry data during development and testing.
To enable the OpenTelemetry LGTM Dev Service, add the following dependencies to your project.
dependencies {
developmentOnly "org.springframework.boot:spring-boot-devtools"
testAndDevelopmentOnly "io.arconia:arconia-dev-services-opentelemetry-lgtm"
}
Running the Application
Once you have added the dependencies, you can run your Spring Boot application using the usual tasks provided by the Spring Boot plugins for Gradle or Maven.
./gradlew bootRun
Unlike the lower level Testcontainers support in Spring Boot, with Arconia you don’t need special tasks to run your application with Dev Services (e.g. ./gradlew bootTestRun ).
|
The application logs will show you the URL where you can access the Grafana observability platform.
...o.t.grafana.LgtmStackContainer: Access to the Grafana dashboard: http://localhost:38125
Learn more about the OpenTelemetry LGTM Dev Service in the Dev Services section. |
Configuring Observability
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.
Property | Default | Description |
---|---|---|
|
|
Whether OpenTelemetry SDK support should be enabled. |
|
|
Whether support for OpenTelemetry logs is enabled. |
|
|
Whether support for OpenTelemetry metrics is enabled. |
|
|
Whether support for OpenTelemetry traces is enabled. |
Exporting Telemetry
By default, all observability signals are exported via OTLP. You can change the type of the exporter in use for each observability signal. If you set the exporter type to none
, the corresponding signal will be disabled from exporting.
Property |
Default |
Description |
|
|
The type of OpenTelemetry exporter to use for logs. Options: |
|
|
The type of OpenTelemetry exporter to use for metrics. Options: |
|
|
The type of OpenTelemetry exporter to use for traces. Options: |
OTLP
Global properties are available to configure the OTLP exporters for logs, metrics, and traces.
Property |
Default |
Description |
|
|
Compression type to use for OTLP requests. Options: |
|
|
The maximum waiting time for the exporter to establish a connection to the endpoint. |
|
|
The endpoint to which telemetry data will be sent. |
|
- |
Additional headers to include in each request to the endpoint. |
|
|
Whether to generate metrics for the exporter itself. |
|
|
Transport protocol to use for OTLP requests. Options: |
|
|
The maximum waiting time for the exporter to send each telemetry batch. |
|
|
Whether to reuse objects to reduce allocation or work with immutable data structures. Options: |
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:
dependencies {
implementation "io.opentelemetry:opentelemetry-exporter-sender-grpc-managed-channel"
implementation "io.grpc:grpc-netty-shaded:1.71.0"
}
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:
dependencies {
implementation "io.opentelemetry:opentelemetry-exporter-logging"
}
This exporter option is not recommended for production. |