OpenTelemetry Fundamentals and Concepts
OpenTelemetry (OTel) is a vendor-neutral, open-source framework for generating, collecting, and exporting telemetry. Its core purpose is to standardize how telemetry is produced and shipped, while deliberately leaving the backend (storage, query, visualization) out of scope. Candidates should know the project's building blocks: the API (interfaces used by instrumentation, no implementation), the SDK (the implementation that processes and exports), the OTLP protocol (the wire format and transport for exporting data), the Collector (a standalone agent/gateway), and instrumentation libraries.
A key conceptual split is the API vs. SDK. Application code instruments against the API; the SDK is plugged in at runtime and configured (samplers, processors, exporters). This lets a library ship instrumentation without forcing a dependency on a specific SDK version. Another frequent trap: signals are independent. Traces, metrics, logs, and baggage each have their own API/SDK pipelines and can be configured separately. Do not assume configuring a trace exporter also exports metrics.
Know the components of a span: trace ID, span ID, parent span ID, name, kind, start/end timestamps, attributes, events, links, and status. Understand that a trace is a DAG of spans sharing a trace ID, and that context (trace ID + span ID + baggage) is what ties distributed work together.
Rule of thumb: if a question asks where telemetry is stored or queried, the answer is "not OpenTelemetry" - that's the observability backend. OTel ends at export.
Worked example: A team wants library authors to add tracing without pinning an SDK version. Correct design: depend only on the OTel API in the library; the application supplies and configures the SDK.