The OpenTelemetry API and SDK: OTCA practice questions

OpenTelemetry separates the API, the interfaces that code calls to produce telemetry, from the SDK, the implementation that decides what happens to it. The specification is strict about the direction of dependencies: instrumentation authors must not reference any SDK package, only the API. Libraries are instrumented against the API, and the application owner installs and configures the SDK. That split is what lets a library ship instrumentation without choosing a backend or imposing overhead on its users.

Without an installed SDK, the trace API is a no-op. Tracer and span operations have no side effects, with one exception that matters for distributed tracing: the API still returns a non-recording span carrying the parent's span context, so a context extracted by a propagator continues to flow to children and is injected into outgoing calls. If there is no parent, the returned span has all-zero IDs and is not sampled.

Each signal has a provider and an object obtained from it. A TracerProvider is the stateful object that holds configuration such as the resource and exporters, is usually created once for the life of the application, and hands out Tracers, which create spans. A MeterProvider hands out Meters, which create instruments: Counter, which only increases; UpDownCounter, which can also decrease; Gauge, which records a current value; Histogram, which aggregates values such as latencies on the client side; and asynchronous versions of the counters and gauge that are read once per export. Views in the metrics SDK change what is exported: which instruments are kept, the aggregation, and which attributes are reported, which is how unneeded attributes are dropped. For logs, the LoggerProvider and Logger belong to the Logs Bridge API, which is meant for authors of logging libraries; applications keep their usual logging framework and connect it through an appender or bridge.

Exporters send data out, to standard output for debugging, to a Collector, or to a backend, usually over OTLP. A resource describes the entity that produces telemetry, such as a process, host or container, and resource detectors fill it in. Samplers limit how many traces are produced. Head sampling decides early, typically from the trace ID and a ratio, and is cheap but cannot keep, for example, every trace with an error; tail sampling decides after seeing most of a trace and runs in the Collector's tail sampling processor, at the cost of stateful infrastructure.

Propagators carry context between services. The sender injects the context into a carrier such as HTTP headers and the receiver extracts it; the default uses W3C TraceContext, and baggage carries additional key-value pairs.

Instrumentation can come from instrumentation libraries for popular frameworks, which OpenTelemetry publishes under names such as opentelemetry-instrumentation-flask, or from zero-code instrumentation that adds the API and SDK without source changes; in Kubernetes the OpenTelemetry Operator can inject it. Language support differs by signal. The status table lists C++, .NET, Java and PHP as stable for traces, metrics and logs, while for example Python and JavaScript logs, and Ruby and Swift metrics and logs, are still in development, so check the table before assuming a signal is stable in a given language.