Skip to main content
PrepForge
Home
Questions Others Experiences
Search problems, topics...Ctrl K
Sign in
All platforms

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.

0/4 learned
1

The Standard — Signals & Semantics

Understand OpenTelemetry as a vendor-neutral standard for metrics, logs, and traces.

standardotlpsignalsvendor-neutral
2

SDKs & Auto-Instrumentation

Generate telemetry from apps with minimal code via APIs, SDKs, and agents.

sdkauto-instrumentationagentspans
3

The Collector — Pipelines

Run a vendor-neutral pipeline to receive, process, and export telemetry.

collectorpipelinestail-samplingexporters
4

OTLP, Context Propagation & Backends

Connect the dots: how OTLP and context carry data across services to any backend.

otlppropagationw3c-traceparentbaggage
Written and reviewed by Santosh Bhima, SSR Labs. © 2026 SSR Labs. All rights reserved.
AboutContactPrivacyTermsChangelog