Zap doesn't provide a simple way to add a writer

[lanzafame]

Looking at moving go-ipfs to #65 's version of go-log, and one of the sticking points is converting the functionality of the writer.WriterGroup.AddWriter call. Zap provides a way to redirect to another logger with a way of undoing the redirection or to add another SyncWriter or you can open a new output but that requires the output have a URL... I shall come back to this issue once I have dug into it more.

[lanzafame]

//cc @Kubuxu @frrist

[Kubuxu]

@lanzafame I guess you need that for ipfs log tail?

[frrist]

ipfs log tail was a stream of event logs iirc. Go-log has deprecated event log code, and #65 removes the deprecated code. Given that, I can't see a reason for keeping the log tail command.

[lanzafame]

That solves my problem. I will just get that ok'ed by the powers that be.

@Stebalien are you ok with the removal of ipfs log tail?

[Kubuxu]

Another option would be to allow streaming all logs, which would be much harder (but possible).

[Stebalien]

Discussed in-person with @lanzafame: I suggested we keep ipfs log tail as it shouldn't be that hard to get working simply by implementing a custom WriteSyncer.

However, I didn't think that through. ipfs log tail spits out structured logs but the WriteSyncer will get serialized logs. Unfortunately, I'm not sure how to get both structured and unstructured logs out of zap.

So, I've changed my mind. Let's just deprecate this command for now.

[Stebalien]

Actually, I take that back. It turns out zap has a nice NewTee function. We can use this to combine two cores: one that's only enabled when ipfs log tail is running and that spits out json and one that logs to standard error (or the user's configured logging system). That means users can pretty logs in their system log but still query a structured log.

If this turns out to be too much work, I'm fine punting. But it doesn't look difficult.

[Kubuxu]

I think, we would need to forgo the simplified configuration we do with ZapCfg and create cores manually.

In simplified model (if ipfs log tail can be same format as stderr output):

Cores would be:

• stderr core that would also be used for ipfs log tail
• file core (if enabled)

The stderr core would write to: MultiWriteSyncer, that would write into stderr and a custom Writer that would either discard or buffer logs for streaming to cli.