Getting syslog from network devices into Graylog without losing or mangling events
Network and security teams need device logs in Graylog reliably, and the first decision is how those messages reach the cluster. Graylog's Syslog TCP and UDP inputs accept RFC 5424 and RFC 3164 messages directly from the device. The Syslog Kafka and AMQP pull inputs take a different route: the device writes to a broker you run, and Graylog pulls from it at its own pace. The syslog inputs documentation lists these four methods, and this section explains how to choose among them before any listener is opened.
The main trade-off is delivery guarantee against operational weight. UDP is simple to configure, but a datagram that is dropped in transit or while a node is busy is not retried by anyone. TCP gives the sender a connection to hold back on, which matters for firewalls and routers that emit bursts during an attack or a failover. Kafka or AMQP adds a buffer that survives a Graylog restart, but it also adds a broker to size, secure and monitor. Confirm with your network team whether each source can send TCP, whether it can send TLS on TCP, and how many events per second a single device can produce at peak.
Parsing is the second risk. Graylog expects RFC 5424 or RFC 3164 structure, and many routers and firewalls send messages that only approximate either format. The documentation recommends forwarding those sources through rsyslog or syslog-ng so the messages are normalized before Graylog parses them. Plan that relay as a separate component with its own configuration, monitoring and failover, and test a sample from each device model against the input before you point production traffic at it.
What you need before opening a syslog port
Syslog ingestion fails quietly when the pieces underneath it do not match: the Graylog version, its search backend, the network path from each device, and the edition behind each input. Work through these cards before you open a listener, because a mismatch found after devices are pointed at Graylog means lost or misparsed events.
Graylog version and backend pairing
Pick the Graylog release first, then confirm its MongoDB and search backend pairing in the compatibility matrix. Graylog 7.0 through 7.2 need MongoDB 7.x up to 8.2.x and support OpenSearch from 1.1.x up to 3.7.x, while Graylog Data Node is the recommended search backend. Confirm the pairing before installing, because OpenSearch 1.x use is deprecated and will be removed in Graylog 8.0.
Kafka broker version for Graylog 7.0
Graylog 7.0 moved the kafka-clients library to 4.x, so its Kafka inputs connect only to brokers at version 2.1 or newer. If you plan to buffer syslog through Kafka, check your broker version before upgrading or building the input, because an older cluster will fail to connect after the upgrade. Confirm the version with the team that runs the broker.
Network paths from devices to inputs
Each device must reach the Graylog node or load balancer address on the port your input listens on, for both TCP and UDP. Map every source, including routers, firewalls and servers, and check that firewalls between them allow the protocol you chose. Ask the network team to confirm routing and any NAT in the path, since source addresses seen by Graylog will be the translated ones.
Certificates for TLS on TCP
A Syslog TCP input can be secured with TLS, which means you need a server certificate, its private key and the CA chain that every sending device trusts. Plan issuance and renewal before go-live, and confirm that each device or relay can present a supported client configuration. Plain UDP offers no encryption, so state that trade-off in your design record.
Edition check for each input type
Graylog Open includes the core syslog listeners, but some inputs need an Enterprise license, and the Kafka and AMQP pull inputs should be checked against your license before you design around them. Build a table of every input you plan to use with its edition requirement, and confirm each entry against the current Graylog documentation rather than assuming a feature is included. Ask the licensing contact to confirm the result in writing.
Parsing and relay tooling for non-compliant devices
Graylog parses RFC 5424 and RFC 3164 syslog, but many routers and firewalls send messages that parse better after a relay such as rsyslog or syslog-ng. Sample real messages from each device model and check them against the expected format before choosing whether to relay. Assign an owner for the relay hosts, since they add a hop, a configuration to version and a host to patch.
TCP or UDP listener: which fits each device
Some routers, switches, appliances and older embedded devices can only send syslog over UDP. UDP is connectionless: the sender transmits each message without waiting for acknowledgment, so the device keeps running even when the collector is slow or unreachable, but messages can be lost in transit or dropped by the receiver under burst load. For these sources, a Graylog Syslog UDP input is the direct option, and the question is how to protect it rather than whether it works.
- Size the receiver for bursts: A short spike of events from one device can overflow socket buffers before Graylog reads them, so confirm the input's buffer settings and the host's kernel receive buffer limits.
- Keep the listener close to the source: Fewer network hops and fewer NAT or firewall devices in the path reduce the chance of silent drops.
- Accept that loss is possible: Plan for gaps in the record and document which sources are UDP-only so auditors understand the limit.
- Watch for parsing differences: UDP-only devices often send non-compliant messages, so confirm the device's message format before choosing a parser.
- Confirm the transport: Check the device's own documentation for supported transports, port numbers and whether it can be switched to TCP or TLS.
Before go-live, confirm each device's transport and message format in its own documentation, then compare event counts on the device with counts in Graylog over a known test period.
Many servers, firewalls and relays can send syslog over TCP, which adds connection state and acknowledgment at the transport layer. A TCP connection lets the sender detect a broken path and retry, and it avoids the size limits that UDP datagrams impose. Graylog offers a Syslog TCP input for this case. The trade-off is that a TCP listener must hold open connections, and a sender may block or buffer locally when the collector is unavailable, depending on its implementation.
- Use TCP for reliable transport: Prefer TCP when the device supports it and the path between sender and Graylog crosses networks you do not fully control.
- Plan connection limits: Each sending device holds at least one connection, so count sources before setting limits on the input and the load balancer.
- Decide on TLS: Plain TCP sends messages unencrypted, so confirm whether the sender supports TLS and whether the network path requires it.
- Check local buffering: Find out what the sender does during an outage, including whether it queues, drops or blocks.
- Consider a relay: When the device sends malformed syslog, a relay such as rsyslog or syslog-ng can normalize messages before forwarding them to Graylog.
Confirm with each vendor how its TCP sender behaves during an outage and whether TLS is available, since these details differ across products.
Some sources, such as firewall logs used for incident investigation or audit trails needed for evidence, cannot tolerate silent loss. Neither UDP nor TCP alone guarantees that every event reaches Graylog during a long outage, because the sender may discard events once its own buffer fills. For these sources, the design question is where events are held while the collector is down, not only which listener is open. Buffering through Kafka or AMQP pull inputs, covered elsewhere on this page, adds a durable queue between the source and Graylog.
- Define loss tolerance in writing: Agree with the security and compliance owners how much gap is acceptable and how gaps are reported.
- Find the sender's buffer: Confirm how much the device or relay can hold locally and for how long, and whether that buffer survives a restart.
- Add a durable intermediate queue: A message broker placed between the relay and Graylog keeps events while Graylog is unavailable, subject to its own retention and capacity.
- Monitor for gaps: Compare expected source counts with received counts and alert when a source goes quiet.
- Test failure modes: Stop the Graylog input during a controlled test and confirm what is recovered and what is lost.
Ask each source owner what its sender does during a collector outage, and record the answer with the event retention requirement it must meet.
Most environments mix these cases, and a single device rarely fits only one category. A common pattern is to use a relay host that receives UDP from legacy devices, normalizes the messages, and forwards them over TCP to Graylog. This keeps the fragile UDP leg short and local, and gives the platform team one place to adjust parsing. The cost is an additional component to build, patch, monitor and document, and the relay becomes a point of failure that needs its own availability plan.
- Keep the UDP leg short: Place the relay on the same network segment as the devices that send UDP.
- Assign ownership of the relay: Name who patches, configures and monitors it, since it sits in the log path for many sources.
- Separate listeners by source type: Use distinct ports or inputs for each class of source so parsing and routing stay predictable.
- Record the transport map: Keep a current table of each source, transport, port, format and owner for audit and troubleshooting.
- Review after changes: Revisit the map when devices are replaced or firmware is upgraded, since transport options can change.
Finally, confirm each device's transport and message format in its own documentation and update the transport map whenever a source is added or changed.
Configuring the syslog input and the first device
This sequence takes a Graylog syslog TCP or UDP input from planning to a verified message, so the team knows the device reaches the right node, the message parses, and it lands in the intended stream. Each step closes with a check the reader can repeat.
Confirm the node and network path
The Graylog administrator and the network team agree which Graylog server node will receive syslog, which IP address and port it listens on, and whether the source device can reach that address through any firewall or NAT in between. Confirm that the host firewall on the Graylog node allows the chosen protocol and port from the device's subnet. Done means the team can name the node, address, port and protocol in writing, and a basic connectivity test from the device subnet to that port succeeds or is scheduled with the network owner.
Choose TCP or UDP for the listener
Decide between the Syslog TCP and Syslog UDP inputs before creating anything. UDP is connectionless, so messages can be lost under load or during network interruptions, and the sender gets no delivery confirmation. TCP gives the sender a connection to hold, which suits devices that support it, and it is the usual choice when TLS is required. Confirm with each device vendor which transports and ports the device sends on, because some devices offer only UDP. Done means each source device has a recorded transport and port that matches the input you plan to create.
Create the syslog input on the chosen port
In the Graylog web interface, open System, Inputs, select the Syslog TCP or Syslog UDP input type, and launch it on the chosen port. Set the bind address and the port, and choose the node that will run the input. Ports below 1024 usually need extra privileges, so confirm the port choice against the node's operating system setup. Done means the input shows as running on the intended node in the input list, and the node's listening socket appears on the expected port when checked from the host.
Bind the input to the right node or interface
If the Graylog cluster has more than one node, decide which node should own the input and bind it to the address on the interface that the device subnet can reach. Avoid binding to all addresses when the node has interfaces on networks that should not receive syslog. Confirm the input appears as running on exactly one node and that the bind address matches the interface you planned. Done means the input status is running, the bound address is the one recorded in step one, and a port scan from an unexpected network does not show the listener.
Send a test message from one device
Pick one non-production device, or a test host configured to send syslog, and send a clearly labeled test message such as a unique string containing the date and the word test. Use the device's own logging test function where it exists. Keep the source to a single device so any problem traces back to one path. Done means the test message reaches the Graylog node, which you confirm by searching for the unique string in the search view over a recent time window.
Confirm parsing in search
Open the message from the search results and check the fields Graylog extracted, including the source, timestamp, facility, severity and message text. Compare them with what the device sent. Syslog from many routers and firewalls does not fully follow RFC 5424 or RFC 3164, so the timestamp, hostname or priority may be missing or wrong. If parsing is incomplete, note which fields are affected before deciding whether to fix the device format or relay the traffic through rsyslog or syslog-ng. Done means the expected fields are present with correct values, or a written list of the fields that do not parse.
Confirm stream routing
Create or select the stream intended for this source, with a rule that matches the source address or a field such as the hostname, and confirm the test message appears in that stream. Check that the message is not also landing in a catch-all stream by mistake. Done means the test message shows in the correct stream in the stream overview, and the stream rule matches only the sources it was designed for when you check it against a second message from another source.
How RFC 5424 and RFC 3164 messages parse differently
Graylog accepts both RFC 5424 and RFC 3164 syslog, but the two formats carry different fields, so the same device can produce very different results depending on which one it sends. RFC 5424 defines a structured header with a version number, a precise RFC 3339 timestamp, a hostname, an application name, a process ID, a message ID and optional structured data in brackets. RFC 3164, the older BSD-style format, uses a looser header with a short timestamp that has no year or time zone, followed by a hostname and a free-text message. Before you build streams or extractions, confirm for each source which format it emits, which timestamp it writes, and whether the hostname it sends is the device name or an address. Those three answers decide whether Graylog's message timestamp matches the event time and whether the source field is useful for searches and alerts.
Many routers and firewalls send syslog that is close to either format but breaks one of its rules, such as a missing or malformed priority value, an unexpected timestamp layout or structured data that is not properly bracketed. The Graylog syslog inputs documentation notes that such devices often parse better when their messages pass through rsyslog or syslog-ng first, which can normalize the header and forward a cleaner message to Graylog. Decide early whether each device model will send directly to a Graylog syslog listener or through a relay, because the relay adds a component to patch, monitor and size. The relay is most useful for devices with a fixed, known quirk. It is less useful when a vendor changes its output between firmware releases, so keep a record of the firmware version next to each sample.
Test with sample messages from each device model and each firmware branch you run before you rely on the parsed fields. Capture raw messages from the device or from a test listener, then check in Graylog whether the timestamp, source, severity and facility fields match what the device logged, and whether messages with unusual content still arrive intact. Confirm the time zone assumption for RFC 3164 sources, since the format carries no zone, and check that the device clock is synchronized with your time source. Keep the sample set in version control with the expected field values, so that a firmware upgrade or a relay configuration change can be re-tested in minutes rather than rediscovered during an incident.
Mapping syslog fields, Kafka topics and AMQP queues to Graylog
This table compares how each transport delivers identifying fields such as host, facility, severity, application name and message, and where the source name is set so it can route to an input and stream. Use it to decide which values to trust, then check every field name against your own sample messages and the Graylog syslog inputs documentation before writing stream rules.
| Source element | Syslog listener (TCP or UDP) | Kafka or AMQP pull input | What to confirm |
|---|---|---|---|
| Host or sender | Taken from the syslog header hostname, or from the sending IP address when the header is missing or malformed | Usually set by the producer in the message body or a message property; no header is guaranteed | Whether your devices send a hostname in the header and whether the sending IP is a reliable identifier |
| Facility and severity | Parsed from the PRI value in RFC 5424 and RFC 3164 messages | Present only if the producer serializes the PRI value or a separate field into the payload | Whether your devices emit PRI values and whether the Kafka or AMQP payload carries them |
| Application name | APP-NAME field in RFC 5424; the TAG portion in RFC 3164, which many devices format differently | Depends on the producer schema, often a JSON key you must map | Exact field names in your samples, since vendors vary in how they fill the tag |
| Message text | The MSG portion after the header; firewalls often place key-value pairs here | The payload or a named JSON field, depending on how the producer serializes it | Whether the message field is the full raw line or a shortened value |
| Source to input mapping | Each listener is a separate input on its own port, so devices are grouped by which port they send to | Each pull input reads one Kafka topic or AMQP queue, so the topic or queue name identifies the feed | Naming convention for topics and queues, and one input per feed where possible |
| Routing to streams | Stream rules match on fields such as source or facility after parsing | Stream rules match on fields the input adds or on fields in the payload | Whether the rule still matches when a device changes its hostname or tag format |
| Non-compliant messages | Fields may be missing or merged when a device breaks the RFC format, which is where relaying through rsyslog or syslog-ng helps | Less affected by framing, but the payload schema can still drift between producer versions | Sample a few messages from each device model before and after any firmware change |
Kafka or AMQP buffering versus a direct listener
A direct syslog listener is the simpler path, while a Kafka or AMQP pull input adds a buffer that can hold events while Graylog is busy or down. The cards below set out what that buffer buys, what it costs to run, and which version and runtime checks to make before committing to it.
Direct listener as the baseline
A Syslog TCP or UDP input receives events straight from the sender, so the path has no broker to install, patch or monitor. Without a queue, events that arrive while Graylog is unavailable depend on the sender and the network path to retain them. Check how long each source device buffers and whether it resends after a reconnect before accepting that risk for critical firewalls or servers.
Replay after a Graylog outage
With Syslog Kafka or AMQP pull inputs, Graylog reads events from a queue, so messages written during a maintenance window or outage can wait there until a node reads them again. Confirm the retention you configure on the broker or queue, since replay is limited to what the queue still holds. Test a stop and restart of Graylog against real topic or queue depth before relying on it.
Extra components to run
A Kafka or AMQP path adds a broker cluster, its storage, its certificates and its monitoring to the platform you operate, on top of Graylog, MongoDB and the Data Node. Ask who owns patching and capacity for that layer and whether it already exists in your environment. Count the added network paths between devices, relays and the broker when you plan firewall rules.
Kafka version floor for Graylog 7.0
Graylog 7.0 moved its kafka-clients library to 4.x, so its Kafka inputs can connect only to brokers at version 2.1 or newer. Older brokers therefore need an upgrade before the Graylog upgrade, not after it. Confirm your broker version and the Kafka release line you plan to run against the Graylog compatibility guidance before you schedule the change.
Java runtime for Kafka brokers
Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications require at least Java 11. Plan the Java runtime on broker hosts as a separate change from the Graylog server runtime. Verify the JDK your platform team supports before choosing a Kafka release line.
KRaft mode and upgrade path
Kafka 4.0 supports only KRaft mode, so a ZooKeeper-based cluster must migrate to KRaft before moving to 4.x. The upgrade notes also recommend that KRaft clusters older than 3.3.x move to 3.9.x first. Ask whether the existing queue is on a supported path, since this affects how far ahead the broker work must start.
Authentication and ACLs on the queue
Kafka supports SSL and SASL mechanisms such as SCRAM and GSSAPI, and security is optional, so a broker can run with unsecured listeners. In KRaft clusters, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Grant Graylog's principal read access to its topics explicitly and keep encryption on the network path between devices, relays and the broker.
Common syslog and queue failures and how to fix them
This table lists the failures teams most often hit when syslog, Kafka or AMQP feeds stop arriving or arrive unreadable in Graylog, with the likely cause and the first fix to try. Work down the rows in order, because a silent UDP drop or a wrong bind address can hide every later symptom. Confirm each fix against your own Graylog version and broker release before changing production inputs.
| Failure | Likely cause | Fix |
|---|---|---|
| Messages missing from UDP input | UDP has no delivery guarantee, so bursts overflow socket buffers or the sender drops packets silently | Move the source to TCP where the device supports it, or relay through rsyslog or syslog-ng with queueing, and check the input's receive buffer settings |
| Fields unparsed or messages landing as raw text | The device sends non-compliant RFC 3164 or vendor-specific syslog that the default parser does not match | Forward through rsyslog or syslog-ng to normalize the format, then confirm the parsed message fields in search before building extractors |
| Kafka input fails to connect on Graylog 7.0 | The kafka-clients library moved to 4.x, which connects only to brokers version 2.1 or newer | Upgrade brokers to a supported Kafka release before upgrading Graylog, or keep the older Graylog line until the brokers are current |
| Kafka or AMQP consumer gets authorization errors | The consumer principal has no read or group ACL, and KRaft resources without ACLs are restricted to super users by default | Grant the input's principal read on the topic and its consumer group, and confirm the ACL with a test consumer before editing Graylog |
| Listener starts but no traffic arrives | The listener is bound to a loopback or unintended interface address, or the host firewall blocks the port | Bind the listener to the interface that faces the devices, then test from a source host with a simple send and check the port is open end to end |
| Listener fails to start on a privileged port | The Graylog service user cannot bind a port below 1024 or another process already holds the port | Use an unused high port with a relay in front, or grant the needed capability, and confirm the port with a listening-socket check |
| Messages from one device stop after a restart | The device or relay reconnects with a new source address or TLS setting that the input does not accept | Review allowed sources and TLS settings on the input, and confirm the device's destination address and protocol after the restart |
| Backlog grows during traffic peaks | Downstream processing or the message journal cannot keep up with the ingest rate | Check journal utilization and processing throughput, then add capacity or buffer through Kafka or AMQP to absorb bursts |
Questions teams ask before syslog ingestion goes live
What drives the cost of setting up syslog ingestion in Graylog?
The biggest cost drivers are the number and type of sources, how many of them need relays, the volume of messages each one sends, and how much parsing and stream routing each log type needs. Graylog Open itself is free to download and use, but the infrastructure to run it (servers, MongoDB, a Data Node or OpenSearch cluster, load balancing and storage) is paid for separately. Some of that cost is one-time, such as the initial build and testing, and some recurs, such as storage, patching and support. Ask any provider for a written scope that lists each source, the input chosen for it, the parsing work, and the environments covered, then compare quotes against that same list.
How long does a typical syslog onboarding take?
Duration depends on how many devices are in scope, how many of them need a relay, whether the Graylog cluster already exists, and how quickly change windows and firewall rules are approved. Graylog's documentation does not give a single onboarding duration, so this page does not either. Ask for a written scope with milestones for each stage: design, cluster readiness, input build, device onboarding, validation and handover. A timeline that cannot be tied to those milestones is not a plan you can check.
What does our team need to provide before the work starts?
Plan to provide the following before any device is changed:
- Administrative access to each source device or a named contact who can make the change on it
- Network paths from each device or relay to the Graylog inputs, including firewall rules for TCP and UDP ports
- Change windows for routers and firewalls, because syslog configuration changes on production gear usually need approval
- A list of log types and retention needs so parsing and index sets can be designed
- Access to the Graylog and Kafka or AMQP environments where those are involved
Confirm the exact access model with your own change process before scheduling.
Can our internal engineers set this up without an outside partner?
Yes, if your team has the skills and time. Graylog's syslog inputs are configured in the web interface, and the main decisions are protocol choice, listener placement, parsing format and whether a relay is needed. The harder parts are usually the less visible ones: confirming how each device formats its syslog, sizing the cluster and message journal, planning index retention, and keeping configurations consistent across devices. Internal teams that already run Graylog and understand their device estate can often do this in-house. A partner is most useful when scope is large, the team is short on time, or an independent review of design choices is needed.
Which Graylog edition do I need for syslog and Kafka or AMQP inputs?
The Syslog TCP and UDP inputs, along with the Syslog Kafka and AMQP pull inputs, are documented in Graylog's syslog inputs guide, which is the page to check for each input's requirements. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and it covers the core ingestion and search features. Some capabilities depend on Graylog Enterprise or Graylog Security, such as certain inputs, correlation, and advanced operations features. Confirm the edition each input needs against the current documentation and the Graylog pricing page before you finalize the design, since requirements can change between releases.
Do I need rsyslog or syslog-ng in front of Graylog?
Often, yes. Graylog accepts and parses RFC 5424 and RFC 3164 syslog, but many routers and firewalls send syslog that does not follow either format closely enough to parse cleanly. Graylog's documentation notes that such devices parse better when forwarded through rsyslog or syslog-ng. A relay can normalize the messages, add a consistent header, and forward them to Graylog over TCP or UDP. Test a sample from each device type before deciding, because a device that already sends compliant messages does not need a relay.
How do relays and Kafka or AMQP queues change day-to-day operations?
Each relay, queue and broker becomes something you must monitor, patch, back up and secure. A relay adds a host with its own configuration, certificates and capacity limits. Kafka and AMQP inputs add a broker layer that buffers messages, which helps when Graylog is briefly unavailable, but it also adds retention settings, consumer lag to watch and authentication to manage. Kafka 4.x runs in KRaft mode only, requires Java 17 for brokers, and Graylog 7.0 Kafka inputs connect only to brokers version 2.1 or newer, so check versions before you choose this design. Include these components in your runbooks, monitoring and upgrade plan from the start.
What security questions should we settle before go-live?
Decide how syslog traffic is protected in transit and who is allowed to send to each listener. Plain UDP and TCP syslog carries no built-in encryption, so the path from a device to Graylog may need a secured design depending on your risk and network. If you use Kafka, it supports SSL/TLS encryption and SASL mechanisms such as SCRAM-SHA-256 and SCRAM-SHA-512. In KRaft clusters, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so confirm the ACL model before connecting Graylog. Review these choices with your security team and document them as part of the design.
How DeployOpen scopes a syslog integration
DeployOpen works in fixed-scope engagements, and the written scope defines the syslog work before anything is built. For this integration, the scope names every device family that will send logs, the input type chosen for each (Syslog TCP, Syslog UDP, Syslog Kafka or Syslog AMQP), any rsyslog or syslog-ng relays, the Kafka or AMQP queues and their access settings, the parsing expectations for RFC 5424 and RFC 3164 messages, and the tests that prove each source arrives and parses. Deliverables, timelines and acceptance criteria are agreed in the same document, so the scope can be reviewed by your security and network teams before a single listener is opened.
The device list is the most useful place to start. Ask your team to confirm, per device, the vendor, model, operating system version, transport it uses and whether its syslog output is documented as RFC-compliant. Devices that send non-compliant syslog usually need a relay, and that relay is a scoped item with its own configuration, testing and monitoring. If the Kafka or AMQP path is in scope, the scope should also record the broker or queue versions, the authentication method and who owns the topics or queues, because those settings affect what Graylog can connect to. Confirm current version requirements with the Graylog and Kafka documentation for your target releases.
DeployOpen does not publish prices. A quote follows from the written scope, so the more precisely your device list, queue choices and test expectations are defined, the more directly the quote reflects the work. When you request a quote, ask for the components listed separately (inputs, relays, queues, tests, documentation and handover), state which items are one-time and which recur, and confirm whether ongoing support or upgrades are covered by a retainer. Ask what changes the scope would trigger, such as adding device families later, so that the cost of growth is known in advance.
How DeployOpen works on this
DeployOpen scopes, builds, tests and hands over Graylog syslog ingestion from network devices, Kafka and AMQP inside infrastructure you control. Each engagement starts from a written scope that fixes the listeners, parsing approach, buffering path and acceptance tests before any configuration changes.
How we scope
- We inventory each router, firewall and server, noting its syslog format, transport and whether it sends RFC 5424 or RFC 3164 messages.
- We decide which sources reach Graylog directly and which pass through rsyslog or syslog-ng, and document the reason for each path.
- We agree in writing whether Kafka or AMQP pull inputs buffer any sources, and which broker versions and authentication methods the cluster uses.
How we build
- We configure Syslog TCP and UDP inputs, relay rules and Kafka or AMQP pull inputs in your Graylog environment, with ports and firewall rules agreed up front.
- We test each source with sample traffic, checking parsed fields, timestamps and stream routing against the scope before live traffic is switched on.
- We verify TLS and SASL settings on Kafka connections and confirm that the Kafka version matches the Graylog release you run.
How we hand over
- We deliver a source inventory, input configuration record, relay configuration files and a test log showing each device's parsed output.
- We document the runbook for adding a device, rotating credentials, changing a listener and recovering a stalled Kafka or AMQP consumer.
- We walk your platform, security and network teams through the configuration so they can run and change the pipeline without us.
How we support
- Engagements are fixed-scope, and any change outside the written scope is quoted separately before work begins.
- Ongoing support, upgrades and periodic testing of new sources are available as a retainer, scoped to your environment.
- Before any Graylog or Kafka upgrade, we check the documented version prerequisites and retest the affected inputs against your sources.
