Skip to main content
Atoti Server is instrumented to produce traces and metrics. Nothing is exported until you give Atoti Server an OpenTelemetry instance. This page explains how to do so.

​
How Atoti Server finds the OpenTelemetry instance

The Atoti Server Starter uses the application’s io.opentelemetry.api.OpenTelemetry Spring bean. Each setup below provides that bean: you declare it in Setups 1 and 3, and the OpenTelemetry Spring Boot starter declares it in Setup 2.
Atoti Server does not read GlobalOpenTelemetry by itself. Attaching the OpenTelemetry Java agent alone leaves Atoti Server’s own spans and metrics as no-ops. Expose the agent’s instance as a bean, as described in the first setup below.
Choose the setup that matches how your application is deployed. Whichever you choose, the exporters, endpoints and sampling are configured by whatever owns the OpenTelemetry instance, not by Atoti Server.

​
Setup 1: OpenTelemetry Java agent

Attach the OpenTelemetry Java agent to the JVM and configure it with its otel.* system properties or OTEL_* environment variables. Then declare a bean that exposes the agent’s instance to Atoti Server:
This is the setup used by the Atoti Python SDK observability plugin.

​
Setup 2: OpenTelemetry Spring Boot starter

Without an agent, add the OpenTelemetry Spring Boot starter, io.opentelemetry.instrumentation:opentelemetry-spring-boot-starter, to the application. It provides the OpenTelemetry bean, with traces, metrics and logs exporters configured through otel.* properties. No additional code is needed.

​
Setup 3: OpenTelemetry SDK bean (advanced)

If neither setup fits, build an OpenTelemetry SDK instance yourself and declare it as a bean. Follow the OpenTelemetry manual setup.
  • Traces, metrics and logs are sent only if the SDK is configured with the matching exporters.
  • Logs also require the OpenTelemetry Logback appender.
Use this setup only when no OpenTelemetry Java agent is attached. With an agent, the SDK bean creates a second instance: Atoti Server’s spans go to one and the agent’s HTTP and JDBC spans go to the other, which splits traces.

​
MDC attributes

Atoti Server puts these attributes in the logging MDC: To export an attribute, enable MDC capture of its name in your OpenTelemetry Logback integration. The logs written while a request is being authenticated, such as those of the authentication filters, do not carry user_name.

​
Known pitfalls

Spring Boot’s spring-boot-starter-opentelemetry drops Atoti Server’s metrics. Atoti Server’s spans are exported, but its metrics, which are recorded through the OpenTelemetry metrics API, are silently dropped. Spring Boot does not auto-configure an SdkMeterProvider and uses one only if you declare an SdkMeterProvider bean. The Spring Boot reference states: “If you or a dependency you include make use of OpenTelemetry’s MeterProvider, those metrics are not exported.” Prefer Setup 1 or Setup 2, or declare an SdkMeterProvider bean.
With the agent attached and Micrometer’s tracing bridge active (micrometer-tracing-bridge-otel and spring-boot-micrometer-tracing-opentelemetry), incoming HTTP, WebClient and GraphQL requests are traced twice. Suppress the duplicate Spring observations in your application, for example with an ObservationRegistryCustomizer that filters them out with a predicate.

​
Check the result

Run a query, for example from a pivot table in Atoti UI, and look for the query spans in your observability backend. See Tracing for what Atoti Server traces and Metrics for the metrics it records.