Skip to main content
Atoti Server provides tracing capabilities through the OpenTelemetry API, which can be used with a variety of observability backends. By default, Atoti instruments the CSV source and every query execution, including distributed queries (i.e. all queries endpoints are traced). Nothing is exported until you supply an OpenTelemetry instance to Atoti Server. See Observability with OpenTelemetry for the supported setups.

​
Span level

Atoti’s spans are exported by the OpenTelemetry instance you supply, so exporters and sampling are configured where that instance is configured (the OpenTelemetry Java agent or the OpenTelemetry Spring Boot starter). The management.tracing.* properties of Micrometer Tracing configure Spring’s own observations, not Atoti’s spans. The granularity of Atoti’s spans is set with the Spring property activeviam.tracing.span.level. Every query has its own Query span whatever the level. The possible values are:
  • NONE (default): continues the parent span.
  • SPECIFIC: creates a new child span when significant tasks are invoked, currently the asynchronous MDX execution task and the task that produces the query result.
  • TASK: creates a new child span whenever a new ForkJoinTask is called.

​
What identifies a query in a trace?

The span of each query execution carries the query.id attribute, and all the parts of the execution plan of one query report the same value. The same value is reported as queryId in the query execution reports of the atoti.server.query.execution logger, and recorded as the id of the query history entry. A trace can therefore be joined with both. Each query runs in a Query span of its own, a child of the span current when the query starts, such as the select query span of an MDX query, and its query id is the id of that span. The id can therefore be looked up in the tracing backend as the span of that query, and several queries sent in parallel, even by a single request, get distinct query ids. A random id is used instead when tracing is not set up. In the following diagram, each box is a span: one request sends two queries, and the sub-queries of each query carry the query.id of that query. Each part of the execution plan also has an id of its own: a sub-query, such as a GET_AGGREGATES query, runs in a Query span of its own too, and takes its id. The query execution reports give this id under a name that depends on the kind of the part: mdxQueryId, gaqId, drillthroughQueryId or dataNodeQueryId. Each of these ids is the id of the Query span of that part, written as 16 lowercase hexadecimal characters like any OpenTelemetry span id, so it can be searched as is as a span id in the tracing backend. For the top-level query, it is equal to queryId. In the following diagram, each box is a span: an MDX query spawns two GET_AGGREGATES queries, and all three spans carry the same query.id.

​
Component specifics

In addition to the out-of-the-box information provided by OpenTelemetry, some components of Atoti add extra metrics (by adding metadata to the spans) in order to provide more insights. Check the tracing documentation of the component you want to monitor to see what information you can get: