Lexicon
OpenTelemetry Collector
The OpenTelemetry Collector receives, processes, and exports telemetry. How its receivers, processors, and exporters work, and where configurations go wrong.
Definition
The OpenTelemetry Collector is a standalone process that receives telemetry from applications and infrastructure, transforms it, and exports it to one or more destinations. It sits between the systems that produce logs, metrics, and traces and the backends that store them, acting as the control point for everything in transit.
What it means in observability
The Collector is where observability stops being a per-application concern and becomes a platform concern. Instead of configuring every service to enrich, filter, redact, and route its own telemetry, teams centralize those decisions in one place that the platform team owns. It is also the escape hatch from vendor agents: one vendor neutral process replaces the per-vendor daemons that observability platforms historically required, and switching backends becomes a configuration change rather than a redeployment across the estate.
How it works in practice
A Collector is assembled from three component types wired into pipelines. Receivers accept telemetry, whether pushed over OTLP or scraped from sources like Prometheus endpoints. Processors act on data in flight: batching, adding resource attributes, filtering noise, redacting sensitive values, or sampling traces. Exporters send the result onward to one or more backends. Each pipeline handles a single signal, and one Collector can run several pipelines at once. Deployment follows two broad patterns, an agent running on every host or node for local collection and a gateway tier for centralized processing, and many teams run both in sequence.
Where it gets hard
Collector configuration is powerful and unforgiving. A pipeline that drops data because of a misordered processor or a misspelled attribute fails silently: nothing errors, telemetry just goes missing. Resource sizing matters too, since an undersized gateway becomes a bottleneck for the whole organization's telemetry. And distributions add a quiet lock-in risk: several vendors ship their own Collector builds with proprietary components, which reintroduces the agent dependency the Collector was meant to remove.
Where Tsuga fits
Tsuga works with the stock upstream Collector, no vendor distribution required. Point a standard OTLP exporter at your Tsuga cluster's intake endpoint and everything flows. And because Tsuga runs inside your own cloud account, the Collector to backend hop stays on your network rather than crossing the public internet.
Related terms
- Infrastructure monitoringInfrastructure monitoring is the practice of tracking the health, performance, and capacity of the layer applications run on: hosts, virtual machines, containers, Kubernetes clusters, and managed cloud services.
- Kubernetes monitoringKubernetes monitoring is observability applied to Kubernetes clusters: the nodes, workloads, pods, and containers that run modern applications, plus the control plane that orchestrates them.
- Observability pipelineAn observability pipeline is the layer that moves telemetry from where it is produced to where it is stored, transforming it along the way: parsing, enriching, redacting, filtering, sampling, and routing to one or more destinations.
- OpenTelemetryOpenTelemetry is an open source framework for generating, collecting, and exporting telemetry: the logs, metrics, and traces that describe how software behaves in production.
- OTLPOTLP is the OpenTelemetry Protocol, the standard wire format for sending logs, metrics, and traces between the components of an OpenTelemetry pipeline.
- SamplingSampling is the practice of keeping only a subset of telemetry, usually traces, so that volume and cost stay manageable.
- Tail samplingTail sampling is a sampling strategy that makes the keep or discard decision after a trace completes, when its outcome is known.