OpenTelemetry ships a tracing API artifact separately from its SDK. Why is the split there, what should a reusable library depend on, what happens at runtime when no SDK is installed, and what is the tracer's name and version used for?

## Why two artifacts OpenTelemetry wants library authors to instrument their own code. That only works if depending on OpenTelemetry costs a library's users nothing when they do not want telemetry. Hence the split: - **API**: interfaces and a no-op default — `TracerProvider`, `Tracer`, `Span`, `Context`, `Propagator`. Stable, slow-moving, safe as a compile-time dependency. - **SDK**: the working implementation — sampler, span processors, exporters, resource, limits. Chosen and configured by the application. The rule that falls out: **libraries depend on the API, applications depend on the SDK.** A library that pulls in the SDK forces its exporter and configuration choices onto every consumer and can collide with the application's own setup. ## The no-op path With no SDK registered, the API's default provider hands back a tracer that produces **non-recording spans**. A non-recording span still carries a valid span context, so propagation and parenting keep working, but it records no attributes and is never exported. The cost is close to zero, which is what makes unconditional instrumentation acceptable. This has an ordering consequence: a component that grabs a tracer *before* the SDK is installed can hold a no-op forever in implementations that resolve eagerly. Modern SDKs mitigate this with lazily-resolving proxies, but the safe habit remains — install the SDK first, or fetch the tracer at use time. ## Instrumentation scope When you ask for a tracer you pass a **name**, optionally a **version**, and optionally a **schema URL**. Together these are the instrumentation scope, and every span the tracer emits carries it. Conventionally the name is the instrumenting library's identifier, not the service name and not the class name — the point is to identify *the instrumentation*, not the workload (the workload is identified by the resource). Why it matters in practice: - A backend can show which instrumentation produced a span, which is how you tell an agent's HTTP client span from your own wrapper. - SDK-side configuration can be scoped: metric views and, in newer configuration surfaces, per-scope enable/disable. One chatty instrumentation can be turned down without disabling everything. - The schema URL records which semantic-convention version the attributes conform to, which is what makes automated attribute translation across convention versions possible. The metrics and logs signals mirror the structure exactly: a `MeterProvider` yields meters with the same scope triple, a `LoggerProvider` yields loggers for log-bridge implementations. Same separation, same no-op default. ## Practical shape of an application The application, once at startup, builds the SDK's providers (tracer, meter, logger), attaches processors and exporters, and registers them globally so library instrumentation can find them. Everything else in the process — your code and every instrumented dependency — just asks for a tracer by scope and uses it. When an agent is present it performs that registration for you, which is why agent-installed and hand-written instrumentation land in the same pipeline. The failure mode to recognise: spans that appear to be created but never arrive, with no error anywhere. That is almost always the no-op provider — either no SDK on the path, or instrumentation that captured a tracer before registration.