[Bro-Dev] Broker's remote logging (BIT-1784)

Siwek, Jon jsiwek at illinois.edu
Mon Feb 6 18:46:42 PST 2017


> On Feb 6, 2017, at 10:43 AM, Robin Sommer <robin at icir.org> wrote:
> 
> I propose that for now we make Broker work like the current model, and
> then we go from there. If we need more, we can add that later. The
> less semantic differences we have between old and new communication,
> the easier the switch will be.

Yeah, I agree that it should behave the same.  Was just also trying to reframe the problem to give ideas for solutions that give back old semantics (i.e. via script-level mechanisms).  No big deal, since there’s no demand for it.

> In addition to that, one can always send log_*
> events around and then do custom processing on the receiving side.
> That's not quite as transparent as "normal" log messages would be with
> their configuration and filters, but that might actually be a good
> thing: if we actually had both mechanisms (sender- and receiver-side
> filtering) built transparently into the logging framework, it could
> end up being quite confusing what's used when.

It was actually always confusing to me that a remote log entry versus a local log entry would be processed differently regarding the log_* events.  The event is a property of the Log::Stream definition and the logging API or docs don’t distinguish between outgoing versus incoming log entries there, or do they?  Or is a Stream meant to be thought of from only the perspective of an outgoing sequence of log entries?

Could be I misunderstood the log framework the whole time, and that’s why broker behaved the way it did :)

- Jon



More information about the bro-dev mailing list