Hello,
the latest Zeek development version re-introduces event groups. This feature allows to disable and re-enable individual event and hook handlers at runtime.
As a continuation, we’re exploring to apply event groups to log streams: For instance, when the logging stream for dns.log is disabled, also disable all event handlers within the base/protocols/dns scripts related to logging. The idea is to remove the overhead of event handlers that are essentially not productive, while keeping the analyzer enabled for other scripts to use these events.
We know of deployments where the logging stream for very new analyzers has been disabled (either due to being too low-level, or not yet fully fleshed out to be enabled and supported by default). However, other functionality scripts reply on these analyzer’s events. To achieve this, one can either call Log::disable_stream() for the involved streams and accept the overhead of the event handlers, or patch the analyzer’s scripts such that logging functionality is in separate files that are then conditionally loaded. The latter approach, however, requires additional dynamic rendering of @loads outside of Zeek rather than using, for example, the configuration framework to toggle such functionality at runtime.
We’re curious if the idea resonates with other users, operators or system builders. We’re also looking for other ideas (whether related to logging or not) where event groups could be interesting.
Thanks,
Arne
A early draft/sketch PR around this has been opened demonstrating implementing this idea either using explicit &group tags, or by introducing “logging modules” and disabling all events in those modules.