Which components make up OpenTelemetry, and why does the collector matter so much?

Instrumentation produces the signals, the SDK collects and enriches them, and the collector centrally processes them — filtering, aggregating and forwarding — which is what frees the application from knowing where its data will end up.

* Instrumentation and SDK live in the app; the collector is the indirection that lets the back end change by configuration alone. *

• Instrumentation — the deliberate placement of measurement points in an application, producing metrics, logs and traces. Much of it is automatic for common frameworks; the rest is added by hand where your own logic matters.
• SDK — gathers what the instrumentation emits and enriches it with context: service name, version, environment, the propagated trace ID.
• Collector — a separate process, typically one per host or cluster, that receives the data and then filters (drop what you do not need), aggregates (reduce volume) and forwards it to one or several back ends.

The collector is the piece that earns the architecture its flexibility. Because applications send to the collector, they never need to know the target platform: swapping Jaeger for Tempo, adding a second destination, changing sampling rates or redacting a field are all configuration changes in one place, with no application redeploy. That indirection is precisely what makes "instrument once, send anywhere" true in practice rather than in principle.

Go deeper:

• OpenTelemetry Collector — receivers, processors and exporters: the three stages inside the collector.
• OpenTelemetry: Context propagation — how the SDK carries the trace ID across process boundaries.