[Zeek-Dev] Supervisor client (Re: Zeek Super-isor: designing client and log archival behavior)

[Robin Sommer]

> * https://github.com/zeek/zeek/wiki/Zeek-Supervisor-Client

Some thoughts on the commands:

> $ zeekc status [all | <node_name>]

> Do we need to include any other metrics in the returned status?

That information is mostly static, would be nice to get some dynamic
information in there as well, like uptime, CPU/memory/traffic stats,
No need to have that right away, but worth keeping in mind.

> # Do we need more categories to filter by (e.g. node type) ?

I'd skip for now.

> # If there's downed nodes at this point, what do we expect users to do?
> # Check the standard services logs for stderr/stdout info?  Check reporter.log ?

Yeah, would be cool if zeekc had access to the stderr/stdout from the
nodes through their supervisors. The supervisors could buffer that for
a while and return on request. More generally, the supervisor could
get a "diagnostics buffer" that, over time, we could use for more
stuff like store backtraces etc.

"reporter.log" is out I'd say, that will go through the normal log
rotation & archival, and be accessible that way.

> # A `zeekc diag` command could help gather information, like ask Zeek supervisor
> # to find core dumps and extract stack trace.  Would it do more than that, like
> # show last N lines of downed nodes' stderr, or last N lines of reporter.log?

> $ zeekc check

I'm wondering which supervisor that would be be talking to in a
multi-system setup? All?

> $ zeekc terminate
>  ...

> # Normally wouldn't terminate the supervisor if a service-manager is handling
> # the Zeek supervisor process itself and will just restart it, but`terminate`
> # would be helpful for anyone running a supervised Zeek cluster
> "manually".

Another use case: If for some reason one wants to restart the
supervisor itself, "terminate" would kill it and the service
manager would then restart it.

Robin

-- 
Robin Sommer * Corelight, Inc. * robin at corelight.com * www.corelight.com