OpenTelemetry has many parts, and most confusion comes from mixing them up. This guide separates them: what runs inside your application, what runs next to it, and where each one is configured. Once the map is clear, the rest of the series is mostly filling in YAML.

The problem it solves

Before OpenTelemetry, each monitoring vendor shipped its own agent and its own data format. Switching vendors meant re-instrumenting every service, and running two tools meant running two agents. OpenTelemetry separates the two concerns: instrumentation produces standard data once, and a pipeline decides where it goes.

The pieces

Piece	What it is	Where it runs
API	The interfaces instrumentation code calls (start a span, record a metric)	In your app
SDK	The implementation behind the API: sampling, batching, exporting	In your app
Instrumentation	Code that creates telemetry for libraries (HTTP, databases)	In your app, via libraries or a zero-code agent
OTLP	The wire protocol for telemetry, over gRPC or HTTP	Between components
Collector	A standalone service that receives, processes, and exports telemetry	Next to apps, per node, or as a central gateway
Semantic conventions	Standard names for attributes, such as http.request.method	Everywhere

Applications can export straight to a backend, but putting a Collector in between is the usual recommendation, because it lets you change processing and destinations without redeploying applications.

Three layers of configuration

1. The application’s SDK, configured with OTEL_* environment variables or, increasingly, a declarative YAML file pointed to by OTEL_CONFIG_FILE. It controls the service name, resource attributes, sampler, and where to export.
2. The Collector, configured with a YAML file. It controls what is received, how data is transformed, and where it goes.
3. The platform glue: Docker Compose files, Helm values, or Kubernetes resources from the OpenTelemetry Operator, which deploy the Collector and inject configuration into applications.

Everything in these layers is text, so it can live in Git.

Data flow in one picture

┌────────────┐  OTLP   ┌─────────────────────────────┐        ┌───────────┐
│ App + SDK  │────────▶│ Collector                   │───────▶│ Traces    │
│ (env vars  │ 4317/   │ receivers → processors →    │───────▶│ Metrics   │
│  or YAML)  │ 4318    │ exporters (config.yaml)     │───────▶│ Logs      │
└────────────┘         └─────────────────────────────┘        └───────────┘

Signals at a glance

• Traces record the path of a request through services as spans. They answer “where did the time go?”
• Metrics are numeric measurements over time, such as request counts and latency histograms. They answer “how is the system trending?”
• Logs are timestamped records. OpenTelemetry can correlate them with traces, so a log line links to the span that produced it.

Each signal has its own pipeline in the Collector, and its own provider in an SDK.

Stability: read before you adopt

OpenTelemetry is large and its parts mature at different speeds. The OTLP protocol and the tracing and metrics APIs are stable. Collector components carry their own stability levels, and many contrib components are still beta or alpha. Declarative SDK configuration reached a stable schema in 2026, but SDK implementations are catching up unevenly, with Java and a few others ahead. When you choose a component or a feature, check its stability in the documentation, and pin versions.

A suggested path through this series

1. Run a Collector and send it data (Docker Compose).
2. Learn the Collector configuration model.
3. Configure SDKs with environment variables and, where supported, a declarative file.
4. Add zero-code instrumentation to an app.
5. Make the Collector production-ready: batching, memory limits, retries, sampling.
6. Deploy it on Kubernetes with Helm or the Operator.
7. Collect logs and infrastructure metrics, send to backends securely, and troubleshoot.

For reference, see the OpenTelemetry documentation.