Determine if ConfigureWithOutputs is sufficient for beatreceiver project

[leehinman]

#218 proposes a new function ConfigureWithCore, but ConfigureWithOutputs already exists.

Need to determine if existing ConfigureWithOutputs is sufficient or could be modified to work with beats receiver project.

[leehinman]

In its current form ConfigureWithOutputs calls createSink which creates a new logOutput. This isn't what we want in the case of the beats receivers. We don't want to setup file logging, all of the log retention should be handled already. In #218 we are calling wrappedCore to get the new sink, and selectiveWrapper to set the selectors on it.

@belimawr we could change ConfigureWithOutputs so if toObserver, toIODiscard, ToStderr, ToSyslog, ToFiles, and ToEventLog were all false it it didn't call createSink but instead used wrappedCore. What do you think?

[belimawr]

@belimawr we could change ConfigureWithOutputs so if toObserver, toIODiscard, ToStderr, ToSyslog, ToFiles, and ToEventLog were all false it it didn't call createSink but instead used wrappedCore. What do you think?

I'm not a fan of this "magic behaviour". But first things first, let me truly understand your goal here.

Because of the Beats receiver project, we need to be able to take an already existing zapcore.Core and use it without ever creating a new one, is that it? Effectively an empty logp.Config will not create any output, is that it?

I'm not a huge fan of "magic behaviour", but it seems to make sense and I believe we have enough tests in place to avoid unforeseen side effects like #208 fixed. logp.DefaultConfig setting ToFiles seems to make sense with this new proposed behaviour.

Just make sure to document it in ConfigureWithOutputs and test a standalone Beat to ensure the current behaviour is not changed.

[leehinman]

Because of the Beats receiver project, we need to be able to take an already existing zapcore.Core and use it without ever creating a new one, is that it?

Essentially yes, the core is already configured with where the logs will be written to. So we just want to use that, and potentially have selectors.

I'm not a huge fan of "magic behaviour", but it seems to make sense and I believe we have enough tests in place to avoid unforeseen side effects like #208 fixed. logp.DefaultConfig setting ToFiles seems to make sense with this new proposed behaviour.

The avoiding magic was part of why I had a different function before. In general I would prefer the new function.

[leehinman]

@belimawr #218 is back out of Draft and ready for review