# Alternatives to one central OpenTelemetry Collector: agents, gateways, or both? > Choose agent collectors for local access, gateway collectors for shared policy and export, or both when placement and processing requirements differ. Canonical URL: https://www.devobs.io/articles/central-otel-collector-alternatives-deployment/ By: Samira Haddad Published: 2024-05-31T02:22:57.012Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture Use host-local Collector agents for telemetry that requires local access, a gateway tier for shared policy and export, or both when those requirements coexist. Keep a single central Collector only when its failure and capacity limits are acceptable for the workload. The topology should follow the data and processing state rather than a preference for fewer processes. A central endpoint is easy to start with. As the system grows, it can become responsible for unrelated jobs: receiving application telemetry, reading local logs, enriching host metadata, applying shared policy, and exporting to several destinations. Those jobs do not all have the same placement requirements. ## Compare agent and gateway roles [OpenTelemetry's agent deployment pattern places a Collector alongside the application or on the same host, such as a sidecar or DaemonSet](https://opentelemetry.io/docs/collector/deploy/agent/). This is useful for local files, host context, and a nearby export destination for application emitters. The operating plan must account for distributing and updating that local configuration. [The gateway deployment pattern uses one or more Collector instances as a shared OTLP endpoint](https://opentelemetry.io/docs/collector/deploy/gateway/). It can centralize destination credentials and shared policy enforcement, for example filtering certain logs or sampling, as described in [OpenTelemetry's gateway trade-offs](https://opentelemetry.io/docs/collector/deploy/gateway/). A gateway pool also requires deliberate traffic routing; adding replicas is not a substitute for understanding stateful processing. [OpenTelemetry's gateway guidance](https://opentelemetry.io/docs/collector/deploy/gateway/) recommends a two-tier setup when telemetry must be processed by a specific Collector, such as routing by trace ID for tail sampling or by service name for accurate service-level aggregations. The combined pattern lets agents handle local collection while gateways own shared work. Choose it when both roles are present. Avoid duplicating every processor at both layers unless the duplicated behavior is intentional. ## Classify each receiver and processor List each input and what it needs to observe. A receiver reading a host file cannot collect that file from a remote machine merely because the gateway is reachable. Conversely, a cluster-wide receiver may duplicate data if several instances independently collect the same source. For each processor, determine whether it can handle records independently or relies on related data reaching the same instance. Verify the selected component's current documentation before designing sharding or load balancing. Stateful sampling and aggregation deserve particular attention. [OpenTelemetry's gateway documentation](https://opentelemetry.io/docs/collector/deploy/gateway/) also warns that OTLP metric data streams must have a single writer. In a multi-Collector gateway deployment, ensure metric streams keep a globally unique identity and avoid duplicate writers, or you can create gaps, jumps, or backend ingest errors. Define where attributes are added and where sensitive fields are removed. If the gateway expects an agent to provide host identity, test what happens when that attribute is absent or overwritten. Consistent metadata is part of the topology contract. ## Design the failure behavior Decide how much telemetry loss or delay is acceptable during a backend outage, collector restart, or network partition. Configure and test the actual queues, retry behavior, and storage options available in the selected distribution. Do not assume that using a Collector guarantees durable delivery. Monitor the collection system itself. [OpenTelemetry's gateway documentation](https://opentelemetry.io/docs/collector/deploy/gateway/) notes that the load-balancing exporter emits metrics including `otelcol_loadbalancer_num_backends` and `otelcol_loadbalancer_backend_latency`, which you can use to monitor the health and performance of the Collector serving the OTLP endpoint. In addition, monitor whatever accepted, refused, queued, and failed export metrics are exposed by the components you deploy, and arrange a diagnostic path that does not depend entirely on the failing pipeline. Run a load test with representative signal sizes and processing, then remove one gateway instance and interrupt a backend connection. Observe whether the result matches the intended loss and latency budget. Choose agents for local access, gateways for shared processing, and both when their responsibilities are distinct. Start by drawing each receiver and processor at the location where it can perform its job correctly. That diagram will show whether the central Collector should be replaced, replicated, or split into a more explicit topology. Research date: 2026-09-05. ## Source references - -