Why There’s No Single Right Zeek Deployment Architecture
Every month we ask the Zeek community a different question about how they work. This month’s question was about deployment: how do you decide on your architecture, and what would you reconsider? The answers made one thing clear: there isn’t a single right answer, even among practitioners who’ve been doing this for decades.
One Big Server, or Many?
A poll this month asked a simple question: one large server running everything, or multiple physical servers split across the deployment? The answer looked clear at first. Most respondents chose multiple physical servers over a single “cluster-in-a-box” setup.
The discussion that followed complicated that number almost immediately. Resources, cost, tap point count, and where infrastructure physically lives all factor in, one contributor pointed out, which means there’s no universal answer, just tradeoffs that look different depending on your constraints.
Someone in the thread asked whether “all of the above” should have been an option on the poll. The reply confirmed it: their own setup runs one of each kind, for experiments, for habit, and because different use cases genuinely call for different setups.
Even the physical limits of a single box aren’t as fixed as they sound. A 4U server can hold a lot, ten network cards, well over a hundred cores, plenty of RAM, but every deployment running one eventually finds where it saturates. Multiple smaller servers scale further, but they bring their own costs: rack space, power, more things to manage. For most practical purposes, both approaches work. Which one is right depends entirely on what you’re optimizing for.
When a Deliberate Decision Has a Cost You Didn’t See Coming
A recent migration story from the discussion makes the point well. One deployment needed deduplication for a new datacenter architecture, so the team moved tap aggregation from older switches to a different vendor’s platform built for that purpose. The move solved the problem it was meant to solve.
What it didn’t account for: the new platform doesn’t expose a per-flow packet counter, and a shunting methodology the team had relied on for years depended on exactly that. The fix wasn’t simple, since the new API didn’t offer an equivalent way to get the same data.
It turned out not to be a major issue. The shunting approach wasn’t heavily relied upon in practice, so losing it was a manageable tradeoff rather than a serious setback. But it’s a useful reminder that even a well-reasoned, deliberate architecture decision can carry a cost that only shows up after the switch is already made.
The Decisions Nobody Talks About Until They Have To
Architecture decisions don’t stop at server count. Where to place Zeek in the network, inside or outside the DMZ, watching east-west or north-south traffic, shapes what you’re able to see. Packet broker choice and vendor selection affect how much of that traffic actually reaches Zeek in the first place. And once a deployment is running, someone has to monitor the deployment itself, which for most practitioners means some combination of Nagios, custom scripts, and cron jobs checking that everything is still alive.
A newer wrinkle came up this month too: using AI to help catch deployment settings that are easy to overlook, network card adjustments in particular that nobody realized needed attention until something pointed it out.
What This Adds Up To
None of this points to a best-practice architecture that everyone should be running. The practitioners in this month’s discussion have decades of combined experience between them, and the closest thing to consensus they reached was that the right setup depends on your constraints, not on a universal formula. The decisions that matter aren’t about finding the correct architecture. They’re about understanding the tradeoffs of the one you pick.
Want to share your own deployment decisions, or the tradeoffs you didn’t see coming? Drop us a note in our Slack community!
Thank you to the community members who contributed to August’s Deployment Decisions conversation: Aashish, Carlos, Dop, Seth, Tom, Kevin, Gargi, Phuong, Jakob, Trong, Chris H., Chris C., Keith, Jim, and Hobbs.
Our topic for September will be announced soon. Join us in the #topic-of-the-month channel on Slack and stay tuned!