How the Graylog Forwarder gets remote-site logs to a central cluster
The Graylog Forwarder lets a team keep collecting logs at a branch office, plant or segmented network and deliver them to a central Graylog cluster over TLS. It runs local Syslog, Beats, GELF and raw inputs at the site, so devices and hosts send to a nearby listener, and the Forwarder then ships those messages to a Forwarder input on the cluster. The Forwarder is available only with Graylog Cloud, Graylog Security or Graylog Enterprise. It is not part of Graylog Open, so a team on the open edition needs a different transport or a licensed edition before this design is possible.
The design starts with a list of what each remote site sends and how each source reaches the Forwarder host. Confirm which edition and deployment model your organization holds, since the Forwarder is tied to those licenses rather than to the cluster itself. Then decide where the Forwarder runs. It needs a Linux or container-based system at the site, and it cannot be installed on Windows. Windows hosts at the site instead send through Graylog Sidecar, which manages their Beats collectors. Plan the local listener ports and protocols for each device type before the firewall rules are requested, because a site with segmented links often needs those rules approved by a separate network team.
Before go-live, verify the TLS path end to end. Confirm the certificate chain that the Forwarder input on the cluster presents, the trust store on each Forwarder host, and the outbound port the site firewall must allow. Test with a known message from each local input and confirm it appears in the expected stream on the central cluster. Also check what happens during a link outage: ask the team that operates the Forwarder how it buffers, what limits apply at the site, and how the central cluster is monitored for gaps. The Graylog Forwarder documentation is the reference for these settings and should be read against the version your cluster runs.
What you need before deploying the Forwarder
The Forwarder adds a remote tier between local log sources and the central cluster. Each card below is a prerequisite that must be settled at the central cluster and at every site before installation, since a gap in any one of them stops logs from arriving.
Confirm the Graylog edition
The Forwarder is available only with Graylog Cloud, Graylog Security or Graylog Enterprise. Graylog Open cannot use this path, so a self-managed Open deployment needs a license change or a different collection design before any site is wired up. Ask the vendor which license covers your planned site count and daily volume, and confirm that the cluster version in use supports the Forwarder input.
Forwarder input on the cluster
Each central cluster needs a Forwarder input that accepts traffic from the remote Forwarders. Decide which cluster node or load balancer address the sites will reach, and whether all sites share one input or each gets its own. Record the input's listening port and check it against your firewall and load balancer rules before any site configuration begins.
A Linux or container host per site
The Forwarder runs on Linux or a container-based system, and it cannot be installed on Windows. Each site needs a host with enough CPU, memory and disk to hold its local inputs and buffered messages during an outage. Windows machines at the site are not installed with the Forwarder; they send to it through Graylog Sidecar, so plan that path separately.
TLS certificates for the link
Traffic from each site to the cluster is sent over TLS, so you need certificates the Forwarder and the cluster input both trust. Decide who issues them, how the certificate chain is distributed to remote hosts, and how renewal will be scheduled across all sites. Confirm the certificate and key format the Forwarder documentation expects before requesting them.
Outbound network paths from each site
Every site must reach the cluster input over the network, usually outbound from the site through its firewall toward the central address. Map each site's source addresses, the destination port of the Forwarder input and any proxy or NAT in between. Confirm the exact ports and certificate requirements in the Forwarder documentation before opening rules, since a blocked path loses logs silently.
Local sources and their formats
The Forwarder accepts local Syslog, Beats, GELF and raw inputs at the site, so each device or service must send in one of those formats. List every source at each site, its protocol and its message volume, then check which local input it will use. Sources that send in an unsupported format need a relay or collector at the site before they can reach the Forwarder.
Configuring a Forwarder site step by step
This sequence takes a remote site from confirming the right Graylog edition to a verified path where local inputs send events through an encrypted Forwarder connection into the cluster and land in the stream you expect. Each step ends with a check so the team knows it is safe to move on.
Confirm the Graylog edition and licensing
Before any configuration, confirm that the cluster runs on Graylog Cloud, Graylog Security or Graylog Enterprise, since the Forwarder is not available with Graylog Open. Ask the Graylog administrator to check the license on the cluster and confirm the installed version against the current Graylog documentation, which covers version 7.2. Done means the license is active on the cluster and the team has written down the version it will target for the site.
Create the Forwarder input on the cluster with TLS
On the central cluster, an administrator creates the Forwarder input that will receive traffic from remote sites and enables TLS on it. Certificate issuance, trust chains and the hostname that remote sites will use should be agreed with the security team before the input is started. Done means the input shows as running in the System inputs view and a TLS client from the site host can complete a handshake with it, which you can confirm with a basic TLS connection test before any log data is sent.
Prepare the site host
Provision a Linux or container-based host at the remote site that will run the Forwarder, since the Forwarder cannot be installed on Windows. The host needs outbound network access to the cluster's Forwarder input port and must allow the local inputs to listen on the ports your devices use. Windows hosts at the site are handled separately through Graylog Sidecar. Done means the host can reach the cluster endpoint and the TLS test from the previous step succeeds from this host itself.
Define local inputs at the site
Decide which local inputs the site needs (Syslog, Beats, GELF or raw) based on the devices and agents that produce logs there, and configure each one on the Forwarder. Record the listening port, protocol and expected message format for every input so that source devices are pointed at the correct endpoint. Done means each input is listed on the Forwarder with its port and status, and the team has a table linking every log source to its input.
Point the site inputs at the cluster
Configure the Forwarder to send its received events to the Forwarder input on the cluster over TLS. Confirm the destination hostname, port and certificate trust settings match what was created on the cluster. Done means the Forwarder reports an active connection to the cluster and the cluster shows the Forwarder as a connected source, with no certificate or handshake errors in either system's logs.
Send test events from the site
Send a known test message from one device or test client at the site to each local input, using a distinctive marker string so it is easy to find. Keep a record of the source, input and time of each test so results can be matched. Done means every test message appears in the cluster search within the expected window and carries the fields your team expects from that input.
Verify stream routing and fields
In the cluster, search for the test markers and confirm that each event lands in the stream that matches its site or source, and that fields such as source, timestamp and message are populated as expected. If events land in the default stream, review the stream rules before routing live traffic. Done means each test event is in the intended stream with correct fields, and the team has signed off the routing before real logs are switched on.
Confirm TLS and connection health over time
After the test events pass, check that the TLS connection stays up under normal traffic and that the Forwarder's connection state and the cluster's input metrics remain stable. Record the connection status, the certificate expiry date and the owner responsible for renewal. Done means the connection has held through a monitored period, and the team has a documented owner and renewal date for the site certificate.
Choosing where Forwarder and Windows collection run
When the site has a Linux server or a container host with enough capacity and network access, the Forwarder can run there directly. It accepts Syslog, Beats, GELF and raw input traffic from local sources, then sends everything to a Forwarder input on the central cluster over TLS. This keeps the design close to what Graylog documents for remote sites and gives the team one component to patch and monitor at the branch.
- Single component at the site: The Forwarder is the only Graylog software the branch needs, so there is one service to update and one place to check when logs stop arriving.
- Local buffering of traffic: Local devices keep sending to a nearby host instead of across the WAN, which reduces the chance that a temporary link outage causes the sources to drop messages.
- Edition dependency: The Forwarder is available only with Graylog Cloud, Graylog Security or Graylog Enterprise, so confirm the license before planning the site.
- Host sizing and hardening: The host carries the inputs, so plan its CPU, memory, disk and operating system patching as part of the site build.
- Container option: Container-based systems are supported, which suits sites that already run a container platform.
Before committing, confirm the Forwarder's supported operating systems and container setup with Graylog's Forwarder documentation and check that the site host can reach the cluster's Forwarder input over TLS.
Some sites have only network devices such as routers, firewalls or switches, with no server that can host the Forwarder. In that case, the devices send syslog straight across the WAN to a central Graylog input, or to a relay the team manages. This avoids a site host but moves the entire transport path onto the network, so the design depends on the link and on the device's own sending behavior.
- No site host to maintain: Nothing needs to be installed at the branch, which simplifies hardware and patching for very small locations.
- Long-haul transport exposure: Devices typically send over UDP or TCP across the WAN, so outages and packet loss go directly into the central cluster's ingest path.
- Limited local buffering: Most devices have little or no queue of their own, so messages sent during an outage may be lost unless the design adds a buffer.
- Per-device configuration: Each device needs its own destination and format settings, which adds work when many branches share one design.
- Protocol choice: Ask the device vendor which syslog transport and format it supports before choosing between direct delivery and a relay.
Check the device documentation for queueing and retry behavior before relying on direct sending. Where the device cannot buffer, plan a relay host and confirm the approach against the Forwarder documentation.
The Forwarder cannot be installed on Windows. Windows servers and workstations at a remote site therefore send their event logs through Graylog Sidecar, which manages Winlogbeat or NXLog and points it at a Beats input. That input is reached through a Forwarder-capable host at the same site, so Windows collection depends on that host even though the Windows machines are not running Graylog components themselves.
- Dependency on a site Linux host: If the Linux or container host at the site is down, Windows events cannot reach the Forwarder, so this host is a single point of failure for Windows collection.
- Sidecar on each Windows host: Each Windows machine runs Sidecar, which needs a registration with the Graylog server and network access to it.
- Beats input placement: Confirm where the Beats input sits in the chain, on the site Forwarder or on the central cluster, because this decides which network paths must stay open.
- Central management: Collector configurations are pushed from Graylog, which keeps Windows settings consistent across branches.
- Capacity planning: Count Windows event volume per site before sizing the single Forwarder host that carries it.
Before deployment, confirm the Sidecar and Beats setup for Windows with the Forwarder documentation and check the Windows collection design with the team that will operate both the Windows and Linux components.
How Windows hosts feed the Forwarder through Sidecar
The Forwarder cannot be installed on Windows, so the Windows event sources at a remote site do not talk to it directly as an agent. Instead, the Windows hosts run a collector that Graylog Sidecar manages, and that collector sends events to a Beats or other input on the Forwarder at the site. The Forwarder then carries those events over TLS to the Forward input on the central cluster. The decision you face is whether every Windows host at the site will be enrolled in Sidecar, or whether some hosts will ship events through a different path. Sidecar gives you central control of collector configuration, but it also adds a management component that must be reachable from each Windows host and kept current.
Before you build this path, confirm the details against the Graylog documentation for the version you run, since Sidecar, Beats and the Forwarder each have their own configuration keys, supported operating system versions and input types. Check which Winlogbeat or Filebeat settings the Sidecar configuration uses, which port each collector sends to on the site Forwarder, and whether the Beats input on the Forwarder is set up to match. Confirm that your Sidecar and Forwarder versions are compatible with each other and with the cluster, and record those answers in the design before rollout starts.
Plan the network path for each Windows host in the same review. Each host needs a route to the site Forwarder on the port the Beats input listens on, and the Forwarder needs outbound reach to the cluster for its TLS connection. Ask your network team which segments sit between the Windows hosts and the Forwarder, and whether a firewall or proxy inspects the traffic. Test one host end to end, from a Windows event to a search result on the central cluster, before you enroll the rest of the site, so that any gap in the path shows up on one machine instead of across the whole fleet.
Which site inputs map to which cluster inputs and streams
This table maps each site input type (Syslog, Beats, GELF and raw) to the sources it usually serves, the Forwarder input on the cluster that receives it, and the stream or index set where events are expected to land. Read each row as a starting design to confirm with your own sample events, because field handling and parsing depend on how each device or agent formats its output.
| Site input | Typical sources at the site | Cluster-side landing point to confirm | Field and parsing checks |
|---|---|---|---|
| Syslog | Firewalls, switches, routers and other network devices that send syslog | Forwarder input on the cluster, routed to a stream chosen for network events | Confirm the syslog format each device emits, and whether timestamps and hostnames survive the hop unchanged |
| Beats | Filebeat or Winlogbeat agents on local servers, or agents managed through Sidecar | Forwarder input on the cluster, routed to a stream for host or endpoint logs | Confirm Beats field prefixes and any processing added at the site before events leave the network |
| GELF | Applications or services that already send structured GELF messages | Forwarder input on the cluster, routed to a stream for application logs | Confirm required GELF fields such as host and short message, and how custom fields are named |
| Raw | Plain text logs from appliances or applications with no structured format | Forwarder input on the cluster, routed to a stream that matches the source owner | Confirm that parsing rules exist for each log layout, since raw events arrive unstructured |
| Index set choice | All of the above, depending on retention and access needs | Index set chosen per stream, not per input type | Ask whether remote-site events need a different retention period from local events before you assign index sets |
| Routing rules | Mixed traffic from one site that serves several teams | Stream rules on the cluster that separate sources after they arrive | Test with sample events from each device class to confirm each message reaches the intended stream |
Securing the link from remote sites to the cluster
A Forwarder site sits outside the data center and sends logs across networks you do not fully control. The controls below cover the path from each remote input to the cluster's Forwarder input, and the local inputs that receive traffic at the site. Confirm each setting against the Forwarder docs for your Graylog version before you rely on it.
TLS on the Forwarder connection
The Forwarder sends logs to a Forwarder input on the cluster over TLS, so the traffic leaving each site is encrypted in transit. Confirm in the Forwarder docs which TLS options the Forwarder input exposes, including whether the cluster requires a certificate from the site and which protocol versions and cipher settings you can set. Test the handshake from a site host before cutover, because a silent fallback or a misconfigured chain shows up as dropped logs rather than as an error on the site.
Certificate issuance and rotation
Decide who issues the certificates, which certificate authority signs them, and how long they last. Use a private CA your team controls where possible, and keep the cluster certificate and any client certificates in the same inventory. Plan rotation as a routine task with a tested procedure, since an expired certificate on the cluster stops every site at once. Ask the Forwarder docs how to reload certificates without a full restart of the cluster nodes.
Restricting which site hosts can connect
Limit the Forwarder input to the source addresses of known site Forwarders, not the whole branch network. Pair network allow lists with client certificate checks where the Forwarder supports them, so a compromised workstation on the same subnet cannot submit events. Record which Forwarder instance owns each address range so that a retired site can be cut off without touching other sites.
Limiting inbound ports at the cluster
Open only the port the Forwarder input listens on, and only from the site networks or the VPN or private links that carry the traffic. Keep the Graylog web interface and API on separate, more restricted paths, and confirm that the load balancer in front of the cluster forwards the Forwarder port without exposing it to the internet. Review the firewall rules after every new site is added.
Protecting local inputs from untrusted segments
Syslog, Beats, GELF and raw inputs at a site accept data from any host that can reach them, so put them on a management or log VLAN and bind them to interfaces that only site sources use. Disable inputs the site does not need, and check whether each input can be restricted to specific source addresses. Treat a plant or shared office network as untrusted by default, because devices there often cannot be patched quickly.
Access control on the Graylog side
Inside Graylog, decide which roles can view logs from each site, and use streams to separate site data so an operator for one branch does not see another branch's events. Restrict who can create or edit Forwarder inputs, since changing an input changes what the cluster accepts. Audit input changes and certificate work in your change records, and confirm which of these actions your Graylog edition logs.
Why remote-site logs stop arriving at the cluster
This table lists the failures that most often stop logs from a remote site reaching the central Graylog cluster, with the likely cause and the fix for each. Read it top to bottom when logs stop arriving, or use it as a checklist before go-live to confirm the edition, trust chain, network paths and local listeners are in place.
| Symptom or failure | Likely cause | Fix |
|---|---|---|
| Forwarder option missing in Graylog | The Forwarder is only available with Graylog Cloud, Graylog Security or Graylog Enterprise, so the deployment is on Graylog Open | Confirm the edition and license with Graylog before design, or plan a licensed edition for the remote-site path |
| Forwarder input on the cluster never receives data | No Forwarder input is created on the central cluster, or the site Forwarder points at the wrong host or port | Create the Forwarder input on the cluster first, then match host, port and TLS settings in the site Forwarder configuration |
| TLS handshake fails between site and cluster | The certificate is not trusted by the site Forwarder, or the certificate name does not match the host name the site connects to | Install the issuing CA chain on the site host, and issue the cluster certificate with a subject or SAN that matches the address the Forwarder uses |
| Outbound connection from the site is blocked | Firewalls or proxies at the site or on the path do not allow outbound traffic to the Forwarder input port | Open the agreed port from the site to the cluster or load balancer, and confirm with the network team that return traffic is permitted |
| Local inputs accept nothing | Syslog, Beats, GELF or raw inputs at the site are bound to the wrong interface, or devices send to a port the input does not listen on | Check the listening address and port on the site Forwarder, confirm the device target, and test with a single known-good sender |
| Windows hosts send nothing to the site Forwarder | The Forwarder cannot run on Windows, and Sidecar or the Beats input path is not reaching the site Forwarder | Install Sidecar on the Windows host, point its Beats output at the site Forwarder listener, and verify the port is open between them |
| Gaps appear after the link drops | The site Forwarder cannot hold logs while the WAN link is down beyond what its local buffering allows, so events are lost or delayed | Size local buffering for the expected outage, monitor the link, and confirm with Graylog how the Forwarder handles backlog and resumption in your version |
Questions buyers ask about Forwarder deployments
Which Graylog edition do I need to run the Forwarder?
The Graylog Forwarder is available only with Graylog Cloud, Graylog Security or Graylog Enterprise, so Graylog Open alone does not include it. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Confirm the current terms with Graylog before you commit, because the license is the first cost decision and it sets which inputs you can use at each site.
What drives the cost of a Forwarder rollout?
The main drivers are the number of sites, how many local inputs each site needs, the network and firewall work to reach the cluster over TLS, and the certificate work. Windows scope also adds effort, because the Forwarder cannot run on Windows and Windows hosts must reach it through Graylog Sidecar. Your cost comes from planning, site configuration, testing and handover, and it is one-time for the initial build with recurring support only if you buy a retainer. Ask for a written scope that lists each site, each input type and each network path, so the quote matches the work.
How long does a site rollout take?
The duration depends on the number of sites, how fast each site can give network access and change rules, and whether certificates are already issued and trusted. A single site with clear access and an existing certificate process moves much faster than several sites that each need firewall change requests. DeployOpen agrees timelines in the written scope before work starts, so ask for a schedule that shows site access dependencies, change windows and the testing that closes each site.
What does our internal team need to provide?
Most delays come from missing inputs, so prepare these before the engagement starts:
- Network access from each remote site to the Graylog cluster's Forwarder input, and the firewall change process for it
- A certificate authority or approved certificate process that can issue the server certificates the TLS connection needs
- A Linux or container host at each site to run the Forwarder and its local inputs
- Sample logs from each source type, so parsing and routing can be tested before go-live
- Named contacts for network, security and site operations who can approve changes
Can our own team deploy the Forwarder without outside help?
Yes, if your team already runs Linux or container hosts, manages certificates and can operate a Graylog cluster. The Forwarder setup itself is a configuration task: local inputs at the site, a Forwarder input on the cluster, and a TLS connection between them. The harder parts are usually the network paths, certificate lifecycle and testing across sites. An outside partner adds the most value when you have many sites, limited staff or strict change control. Compare the internal effort with the written scope before you decide.
How do Windows hosts at a remote site send logs?
Windows hosts cannot run the Forwarder, so they send logs to a Linux or container host at the site that runs the Forwarder's local inputs. Graylog Sidecar manages the collector on each Windows host, including the Beats configuration that ships logs to that site host. Plan the Windows scope separately, because each host needs its collector installed, a Sidecar configuration assigned and a network path to the local input. Confirm the Sidecar and Beats steps with the Graylog documentation for your version before you build the rollout plan.
What should we check when logs stop arriving from a site?
Check the path in order: the local input at the site, the Forwarder process on its host, the TLS connection to the Forwarder input on the cluster, and then the stream and index rules on the Graylog side. Look for expired certificates, blocked ports after a firewall change, and local buffers that fill when the link drops. Set an alert on each site so silence is noticed quickly, and record the expected source list for each site so a missing source is easy to spot. Ask for these checks in the runbook as part of the handover.
How DeployOpen scopes and delivers Forwarder rollouts
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Graylog Forwarder, we start from the sites, edition and network paths you have, then deliver a fixed-scope rollout with written deliverables, verification and handover to your team.
How we scope
- Inventory each remote site, its log sources and the input types needed locally, such as Syslog, Beats, GELF or raw.
- Confirm the Graylog edition covers the Forwarder, since it requires Cloud, Security or Enterprise.
- Agree in writing which Forwarder hosts, Windows Sidecar hosts and cluster inputs are in scope.
How we build
- Install and configure Forwarder hosts on the Linux or container systems you approve at each site.
- Configure TLS from each Forwarder to the Forwarder input on the central cluster, with certificate handling agreed up front.
- Set up Sidecar with Beats for Windows hosts, and test log delivery from each site end to end.
How we hand over
- Document each site's configuration, network paths, inputs, certificates and firewall rules.
- Provide runbooks for adding a site, rotating certificates and recovering a failed Forwarder.
- Walk your operations team through the setup and confirm they can run it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Forwarder and Graylog version changes against the documented upgrade prerequisites before they reach production.
- Confirm current edition, licensing and version details with Graylog and your own environment before each change.
