Open jack-berg opened 1 month ago
cc @open-telemetry/java-instrumentation-approvers
explicitly install an opentelemetry instance via something like
.install(OpenTelemetry), and do nothing until a user installs it
The agent could install the otel instance automatically if the instrumentation somehow signals it, e.g. by implementing an interface
Discussed in the 7/11/24 Java SIG and later in this slack thread. Opening an issue to track and bring more visibility to the conversation.
We want libraries and frameworks to adopt the OpenTelemetry API for native instrumentation. The idea is that distributing instrumentation is more scalable than a centralized approach. Additionally, native instrumentations cast a wider net of possible users, since although native instrumentation should be compatible with a java agent, it shouldn't require a java agent.
We should document the patterns which are idiomatic for library authors to follow. This will reduce the cognitive load of adopting OpenTelemetry APIs for instrumentation (there's a lot of concepts and more we can do to simplify the better) and promote consistency.
There are a few key questions we need to discuss before documenting:
Should instrumentations default to
GlobalOpenTelemetry.get()
orOpenTelemetry.noop()
?Supposing we recommend defaulting to
GlobalOpenTelemetry.get()
...GlobalOpenTelemetry
GlobalOpenTelemetry
which current reads: "Due to the inherent complications around initialization order involving this class and its single global instance, we strongly recommend not using GlobalOpenTelemetry unless you have a use-case that absolutely requires it. Please favor using instances of OpenTelemetry wherever possible."GlobalOpenTelemetry.get()
prevents future future calls toGlobalOpenTelemetry.set()
, so an instrumentation is loaded before user code installs OpenTelemetry will cause an exception to be thrown. Users can opt into autoconfigure whenGlobalOpenTelemetry.get()
is called, but this essentially prevents full programmatic config of the SDK and installation of alternative implementations of theOpenTelemetry
interface.Supposing we recommend defaulting to
OpenTelemetry.noop()
...<class>.install(OpenTelemetry)
, and do nothing until a user installs itShould instrumentations prefer the higher order instrumentation API or the lower level trace, metrics, log bridge API?
Args in favor of the instrumentation API...
Args in favor of the trace, metrics, log bridge API...