OpenTelemetryCollector
title: OpenTelemetry Collector type: tool created: 2026-05-21 last_updated: 2026-05-21 related: ["radar/techniques/OpenTelemetryGitPerformance", "radar/techniques/ServiceLevelObjectives"] sources: ["https://dev.to/nfrankel/exploring-the-opentelemetry-collector-ldc"] radar_quadrant: Tools radar_ring: Assess radar_position: inner
A vendor-agnostic telemetry pipeline that receives, processes, and exports traces, metrics, and logs from instrumented services to one or more observability backends.
OpenTelemetry provides two ways to export telemetry: direct export from the SDK to a backend (e.g., Jaeger, Prometheus, Datadog), or export to a Collector which then forwards to backends. The Collector decouples instrumented services from backend choices.
Without the Collector, changing observability backends requires updating every service. With the Collector, backend changes are configuration updates in one place.
The Collector uses a pipeline model with three component types:
| Component | Role |
|---|---|
| Receivers | Accept telemetry in various formats (OTLP, Jaeger, Zipkin, Prometheus scrape, Syslog) |
| Processors | Transform data in flight (filter, batch, add/remove attributes, sample) |
| Exporters | Forward to backends (Jaeger, Prometheus, Datadog, Grafana, S3, stdout) |
Multiple pipelines can run simultaneously — traces to Jaeger, metrics to Prometheus, logs to Loki — all configured in a single YAML file.
Agent mode: A Collector instance runs on each host or as a sidecar, collecting local telemetry and forwarding to a central Collector or backend directly.
Gateway mode: A central Collector cluster receives telemetry from all agents, applies organisation-wide processing (PII scrubbing, sampling, enrichment), and fans out to backends.
For small deployments, a single Collector in gateway mode handles both roles.
- Batch processor: Groups spans and metrics into batches before export, reducing network overhead.
- Attributes processor: Adds, modifies, or removes attributes on spans and metrics (e.g., adding environment tags).
- Filter processor: Drops telemetry matching specific criteria (e.g., health check spans).
- Tail sampling processor: Makes sampling decisions after seeing a full trace, enabling error-biased sampling.
The radar/techniques/OpenTelemetryGitPerformance blip describes instrumenting Git operations with OTel. The Collector is the natural receiver for that telemetry — GIT_TRACE2 events exported as OTLP spans would flow through a Collector before reaching a Jaeger or Grafana Tempo backend.
OpenTelemetry Collector sits in the Assess ring of the Tools quadrant, at inner position. First studied via the DEV Community article by Nicolas Frankel (2023-11-16). The Collector is a CNCF graduated project and the standard deployment pattern for OpenTelemetry at scale. That standing is third-party reputation, not first-person use: no Collector has been deployed here, and the Trial gate requires that, so it stays at Assess. Inner position reflects a Docker Compose deployment path (single container, YAML config), direct applicability to any service already emitting OTel traces, and strong backend flexibility. The gate to Trial is a completed Collector deployment routing telemetry from at least one active service to an observability backend.
