RFC: Support OpenTelemetry tracer provider concept

[slashmo]

Overview

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.

OpenTelemetry Spec: InstrumentationScope

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.

Alternatives considered

Supporting TracerProviders in swift-otel

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.

---

See Also 📚

• OpenTelemetry Spec: TracerProvider
• OpenTelemetry Spec: InstrumentationScope