In this livestream, Cribl’s Ahmed Kira and I go into more detail about the Cribl Stream Reference Architecture, with a focus on scaling syslog. They share a few use cases, some guidelines for handling high-volume UDP and TCP syslog traffic, and talk about the pros and cons of some of the different approaches to tackling this challenge.
It’s also available on our podcast feed if you want to listen on the go. If you want to automatically get every episode of the Stream Life podcast, you can subscribe on your favorite podcast app.
When to use this reference architecture
Use this guide when you are designing or updating a Cribl Stream deployment for syslog and need to make architecture decisions about collector placement, load balancer configuration, port and pool strategy, worker distribution, or dedicated worker groups. If you are looking for general syslog best practices, start with the broader scaling-syslog article instead.
Should You Use Syslog Over UDP or TCP?
Syslog was originally designed as a protocol to be leveraged over UDP, so we recommend using it as such. Protocols (like HTTP) designed for TCP will regularly open new connections to take full advantage of the TCP stack — protocols built for UDP and used over TCP won’t be able to open these new connections. Instead, they’ll be put over one long-lived connection and cause major load-balancing issues.
Whatever you do, don’t try to home-run your UDP Syslog data across your WAN — there are very few situations where data loss would be more likely. Keep your collection sources as close to the destination as possible, and have at least one syslog server in every data center.
Configure Your Load Balancers Correctly
It would be hard to overstate the importance of properly configured load balancers for collecting syslog data. In addition to using UDP instead of TCP, be aware of UDP pinning, which can happen if your load bouncer is misconfigured. Even if you have three Cribl Stream workers below your load balancer, data can get funneled to only one of them if you have sticky sessions or other faulty settings enabled.
You want to have as much distribution across your worker processes as humanly possible because that’s how you can engage all the resources on the server and get that scale you’re looking for. If you have 50 cores on each server, but only one of them is getting engaged, scalability will be severely limited.
If you have multiple CPUs on one of Cribl workers, you want to spin up a different worker process to map to each one. When the load bouncer redirects the traffic to that worker, it’ll spread it across all of the available worker processes and take advantage of all of the available CPU cores.
Other best practices for correctly configuring your load balancers include using as many pools as possible. Unless you’re a small mom-and-pop shop, avoid sending all your syslog traffic over the default 514 — allocate different ports for different device types instead. You also want to map each pool to that same port on your Cribl workers.
Once you get data into Cribl Stream, it’s all TCP from then on — and it’s very flexible. All of your issues with managing Syslog will likely go away at that point, but the data has to make it there first.
Dedicated Worker Groups vs. an All-On-One Worker Group
The all-in-one worker group is a good choice for organizations with only one or two regions and less than 1 TB of data daily. Suppose you’re collecting data from various agents like Elastic, pushing data to Stream via HTTP, using a rest collector to pull data from an API, or sending data to just one destination. In that case, there’s no need to overcomplicate things.
If any of these things change, you’ll have to start thinking about separating out worker groups.
A dedicated worker group comes in handy when you make changes to your syslog data — commit-and-deploys in Stream won’t affect any other worker groups, and syslog will be the only thing that needs to be restarted. Isolating the workflow means fewer restarts and fewer problems for you and your enterprise.
Having a dedicated worker group for your syslog gives you more breathing room for processing and increases business resiliency at the same time. If you have a DDoS attack or a massive spike of data, it’ll only impact your Syslog worker group instead of shutting down everything else. Environments that deal with large volumes, heavy regulation, or high SLAs for availability benefit the most from splitting up data sources, allowing you to fail small instead of big when certain situations arise.
Watch the full livestream for more insights on how SecOps and Observability data admins can integrate Cribl Stream into any environment — including formatting and change management guidelines within data centers. Don’t miss out on this opportunity to empower your observability administration skills.
More on the Cribl Reference Architecture Series
How do I set up Cribl Stream as a syslog server?
Create a Syslog Source in Cribl Stream with a name, a port to listen on, and your protocol choice (TCP, UDP, or both). Cribl Stream parses the basic syslog structure by default, so you can immediately route, transform, filter, and forward the data. Keep the default 0.0.0.0 listen address unless you have a specific reason to change it.
Should I use TCP or UDP for syslog?
Use TCP with TLS whenever your senders support it, because UDP offers no delivery guarantee or encryption. Many appliances only use UDP, so if you must use it, deploy Cribl Stream Workers as close to the syslog producers as possible and tune the Linux kernel receive buffers to avoid dropped packets.
How does Cribl Stream handle syslog load balancing?
Most load balancers pin TCP syslog to a single connection, which limits throughput to one Worker Process. In Cribl Stream 4.6.0, a native syslog load balancing feature dedicates one process per Worker Node to receive TCP syslog and distribute events across all Worker Processes, scaling to about 100 MB/s of ingested syslog per Node.
How do I prevent syslog data loss during downtime?
Enable persistent queuing (PQ) in Cribl Stream. Use source-side PQ in most situations, because most syslog senders (and all UDP senders) do not buffer data when the receiver is down. If you enable source PQ on a UDP syslog input, set the event buffer under Advanced Settings to 0, to prevent both from being active at once.
How should I handle syslog timestamps without timezones?
Many syslog senders still omit timezone information, which can cause events to appear in the past or future. Use the Cribl Syslog Preprocessor Pack with lookup files to map hosts to their correct timezones, and standardize all servers and appliances on UTC long term. Have your analysis tier convert to local time when needed.
Does Cribl Stream support RFC 6587 octet count framing?
Yes. In Cribl Stream 4.7.0, RFC 6587 messages are automatically recognized, so no manual toggle is required. Octet count framing specifies the message length at the front of the payload, which makes event breaking precise.
