Routers, firewalls, switches, and load balancers have been emitting syslog for decades, well before the structured APIs we reach for today. It is universal, fire-and-forget, and already built into every major device vendor, so once a fleet of network gear is logging, syslog is the common denominator no matter how many other data channels you add. Getting that intake right, rather than bolting it on, is the point of the Syslog Best Practices use case. Cribl Stream processes the syslog stream directly, and doing so replaces the syslog-ng or rsyslog servers that traditionally sat between the senders and the SIEM.
The Syslog source, configured
The Syslog Source receives syslog over UDP or TCP and parses each message into structured fields, or keeps it raw when it does not recognize the format. It understands both RFC 3164 and RFC 5424 structured data, including timestamps, facility codes, severities, and the message content. It also handles the message-length prefixes from RFC 5425 and RFC 6587 so that larger messages arrive intact.
You do not start from scratch. Cribl Stream ships with a Syslog Source already listening for both UDP and TCP traffic on port 9514. Clone that Source or modify it directly, then enable it. For devices hard-coded to send to port 514, the built-in default Source can forward that traffic; keep in mind, as the docs note, that traffic on port 514 is unencrypted, so enable it only if you accept that risk. The General and TLS settings below are taken directly from the Source's configuration reference, with the defaults as documented.
Syslog Source (Push) TLS Support: YES
General Settings
Input ID unique name, default "in_syslog_default"
Description optional
Address hostname/IP to listen on, e.g. 0.0.0.0 or localhost
UDP port UDP port to listen on (not required if listening on TCP)
TCP port TCP port to listen on (not required if listening on UDP)
max inbound UDP message size 16,384 bytes
TLS Settings (TCP only)
Enabled default off
Certificate name of the predefined certificate
Certificate path server path to PEM certificate
Private key path server path to PEM private key
Passphrase passphrase to decrypt the private key
Authenticate client mutual auth, require client certs (default off)
Trusted client CA path server path to CA certs for validating clients
Common name regex the peer cert must match (default .*)
Minimum TLS version lowest TLS version to accept
Maximum TLS version highest TLS version to acceptBecause the TLS section is TCP only, encryption is a decision you make about the transport. For the UDP path, the reference points out that the default kernel receive buffer is usually far too small for a busy syslog server, and shows how to check it and raise it. The two monitoring commands and the permanent change below are reproduced from that same page.
# check the current buffer size
$ sysctl net.core.rmem_max
# check UDP health; watch the "packet receive errors" line
$ netstat -su
# make the change permanent in /etc/sysctl.conf
net.core.rmem_max=26214400
net.core.rmem_default=26214400Parsed, a compliant message yields a small set of predictable fields: _time, appname, facility and facilityName as a numeric/text pair, host, the message, and severity with severityName. If a message matches neither RFC, you get the raw line under _raw along with _time, host, and a __syslogFail flag. Knowing which fields will be present is exactly what the routing in the next section relies on.
Routing by device
The best-practices page recommends two complementary moves. First, create a dedicated Syslog Source for each vendor or class of sender, each on its own port. The doc's examples use Input IDs such as in_syslog_cisco_switch for Cisco switches and in_syslog_f5 for F5 load balancers, and it attaches sender-specific metadata like sourcetype, index, and __timezone to each Source so the data is labeled at ingest.
When a single Source does have to accept a mixed stream, the page's answer is Routes that split it into subsets. Its worked example is a router tagged sourcetype myrouter carrying a blend of DHCP activity, login and authentication attempts, and firewall traffic. The Route filters below are copied from the use case, and each one feeds its own Pipeline.
# Route filters from the Syslog Best Practices use case
myrouter-dhcp sourcetype=='myrouter' && raw.match('dhcpd3:')
myrouter-auth sourcetype=='myrouter' && raw.match('login')
myrouter-fw-traffic sourcetype=='myrouter' && raw.match('TRAFFIC')
myrouter-other sourcetype=='myrouter'The last Route, myrouter-other, is the catch-all and is pointed at a Pipeline that drops the noise rather than storing it. The page keeps a dedicated Pipeline (and Route) for each distinct subset and adds a final Route that matches the general sourcetype, so nothing falls through. Parsed syslog fields such as facility, severity, host, and app name are available for matching the same way if your datasets key off those instead of a string in the message.
Cloud and network considerations
Pointing at Cribl.Cloud changes the transport decision. The Syslog TLS to Cribl.Cloud guide walks through forwarding syslog to your Cribl.Cloud instance over TLS, and the guidance is consistent across the docs: avoid sending unencrypted traffic over the Internet, and when using Cribl.Cloud, syslog with TLS is strongly recommended. The TLS benefits the guide lists are straightforward encryption in transit, integrity verification, and support for compliance in regulated environments.
Cribl.Cloud exposes a small set of fixed ports for syslog. Port 6514 carries TCP with TLS and is the standard for encrypted syslog. Ports 9514 and 514 carry unencrypted TCP or UDP, and 514 exists specifically for devices that cannot be configured to use a non-default port. If you are using Cribl.Cloud, set the sender's protocol to TLS/SSL rather than plain TCP, and use port 6514. Hybrid Stream Workers, by contrast, support any port, which is the lever for keeping dedicated ports per device class.
On the sender side, the configuration is to note your Public Ingress address, such as default.main.<organizationId>.cribl.cloud, set the destination to it, pick TLS/SSL, and enable certificate validation. Cribl.Cloud is secured with Google Trust Services (GTS) certificates. Most systems already trust GTS, so no additional certificate configuration may be necessary if your trust store is up to date. Where it is not, the guide shows importing the GTS Root R1 and WR1 certificates into the sender, with a worked example for Palo Alto.
The doc pages do not specify a NAT or outbound firewall requirement on their own. Our recommendation for that layer: your network must let the senders reach the Public Ingress address on port 6514 for TLS (or 9514/514 for the unencrypted paths), and where the senders cannot encrypt, keep them behind hybrid Workers on the same LAN so unencrypted traffic never crosses the Internet.
Frequently asked questions
Which syslog standards does the Cribl Stream Syslog Source parse?
It parses both RFC 3164 and RFC 5424 messages, including timestamps, facility codes, severities, and message content. It also handles the RFC 5425 and RFC 6587 length prefixes so larger messages arrive intact.
Is TLS available for UDP syslog into Cribl Stream?
No: the TLS settings on the Syslog Source are TCP only, so encryption is a transport decision. Port 514 traffic is unencrypted, so enable it only if you accept the risk.
How do I route mixed Cribl Stream syslog traffic from a single source?
The docs recommend a dedicated Syslog Source per sender class, on its own port, with metadata. When one Source must take a mixed stream, Routes split it into subsets, each with its own Pipeline, and a catch-all.
Which port should senders use for TLS syslog to Cribl.Cloud?
Port 6514 carries TCP with TLS and is the standard for encrypted syslog; 9514 and 514 carry unencrypted traffic. Set senders to TLS/SSL on port 6514 rather than send unencrypted traffic across the Internet.
Verified against Cribl Stream 4.20 documentation on October 1, 2026.