Is there a way to retrieve the local "root" span

[NicklasWallgren]

Is it possible to access the local root span without explicitly storing it in a thread-local or context variable at the beginning of the process?

Our goal is to add an attribute to the root span from a point several spans deep in the trace.

Related discussion: open-telemetry/opentelemetry-go#3457

[trask]

The Java instrumentation uses https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/LocalRootSpan.java, but this is not part of the core SDK, and so only works if all of your instrumentation is using it.

[NicklasWallgren]

The Java instrumentation uses https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/LocalRootSpan.java, but this is not part of the core SDK, and so only works if all of your instrumentation is using it.

Alright, thanks. I suppose we'll have to keep storing it explicitly for now. Hopefully, the API will change in the future.

We're migrating from Elastic APM, which has the concept of transactions (service root spans), so it's a bit of a bummer that OpenTelemetry doesn't offer equivalent functionality.

[trask]

are you using the OpenTelemetry Java agent? if so LocalRootSpan should work

[jkwatson]

Hopefully, the API will change in the future

If this is something you want, "hope" won't make it happen. The only way to make it happen is to join the community, make a proposal in the specification and help push it forward. Otherwise, it definitely will not happen.

[NicklasWallgren]

are you using the OpenTelemetry Java agent? if so LocalRootSpan should work

@trask Thanks! Unfortunately, LocalRootSpan.store is package-private and it's primarily used by the Instrumenter, which seems to be designed around HTTP request/response handling.

In my case, I'm looking to create a local root span for a queue job, which originates from a database-based task scheduler. It would be really helpful to have a more generalized Instrumenter-like abstraction that isn't tied to the request/response paradigm - something that better fits background or asynchronous processing scenarios.

[trask]

check out the quartz instrumentation: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/bb571fd4039c3cd2f95754dad36423357c7ce5fa/instrumentation/quartz-2.0/library/src/main/java/io/opentelemetry/instrumentation/quartz/v2_0/QuartzTelemetryBuilder.java#L79