OpenTelemetry
The vendor-neutral standard — signals, SDKs, the Collector, OTLP, and context propagation
OpenTelemetry is not a backend. It is a vendor-neutral specification, a set of SDKs and a Collector, and the whole point is that instrumentation outlives your choice of vendor. That framing answers most interview questions before they are asked: you instrument once with OTel and can switch from one observability vendor to another by reconfiguring an exporter rather than rewriting code. Expect questions on the three signals and their differing maturity, on context propagation and the W3C traceparent header that makes distributed tracing work across process boundaries, and on the Collector's receiver-processor-exporter pipeline. Deployment topology comes up frequently: an agent Collector on each host for local collection, versus a gateway Collector for centralised sampling, batching and redaction. Head-based versus tail-based sampling is the classic follow-up, since only a gateway can make tail decisions.
The Standard — Signals & Semantics
Understand OpenTelemetry as a vendor-neutral standard for metrics, logs, and traces.
SDKs & Auto-Instrumentation
Generate telemetry from apps with minimal code via APIs, SDKs, and agents.
The Collector — Pipelines
Run a vendor-neutral pipeline to receive, process, and export telemetry.
OTLP, Context Propagation & Backends
Connect the dots: how OTLP and context carry data across services to any backend.