Applications can produce logs, measurements and request traces in different places and formats. OpenTelemetry Collector receives those signals, applies configured processing and forwards them to selected monitoring backends. It gives teams a common place to control routing, filtering and export instead of embedding every backend connection in each application. Collectors can run near workloads or as shared gateways; that choice affects which data they can collect and how failures, buffering and duplicate collection must be handled.
Its Helm chart can support agent or gateway arrangements; the right topology depends on which receiver needs node-local files, host information or cluster-wide access.
Choose one owner for each signal
Node-local file logs commonly belong to an agent on each node. Shared ingress, filtering and export can belong to a gateway tier. Cluster-level collection needs deliberate replication and ownership so several collectors do not emit the same observations. Presets are a starting configuration, not a complete data architecture.
Failure behavior
Budget memory and queue capacity. Decide what happens when the backend is slow, credentials expire or collectors restart. Test whether the expected telemetry is lost, delayed or duplicated, and observe the collector's own health independently of the backend it is sending to.
The Collector guide covers signal paths, duplication and rollout checks. This page describes upstream capabilities, not a measured throughput result.
Sources & further reading
Spotted something that needs another look?
Help improve this page →