OpenTelemetry (OTel)

The vendor-neutral standard for emitting traces, metrics, and logs, so you instrument once and can swap monitoring tools later.

instrument once, switch tools laterthe standard logging/tracing formatotelopen telemetryopentelemtryotlpvendor neutral telemetry standardthe thing that stops me getting locked into one monitoring vendor

See it

Live demo coming soon

What it is

OpenTelemetry (everyone says 'OTel') is a CNCF project that defines one API, one SDK per language, and one wire protocol (OTLP) for the three telemetry signals: traces, metrics, and logs. Before it, moving from one vendor's agent to another meant rewriting every call site. With OTel your code talks to a neutral API and the choice of backend becomes a config line.

Three pieces to keep straight. The SDK lives inside your app and produces telemetry, with auto-instrumentation packages covering common frameworks, HTTP clients, and database drivers at close to zero lines of code. The Collector is a separate process that receives, batches, filters, redacts, and routes telemetry, which is where you fan out to two backends or scrub PII in one place. Semantic conventions are the agreed attribute names (http.request.method, db.system, service.name) that let any backend chart your data without custom setup.

Gotchas: the signals matured at different speeds, so tracing is rock solid, metrics are solid, and logs arrived last, which is why plenty of teams still ship logs the old way alongside OTel traces. Auto-instrumentation is generous with span volume, so plan sampling before the invoice teaches you. And forgetting to set service.name and deployment.environment is the classic day-one mistake: every service shows up in the UI as 'unknown_service'.

Ask AI for it

Set up OpenTelemetry in this app. Install the OTel SDK and the auto-instrumentation package for this runtime, and initialize it in a separate file loaded before any other import so library patching works. Configure an OTLP exporter over HTTP pointed at OTEL_EXPORTER_OTLP_ENDPOINT, and set resource attributes service.name, service.version, and deployment.environment from env vars. Enable traces and metrics, use a batch span processor, and default to a parent-based sampler at 10% with errors always kept. Follow OTel semantic conventions for attribute names, and keep every vendor-specific choice out of app code so the backend can change by editing collector config alone.

You might have meant

distributed tracingspaninstrumentationtelemetryopentelemetry collector

Go deeper