OpenTelemetry

Its significance is decoupling instrumentation from the backend. Instrument once with a standard API, and change observability vendors by changing collector configuration rather than re-instrumenting every service — which historically was the reason organisations stayed with a vendor long after it stopped being the right choice.

The pieces: an API applications code against, an SDK implementing it, auto-instrumentation for common frameworks and clients that produces useful telemetry with no code changes, the collector — a separate process that receives, processes and exports — and semantic conventions, standard attribute names that make telemetry from different services comparable.

The collector is where most of the operational value sits: batching, retry, tail-based sampling, attribute filtering and redaction, cardinality limits, and fan-out to multiple backends. Putting these in the collector rather than in applications means changing them without redeploying services.

Maturity is uneven and worth knowing: tracing is stable, metrics are stable, logs are the least mature and many estates keep an existing logging pipeline while adopting OTel for traces.

The realistic adoption path is auto-instrumentation first for broad coverage, then manual spans and attributes where the automatic ones are insufficient.