The OpenTelemetry Collector is the central point for receiving and distributing telemetry. This episode covers the receiver, processor, exporter, and extension architecture, agent and gateway deployment modes, popular components, and pipeline configuration best practices.

In episode 3 you got a brief introduction to the OpenTelemetry Collector. Now it's time to dissect it deeper, because the Collector is the central point of your telemetry architecture — receiving data from applications, processing it, then distributing it to Mimir, Loki, and Tempo.
This episode covers the Collector architecture consisting of receivers, processors, exporters, and extensions, agent and gateway deployment modes, popular components for each part, and best practices for building reliable pipelines.
Pipelines connect receivers, processors, and exporters in one flow:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch: {}
exporters:
otlp:
endpoint: tempo:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]The service.pipelines.traces block defines the trace flow: from the otlp receiver, through the batch processor, to the exporter toward Tempo.
In agent mode, the Collector runs on every node, receiving telemetry from local applications then sending it to a gateway or directly to the backend. Its advantage: it's close to the data source, making local scraping and relabeling easy.
In gateway mode, a centralized Collector receives data from many agents or applications. Its advantage: one point for heavy processing, smart sampling, and organizational policies.
A combination of the two is most common: an agent on each node for local collection, and a centralized gateway for aggregation and distribution to backends.
apps -> agent (per node) -> gateway (centralized) -> Tempo/Mimir/LokiThe agent (per node) -> gateway (centralized) pattern is the architecture you'll most often encounter in large-scale production.
processors:
batch:
send_batch_size: 10000
timeout: 10s
memory_limiter:
check_interval: 1s
limit_mib: 512The limit_mib: 512 configuration keeps the Collector's memory under control below 512 MiB.
Info
A rule of thumb: heavy processors — sampling, parsing, filtering — should run at the gateway, not the agent. Agents must stay lightweight so they don't add load to application nodes.
In episode 16 you understood the Collector architecture consisting of receivers, processors, exporters, and extensions, the agent, gateway, and hybrid deployment modes, popular components for each part, and best practices for building reliable and efficient pipelines.
The key takeaways:
In the next episode 17 we'll discuss advanced Grafana Alloy features — a comparison with the OTel Collector, deeper into the River language, discovery and relabeling components, and clustering mode for high availability. The two collectors you know will connect into a single collection strategy.