> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/production-checklist/bindplane-otel-collector/edge-collectors-v.-gateways.md).
# Edge Collectors v. Gateways
Learn when and why to send telemetry from edge collectors through gateways, and how to architect gateways for production environments.
A collector can run as either an edge collector or a gateway collector. An edge collector sits on the same host, container, or node as the workload it monitors. A gateway collector is a standalone collector that receives telemetry from edge collectors, processes it, and forwards it to your destinations. Both use the same binary – the only difference is where they deploy and how they're configured.
These two roles match the deployment patterns described in the OpenTelemetry documentation. An edge collector is what OpenTelemetry calls the [agent deployment pattern](https://opentelemetry.io/docs/collector/deploy/agent/), and a gateway collector follows the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). In Bindplane, a [Gateway](/core-concepts/gateways.md) is a named group of gateway collectors that you create and manage as a resource.
For most production deployments, sending telemetry from edge collectors through a Gateway is the recommended architecture. This guide covers when gateways are the right choice, when you can skip them, how to size and scale them, and the architecture patterns that fit common deployment scenarios.
## When to Use Gateways
Gateways solve three problems that come up in most production environments.
* **Credential isolation.** Without gateways, every server that sends telemetry needs credentials to your destination, whether that's Google SecOps, Splunk, Datadog, or anything else. With gateways, only a small number of gateway collectors hold those credentials. If you have 1,000 servers, you may not want all 1,000 to need API keys for your SIEM.
* **Network traffic control.** Gateways let you funnel outbound traffic through a controlled point in your network. Many environments restrict which machines can make outbound internet requests. Rather than opening direct egress for every host, route telemetry through gateways that sit in a DMZ or a network zone with permitted outbound access.
* **Offloading processing.** Filtering, parsing, sampling, and enrichment all consume CPU and memory, and running that work on the same host as your application can starve your workload. Gateway collectors run on dedicated, well-provisioned machines built specifically for this job. Move heavy processing to gateways so your edge collectors stay lightweight.
There are secondary benefits as well. Gateways batch telemetry into fewer, larger API requests, which can help stay within rate limits and reduce overhead on your destinations. They also give you a single, centralized place to change destinations, add processors, or adjust routing without touching every edge collector in your fleet.
## When You Can Skip Gateways
Gateways add infrastructure, and infrastructure isn't free. There are cases where sending telemetry directly from edge collectors to your destination is a reasonable choice:
* **Small or simple environments.** If you have a handful of servers, minimal processing needs, and your edge collectors can reach your destination directly, a gateway may add complexity without meaningful benefit.
* **Cloud-native sources already flowing to your destination.** If you're already ingesting data into your destination through a managed service (for example, a SaaS integration or cloud-native pipeline) and don't need additional processing, filtering, or multi-destination routing, there may not be a reason to insert a gateway into that path.
* **Infrastructure cost outweighs the benefit.** At scale, the cost of running gateway infrastructure can be significant. If your telemetry doesn't require processing, credential isolation, or network control, and your destination can handle direct ingest from your edge collectors, the infrastructure savings may be worth the trade-off.
That said, the problems gateways solve (credential sprawl, egress costs, processing overhead) tend to emerge gradually and become harder to address retroactively. It's worth revisiting the decision as your environment scales.
## Setting Up Gateways in Bindplane
Adding a Gateway to an existing Bindplane deployment takes three steps. See [Gateways](/core-concepts/gateways.md) for the full walkthrough and CLI options.
1. **Create a Gateway.** Select **Gateways** in the navigation, choose a deployment method (**Kubernetes** or **Load Balanced VMs**), name the Gateway, and select **Create Gateway**.
2. **Finish the setup checklist.** On the Gateway's page, provision your gateway infrastructure, install gateway collectors, enter the hostname edge collectors use to reach the Gateway (usually the load balancer's address), and publish a configuration with the **Gateway** role. The gateway configuration uses a [Bindplane Gateway source](/integrations/sources/bindplane-gateway.md), which listens for OTLP traffic on ports 4317 (gRPC) and 4318 (HTTP) by default. Add your destinations and any processors you want to run centrally. This is where you move processing that was previously running on your edge collectors.
3. **Point edge collectors to the Gateway.** Update your edge configurations to replace their current destinations with a [Bindplane Gateway destination](/integrations/destinations/bindplane-gateway.md) that points to the Gateway's hostname, then roll them out.
## Sizing and Scaling Considerations
For specific resource requirements and throughput tables for both edge and gateway collectors, see the [Sizing and Scaling](/production-checklist/bindplane-otel-collector/sizing-and-scaling.md) documentation.
When planning your gateway fleet, size for both failure and maintenance. If one gateway collector goes down or is taken offline for an upgrade, the remaining gateway collectors need enough capacity to handle the full load. Your network architecture also affects how many gateways you need. If your servers are spread across multiple cloud providers or data centers, you will need gateways in each environment. Deploy them close to the sources they serve to minimize latency and reduce egress costs.
If a gateway is struggling under load, adding another node is often more effective than increasing the instance size. Vertical scaling can hit diminishing returns where additional CPU and memory don't translate to higher throughput. That said, vertical scaling can still help when you're working with a fixed number of collectors.
Most gateway operations are stateless, which makes auto-scaling straightforward. Place your gateway collectors behind a load balancer and scale the group based on CPU, memory, and network I/O. For details on health checks, internal collector metrics, and scaling configuration, see the [High Availability](/production-checklist/bindplane-otel-collector/high-availability.md) documentation.
## Architecture Patterns
A single gateway collector is the simplest setup. Edge collectors export to one gateway collector, which handles processing and forwards telemetry to your destinations. This works for small environments but offers no redundancy.
For production, use two or more gateway collectors behind a load balancer. If a node fails, the load balancer routes traffic to the remaining nodes automatically.
As your environment grows, you may want to split telemetry across multiple Gateways. Common approaches include segmenting by region or data center (to reduce egress costs and latency), by application or team (to simplify processing rules and enable chargeback), or by telemetry type (to tune scaling for each signal independently). These patterns can be combined. A large enterprise might have Gateways segmented by region, with separate pipelines per telemetry type within each Gateway.
## Additional Considerations
### Push vs. Pull Sources on Gateways
In addition to receiving forwarded telemetry from edge collectors, gateway collectors may also collect directly from push-based sources like syslog or firewall logs on the same nodes. However, adding pull-based sources to a Gateway requires more care. With a push-based source, the sender decides which gateway collector to hit. With a pull-based source, every gateway collector independently reaches out to collect data. If you add an API-based source to a Gateway with five collectors, each one may pull from that API independently, which could result in duplicate data.
Before adding any pull-based source to a Gateway, verify that it supports being consumed by multiple collectors simultaneously without duplication.
### Publicly Exposed Gateways
If you're collecting telemetry from endpoints that go on and off your corporate network, such as employee laptops, you may need gateways that are publicly accessible. This allows edge collectors to fail over to an external gateway when they're off-network rather than queuing data locally with no guarantee of delivery.
This introduces standard concerns around securing a public-facing service: authentication (the collector supports mTLS for certificate-based validation), DDoS protection, and appropriate load balancing. Every cloud provider offers tools for this, but specific recommendations will depend on your network and security requirements.
### Further Reading
* [Gateways](/core-concepts/gateways.md)
* [Sizing and Scaling](/production-checklist/bindplane-otel-collector/sizing-and-scaling.md)
* [High Availability](/production-checklist/bindplane-otel-collector/high-availability.md)
* [Gateway Source](/integrations/sources/bindplane-gateway.md)
* [Gateway Destination](/integrations/destinations/bindplane-gateway.md)
* [GKE Gateway Load Balancer Guide](/how-to-guides/cloud-and-platform-integrations/kubernetes/google-kubernetes-engine-gateway-collector-load-balancer.md)
* OpenTelemetry: [Agent deployment pattern](https://opentelemetry.io/docs/collector/deploy/agent/) and [Gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.bindplane.com/production-checklist/bindplane-otel-collector/edge-collectors-v.-gateways.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
