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.

Arconia provides full support for OpenTelemetry and 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.

Table 1. Observability Signals Configuration Properties
Property Default Description

arconia.otel.enabled

true

Whether OpenTelemetry SDK 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. 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.

Table 2. Exporter Type Configuration Properties

Property

Default

Description

arconia.otel.logs.exporter.type

otlp

The type of OpenTelemetry exporter to use for logs. Options: console, otlp, none.

arconia.otel.metrics.exporter.type

otlp

The type of OpenTelemetry exporter to use for metrics. Options: console, otlp, none.

arconia.otel.traces.exporter.type

otlp

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

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.