OpenTelemetry (OTel) is an open source, vendor-neutral framework for generating, collecting, and exporting telemetry: traces, metrics, and logs. It defines the data model, the wire protocol (OTLP), the SDKs that applications use, and the Collector that receives and routes data. Because it has no backend of its own, you can send the same data to Grafana, Prometheus, Jaeger, or a commercial vendor, and switch later without re-instrumenting your code.

Almost everything in OpenTelemetry is configured with text: a YAML file for the Collector, environment variables for SDKs, and, increasingly, a declarative YAML file for SDKs too. This series focuses on that, so your telemetry setup is reviewed, versioned, and reproducible like the rest of your infrastructure.

How it works

Applications are instrumented with an OpenTelemetry SDK (or a zero-code agent that injects one). The SDK creates spans, metrics, and log records, and exports them over OTLP, usually to a Collector. The Collector receives data, processes it (batching, enriching, filtering, sampling), and exports it to one or more backends.

App + SDK ──OTLP──▶ Collector (receivers → processors → exporters) ──▶ Backends

Core concepts

• Signals — traces, metrics, and logs. Profiles are emerging as a fourth signal.
• SDK and API — the API is what instrumentation calls, and the SDK is the implementation that samples, batches, and exports.
• OTLP — the OpenTelemetry protocol, over gRPC (port 4317) or HTTP (port 4318).
• Collector — a standalone binary built from receivers, processors, exporters, connectors, and extensions, wired together in service.pipelines.
• Resource — attributes describing the thing that produces telemetry, such as service.name and deployment.environment.name.
• Semantic conventions — standard attribute names so that data from different languages and libraries looks the same.
• Sampling — deciding which traces to keep, at the SDK (head sampling) or in the Collector (tail sampling).
• Instrumentation — manual code, libraries, or zero-code agents that create telemetry.

Why teams adopt OpenTelemetry

• No lock-in. Change backends by editing Collector config, not application code.
• One pipeline for everything. The same Collector handles traces, metrics, and logs from every language.
• Control at the edge. Filter, redact, sample, and route data before it leaves your network.
• Consistent naming. Semantic conventions make dashboards and alerts portable.
• Config as code. Collector YAML and SDK environment variables fit GitOps tools such as Flux and Argo CD.

Getting started

Run a Collector with a small config file, point an application at it using a few OTEL_* environment variables, and watch the data in the Collector’s debug exporter. The guides below take you from there to zero-code instrumentation, sampling, Kubernetes, and production hardening. They were written against recent Collector releases (the 0.16x series) and the stable declarative configuration schema; check the OpenTelemetry documentation for the versions you install, since Collector components vary in stability.