OpenTelemetry has the notion of a TracerProvider, which is, as the name suggests, a way of obtaining multiple Tracers. A TracerProvider is configured with a sampler, processor, exporter, etc... Each Tracer obtained from this provider then uses this configuration and denotes a so-called "instrumentation scope":
A logical unit of the application code with which the emitted telemetry can be associated. It is typically the developer's choice to decide what denotes a reasonable instrumentation scope. The most common approach is to use the instrumentation library as the scope, however, other scopes are also common, e.g. a module, a package, or a class can be chosen as the instrumentation scope.
A TracerProvider can be configured as the global one, thus making it available to instrumented libraries.
Swift Distributed Tracing Support
This concept is similar to our InstrumentationSystem, but instead of bootstrapping a single "unscoped" global tracer, it bootstraps a global tracer to obtain "scoped" tracers.
I'm keen on getting your thoughts on this to decide whether we want to embrace this OpenTelemetry concept or discard it from our API.
The issue with only supporting TracerProviders in swift-otel is that instrumented libraries with built-in tracing support don't know about the implementation details of swift-otel, therefore making it impossible to correctly implement TracerProviders in swift-otel only.
Overview
OpenTelemetry has the notion of a
TracerProvider, which is, as the name suggests, a way of obtaining multipleTracers. ATracerProvideris configured with a sampler, processor, exporter, etc... EachTracerobtained from this provider then uses this configuration and denotes a so-called "instrumentation scope":A
TracerProvidercan be configured as the global one, thus making it available to instrumented libraries.Swift Distributed Tracing Support
This concept is similar to our
InstrumentationSystem, but instead of bootstrapping a single "unscoped" global tracer, it bootstraps a global tracer to obtain "scoped" tracers.I'm keen on getting your thoughts on this to decide whether we want to embrace this OpenTelemetry concept or discard it from our API.
Alternatives considered
Supporting
TracerProviders inswift-otelThe issue with only supporting
TracerProviders inswift-otelis that instrumented libraries with built-in tracing support don't know about the implementation details ofswift-otel, therefore making it impossible to correctly implementTracerProviders inswift-otelonly.See Also 📚
TracerProviderInstrumentationScope