OpenTelemetry — the vendor-neutral observability standard

OpenTelemetry (OTel) is the open-source standard for emitting metrics, logs, and traces. Lets you switch backends (Datadog, Honeycomb, Grafana Cloud) without changing app code.

## Why OTel matters

- Avoid vendor lock-in
- One instrumentation library, many backends
- Standard semantic conventions (HTTP, DB, cloud)
- Strong OSS ecosystem in 2026

## Three pillars in OTel

1. **Traces** — request flow across services
2. **Metrics** — counters, gauges, histograms
3. **Logs** — structured events (newer; less mature)

All flow through a **Collector** (daemon that batches + routes telemetry).

## Architecture pattern

```
App SDK -> OTel Collector (agent/sidecar) -> Backend(s)
```

Collector lets you fan out to multiple backends, sample, filter, and transform without app changes.

## Instrumenting code

```python
from opentelemetry import trace
tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("checkout") as span:
    span.set_attribute("order.id", order_id)
```

## Auto-instrumentation

```bash
opentelemetry-instrument --traces_exporter otlp python app.py
```

## When to choose OTel

- Multi-cloud / multi-vendor environments
- Long-term cost / lock-in concerns
- A/B between observability vendors
- Strong DevOps team to operate the collector

## When to stay on vendor SDK

- Single vendor, no plans to migrate
- Small team, don't want to operate collectors
- Vendor SDK has features OTel doesn't

## 2026 trajectory

OTel is winning. Most major vendors now natively accept OTLP. New instrumentation work should default to OTel.