Getting Zeek deployed is one thing. Keeping it running well is another, and it looks different for every environment. Last month, we asked the Zeek community: once Zeek is in production, what does the ongoing care actually look like? What do you monitor, what have you automated, and what have you learned the hard way?
The answers varied by environment, but three themes came up consistently: knowing which signals to watch, not assuming your packet capture is complete, and using automation to catch problems before they catch you.
Here’s what the community shared.
Start With Three Questions
One practitioner running a large cluster put it simply, and it resonated across the whole conversation. When it comes to monitoring Zeek, most of what matters comes down to three questions:
- Is Zeek up and generating logs?
- What’s the load on the workers?
- How’s packet loss looking?
Everything else is nice to have. Those three are the baseline, and if you don’t have a quick way to check them, gaps in coverage tend to surface later than you’d like.
Turning Signals Into Alerts
Most practitioners start building visibility in the logs Zeek generates about its own operation. One practitioner shared the specific set of diagnostic logs they watch: stats.log, capture_loss, analyzer_debug, broker, cluster, config, packet_filter, and reporter, feeding them into dashboards that surface packets and bytes seen, packet drops, ACKs missed, and traffic volume by interface.
If that list feels like a lot to start with, two logs cover a lot of ground: capture_loss tracks missing traffic based on TCP sequence gaps, and stats.log surfaces throughput and performance metrics. Together, they answer two of the three baseline questions directly, which means you can start getting real visibility into your deployment without building out a full monitoring stack first.
Dashboards are a solid foundation, and the next step for many practitioners is pairing them with alerting. One community member says he sends Zeek’s operational logs into a log aggregation platform (Splunk in their case) to get notified about missing data and failures that config management can’t auto-fix. Rather than checking dashboards manually, the alerts come to them. The approach works regardless of which platform you use.
Whether you’re starting with two logs and a dashboard or routing everything into a SIEM, having some visibility into Zeek’s own operation means you’re in a position to catch problems early rather than piece things together after the fact.
Don’t Assume Your Capture Is Complete
Getting packets to Zeek in the first place requires a decision because how you feed traffic to your sensor matters as much as how Zeek processes it. Switch mirroring is the obvious starting point; it’s built in and requires no extra hardware. One practitioner running a home deployment went that route, figuring it would be more than adequate for a network that wasn’t heavily loaded. They were still seeing 0.5% packet loss after the fact.
On a whim, they bought a used 1Gbps copper bi-directional tap. Packet loss went to zero and stayed there.
The lesson: switch mirroring is convenient but not guaranteed, and the same limitation can apply at any scale. Even on lightly loaded networks, you can’t fully rely on it to deliver 100% of packets 100% of the time. If complete capture matters for your use case (and for most Zeek deployments, it does) you need to design for it. That might mean a hardware tap, packet brokering equipment, or at minimum, understanding where your current setup has limits.
If you’re evaluating your capture setup, it’s worth testing actual packet loss before assuming mirroring is sufficient. A small investment in tapping hardware can eliminate a variable that’s otherwise difficult to diagnose.
Automation as Operational Confidence
For teams managing multiple sensors or frequent Zeek updates, some practitioners have built systems that catch problems before they reach production. The implementations vary; some are more involved than others.
One approach that was shared is a CI/CD pipeline that automatically builds new versions of Zeek as soon as they’re merged upstream, across each OS in the environment. A nightly Ansible job deploys the latest build to a test host. If something breaks, it breaks there, and production stays stable.
Another approach is a deployment script that monitors running Zeek processes and the last modified time of dynamically generated config files, triggering an automatic redeploy via zeekctl when needed. What would otherwise require manual intervention gets handled automatically.
Both reflect the same idea: if a process catches failures automatically, you spend less time wondering whether things are working.
What This Adds Up To
The practitioners who contributed this month run very different stacks. Some use Splunk, some custom dashboards, some CI/CD pipelines, some bought a tap. Environments range from home labs to large multi-node clusters.
But the pattern holds: stable deployments belong to operators who can answer those three questions (is Zeek up and generating logs, what’s the worker load, how’s packet loss) and built just enough to know when the answer changes. That’s a reasonable place to start regardless of where you’re running Zeek.
Want to share how you keep Zeek running? Join the conversation in the Zeek Slack community.
Thank you to the community members who contributed to April’s Topic of the Month conversation, “How do you keep Zeek running?”: Mark M., Seth, Jim, Aaron, Jakob, Doug, Chris H., Carlos, Luca, Chris C., Trong, Franky, Mark O., Arne, and Dop.
This month we’re talking about Sensor Placement. We want to learn more about the decisions you make and how you think about visibility. Join the conversation today in our Slack workspace.
RSS - Posts