Collector Architecture and Configuration
The Collector is a vendor-neutral binary that receives, processes, and exports telemetry. Its config is a YAML file organized by pipelines, each composed of three component types: receivers (ingress, e.g., OTLP, Prometheus, filelog), processors (transform/filter/batch/memory-limit), and exporters (egress to a backend or another collector). A pipeline is defined per signal: service.pipelines.traces lists its receivers, processors, and exporters.
Critical rules: a component must be defined in its top-level section (receivers/processors/exporters) and referenced in a pipeline. A receiver can feed multiple pipelines, but an exporter typically receives from the pipeline it's listed in. Processors run in the order listed. The batch processor should generally be last among processors (right before export) to batch effectively. The memory_limiter should be first to protect the collector from OOM. Connectors join pipelines (e.g., spanmetrics turns spans into metrics).
Deployment modes: agent (per-host/sidecar, close to the source) vs. gateway (centralized, aggregation, routing). A common pattern is agent → gateway → backend. Understand fan-out (one receiver to many pipelines) and routing (e.g., routing connector or filter processor).
Traps: referencing an undefined component (collector fails to start); wrong processor order; assuming one pipeline serves all signals; confusing service.pipelines (wiring) with top-level component definitions (declarations).
Rule of thumb: memory_limiter first, batch last, and every referenced component must be declared.
Worked example: To send OTLP traces to two backends, define both exporters and list both in the traces pipeline - the collector fans out to both.