[Bro-Dev] New logging architecture

[Jonathan Siwek]

> I figure the LogMgr would need to be able to generate (at a minimum)
> the following types of messages:
> 
> *) EnableStream
> *) DisableStream
> *) StreamInit
> *) StreamFinish
> *) RotateLog
> *) LogMessage

Does that mean the LogMgr would send messages to Stream threads even if they're disabled?  Couldn't the LogMgr itself keep track of the Stream enabled/disabled state and just not send messages to disabled Streams?

> anything that spoke the correct message format could act as a logger for Bro.

That's a neat idea if you're hinting at something like creating Streams such that the LogMgr binds its 0MQ socket to a tcp port, allowing 0MQ sockets connected from other hosts (not necessarily running a full Bro process) to receive logs.  But I think some 0MQ-specific caveats of that might be:

* the same PUSH/PULL pattern may not work well because it's possible for the pusher to block on a call to zmq_send().  Maybe PUB/SUB is better when working w/ Streams that aren't inproc?

* 0MQ doesn't (currently) provide a good framework for securing messages[1] or being exposed to the public Internet[2].  (I'm about to send another mail about an experiment I did with the former topic, but basically I just ended up coming to the same conclusions that they/we already talked about).

- Jon

[1] http://lists.zeromq.org/pipermail/zeromq-dev/2010-October/006559.html
[2] http://lists.zeromq.org/pipermail/zeromq-dev/2010-September/005944.html