OpenTelemetry Collector Dev Service

A service providing an OpenTelemetry Collector for development and testing purposes.

It works with Spring Boot libraries that support OpenTelemetry, including:

This Dev Service is mutually exclusive with other OpenTelemetry dev services. If more than one is active at the same time, the application will fail at startup with a clear error message. Disable all but one by setting arconia.dev.services.<name>.enabled=false.

Dependencies

First, you need to add the Dev Service dependency to your project.

  • Gradle

  • Maven

dependencies {
  testAndDevelopmentOnly "io.arconia:arconia-dev-services-otel-collector"
}
<dependency>
    <groupId>io.arconia</groupId>
    <artifactId>arconia-dev-services-otel-collector</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

You can optionally include the Spring Boot DevTools dependency to enable live reload of your application during development.

  • Gradle

  • Maven

dependencies {
  developmentOnly "org.springframework.boot:spring-boot-devtools"
}
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

When you use the Spring Boot DevTools in your project, Arconia will keep the Dev Services running while you make changes to your code instead of restarting them with the application. This allows you to see the changes in real-time without having to restart the Dev Services.

Running the Application

When using the Arconia Dev Services, you can keep running your application as you normally would. The Dev Services will automatically start when you run your application.

  • Gradle

  • Maven

  • CLI

./gradlew bootRun
./mvnw spring-boot:run
arconia dev
Unlike the lower-level Testcontainers support in Spring Boot, Arconia doesn’t require special tasks to run your application when using Dev Services (./gradlew bootTestRun or ./mvnw spring-boot:test-run) nor requires you to define a separate @SpringBootApplication class for configuring Testcontainers.

Your integration tests based on @SpringBootTest will automatically use the Dev Services without any additional configuration.

Test slices (e.g. @DataJdbcTest) load only a subset of the auto-configurations, so they don’t pick up Dev Services automatically. You can import the Dev Service explicitly. For example, for the PostgreSQL Dev Service:

@DataJdbcTest
@AutoConfigureTestDatabase(replace = Replace.NONE)
@Import(PostgresqlDevServicesAutoConfiguration.class)
class CustomerRepositoryTests {
    ...
}

By default, when running the application in dev mode, the Dev Service is shared across multiple applications running simultaneously: the application connects to a running OpenTelemetry Collector Dev Service started by another application if available, or else starts its own that other applications can discover in turn.

Exploring the Telemetry

The application logs will show you the URLs where the OpenTelemetry Collector is accepting logs, metrics, and traces.

...s.l.e.o.OtlpLoggingExporterConfiguration : Configuring OpenTelemetry HTTP/Protobuf log exporter with endpoint: http://localhost:39117/v1/logs
...s.m.e.o.OtlpMetricsExporterConfiguration : Configuring OpenTelemetry HTTP/Protobuf metric exporter with endpoint: http://localhost:39117/v1/metrics
...s.t.e.o.OtlpTracingExporterConfiguration : Configuring OpenTelemetry HTTP/Protobuf span exporter with endpoint: http://localhost:39117/v1/traces

By default, logs, metrics, and traces are exported via OTLP using the HTTP/Protobuf format.

The Dev Service runs the image’s built-in default configuration, whose pipeline only exports the received telemetry to the collector’s own debug exporter, visible in the collector container logs. It is meant for locally inspecting what your application emits, not for forwarding telemetry to another backend. To route telemetry elsewhere, supply a custom collector configuration as described in the next section.

Customizing the Collector Configuration

To go beyond the built-in default configuration, for example to forward telemetry to another backend, you can supply your own collector configuration file and copy it into the container via the resources property (see Resource Mappings). Each mapping requires two values:

  • Source path: Location of the resource on the classpath or filesystem;

  • Container path: Destination path inside the container.

The OpenTelemetry Collector reads its configuration from /etc/otelcol-contrib/config.yaml, so copying your file to that path replaces the default configuration.

arconia:
  dev:
    services:
      otel-collector:
        resources:
          - source-path: otel-collector-config.yml
            container-path: /etc/otelcol-contrib/config.yaml

Make sure your configuration keeps the OTLP receiver listening on the default ports (4317 for gRPC and 4318 for HTTP), since those are the ports the Dev Service exposes to the host and wires into your application.

Configuring the Dev Service

You can configure the Dev Service via configuration properties.

Property Default Description

arconia.dev.services.otel-collector.enabled

true

Whether the dev service is enabled.

arconia.dev.services.otel-collector.image-name

otel/opentelemetry-collector-contrib

Full name of the container image used in the dev service.

arconia.dev.services.otel-collector.environment

{}

Environment variables to set in the service.

arconia.dev.services.otel-collector.network-aliases

[]

Network aliases to assign to the dev service container.

arconia.dev.services.otel-collector.port

0

Fixed port for exposing the OTLP HTTP port to the host. When it’s 0 (default), a random available port is assigned dynamically.

arconia.dev.services.otel-collector.resources

[]

Resources from the classpath or host filesystem to copy into the container. They can be files or directories that will be copied to the specified destination path inside the container at startup and are immutable (read-only).

arconia.dev.services.otel-collector.reuse

false

Whether the container used in the dev service is reused across multiple applications and application restarts, relying on the Testcontainers reusable containers feature. Only applicable in dev mode.

arconia.dev.services.otel-collector.shared

true

Whether the dev service is shared among applications running simultaneously. A shared dev service is discoverable by other applications, and the application connects to an existing shared dev service if available instead of starting a new one. Only applicable in dev mode.

arconia.dev.services.otel-collector.startup-timeout

30s

Maximum waiting time for the service to start.

arconia.dev.services.otel-collector.volumes

[]

Files or directories to mount from the host filesystem into the container. They are mounted at the specified destination path inside the container at startup and are mutable (read-write). Changes in either the host or the container will be immediately reflected in the other.

arconia.dev.services.otel-collector.otlp-grpc-port

0

Fixed port for exposing the OTLP gRPC port to the host. When it’s 0 (default), a random available port is assigned dynamically.

You can enable/disable the Dev Service selectively for a specific application mode (development, test), relying on one of the profiles which are automatically configured by Arconia (see Profiles).

You can enable/disable the Dev Service for a specific test class by using the @TestPropertySource annotation or equivalent Spring testing utilities.