Shared state across multiple interfaces/workers or how to run manager/worker specific scripts

Zeek
1

Hi, I wrote a script caching certain data and executing commands upon new entries.

Thus zeek –bare-mode –iface lo -- ./script.zeek runs permanently, watches for, say requests to foo, and executes cmd foo for the first request seen.

The equivalent happens when cache entries expire, but that should not matter here.

I am new to Zeek and after Zeek Cluster Setup — Book of Zeek (git/master) and Notice Framework — Book of Zeek (git/master) still have questions on how to scale this to multiple interfaces.

  1. Given a cluster on localhost with one manager and proxy node each plus one worker node for each interface, is there a way to split workloads like mine into a) workers just parsing packets into events/notices/etc. with relevant data and b) a single manager node receiving all of them to maintain a single consistent cache regardless of the number of workers?
  2. Is it generally possible to have shared state between workers, e.g. like process-wide global variables in a multi-threaded program?

After reading, I started with the following node.cfg

[manager]
type=manager
host=localhost

[proxy-1]
type=proxy
host=localhost

[worker-1]
type=worker
host=localhost
interface=eth0
        
[worker-2]
type=worker
host=localhost 
interface=eth1

and am a bit thrown aback by zeekctl scripts suddenly showing me +2000 scripts being loaded.

So far I have not found documentation on or understood myself where the line between nodes lies wrt. what zeek code runs where and why.

Is anyone running a similar setup and/or can help answer above questions?

2

Based on Broker Communication Framework — Book of Zeek (v8.0.0) I employed

@if ( Cluster::local_node_type() == Cluster::... )
...
@endif

to divide local.zeek into code for the manager and several worker nodes brokering events between them.

It works, but only with careful placement of common code like event definitions to satisfy zeek during startup.

I wonder if there’s a more straight forward way, perhaps to have separate *.zeek files per node.