Hello.
We’ve just switched the default cluster backend for a Zeekctl managed cluster to ZeroMQ in the master branch. This means that if you’re deploying a Zeek cluster using Zeekctl, individual cluster nodes (workers, logger, proxies and manager) will now communicate via ZeroMQ (XPUB/XSUB and PUSH/PULL sockets are used; the docs have more implementation details) instead of Broker. This is planned to be the new state going forward for Zeek 8.1. If you’re deploying Zeek in “single-node mode” (single VM, single physical system or a single container) and have no advanced and cluster-aware scripts deployed, this change should mostly be transparent to you.
If you’re integrating Zeek with external applications using Broker’s Python Bindings, we recommend switching to using Zeek’s WebSocket API instead as the Python bindings are Broker specific and not compatible with ZeroMQ. Benjamin has been working on language bindings for the WebSocket API for Rust, Python and C which should be part of Zeek 8.1 in one way or another.
This switch also means that features that are very ingrained with Broker will stop working. This, for example, affects Broker stores and the &broker_store or &backend attributes on tables. We’re discussing alternative approaches that involve explicit Cluster::publish() usages or introducing helper functions that can be used with &on_change on tables that are meant to be cluster backend independent. For persistently storing data, users should switch from the SQLite Broker store to the storage framework.
We understand this will break certain deployments, particularly if your scripts are Broker-heavy. Add the following entry to your zeekctl.cfg to keep using Broker.
# Keep using Broker...
ClusterBackend = Broker
We’re looking for testers and feedback. If you have the possibility to run Zeek with ZeroMQ enabled in a live/production environment, please report success, failures, unexpected behavior, reduced or increased CPU/memory usage. We’re cautiously optimistic that ZeroMQ should be more efficient. Look out for surprising messages on stderr or in reporter.log. If you see non-zero values for the Prometheus metrics zeek_cluster_zeromq_xpub_drops_total and zeek_cluster_zeromq_onloop_drops_total, that’s an indication that some events were dropped to avoid overloading individual cluster nodes. There’s more detailed Prometheus metrics available to understand the events and topics involved.
For users running non-Zeekctl managed Zeek clusters, it is now required to load the cluster backend explicitly. See the NEWS file more more information. Essentially you’ll have to put a @load line for a cluster backend somewhere:
@load policy/frameworks/cluster/backend/zeromq
@load policy/frameworks/cluster/backend/broker
If anything here is surprising or you have further questions, reply to this thread or reach out on Slack or Github!
Have fun!
Arne