API and SDK Separation, Providers and Plugin Interfaces: OTCA practice questions

OpenTelemetry splits each signal into an API and an SDK so that instrumentation never depends on a particular implementation. Libraries and frameworks reference only the API packages, and the spec overview says instrumentation authors must not directly reference any SDK package. The application owner decides whether to install the SDK, which exporters to use and how to configure everything else. Without an SDK the API stays functional but records nothing. Even then, a span created from a context that holds a remote parent is returned as a non-recording span carrying that parent's SpanContext, so trace context still flows to outgoing calls.

Providers are the entry points for each signal: TracerProvider, MeterProvider and LoggerProvider. The API should offer a way to register and read a global default provider, but an application may also create several provider instances, for example to give different span processors to different parts of a program. Configuration lives in the provider rather than in individual Tracers or Meters. The Tracing API also requires that users never have to obtain a Tracer again just to pick up configuration changes.

The SDK exposes two kinds of public surface that are not part of the API. Application owners use SDK constructors, and plugin authors use SDK plugin interfaces. On the tracing side the extension points include span processors, samplers, span exporters and ID generators. A sampler implements ShouldSample and returns DROP, RECORD_ONLY or RECORD_AND_SAMPLE, plus attributes and a Tracestate. The ID generator lets a vendor supply custom trace and span IDs; vendor-specific generators such as an AWS X-Ray one must not be shipped in core packages. Propagators are also pluggable, and the spec treats OTLP exporters and the TraceContext propagator as core packages defined by the specification.

Resources have their own extension point. Resource detectors for platforms such as Docker or Kubernetes, or for cloud vendors, must be published separately from the SDK. They return a resource that is merged into the one associated with a provider. A detector that finds nothing has not failed, but combining detectors whose non-empty Schema URLs differ is an error with an undefined result. On the metrics side, Views let the application owner change which instruments are kept, how they are aggregated and which attribute keys survive, without editing library code. A match-all View with the Drop aggregation disables instruments by default.

Exporters should stay thin. The client design principles ask vendors to implement the SDK exporter interface in a separate package and to rely on SDK helpers for batching, queuing and retry. The same principles describe an in-memory exporter that collects telemetry for unit tests. Optional packages that the project maintains are Contrib: API Contrib depends only on the API, while SDK Contrib also depends on the SDK.