Accept interface instead of *zap.Logger

[gotd]

Accept interface instead of *zap.Logger

[ernado]

I'll return to this near 1.0 release, probably I'll extract abstract logger to separate package under gotd org.

I've seen lots of bad approaches to this problem and just don't want to make another one.

[tdakkota]

Seems like duplicate of #15

[ernado]

Yes, this can be achieved in #15

Currently I can't come with a way of abstracting out zap logging without losing performance or usability.

Can you please provide examples of such "abstract logger"?

[Semior001]

Example is here: https://github.com/go-pkgz/auth/tree/master/logger
This is the library for providing oauth, it also stores its states, logs some events, but there you may provide your own implementation of the store and logger

[ernado]

// L defined logger interface used everywhere in the package
type L interface {
	Logf(format string, args ...interface{})
}

So there are no way to use subloggers, structured logging and verbosity levels.

[Semior001]

Nothing stops you from defining such interface, like:

type Logger interface {
	Debug(format string, args ...interface{})
	Info(format string, args ...interface{})
	Warn(format string, args ...interface{})
	With(info string) Logger // adds additional information to the logger
	Named(name string) Logger // creates a sublogger
}

at least it adds some flexibility around the logger, while the library is strictly tied to zap.

[ernado]

I need statically typed structured logger with good performance, if someone will come up with zap-like interface for abstract logger I'm ok with it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tdakkota]

keep

[suntong]

I've seen lots of bad approaches to this problem and just don't want to make another one.

Here is my 2c, the best performance logger (for both logging and parsing) that I found is

https://github.com/go-kit/log
(There are some benchmarks & comparisons links at the end of it)

which is also a structured logger --

• Using a stricter, key/value-oriented message format for our logs, containing contextual and semantic information, makes it much easier to get insight into the operational activity of the systems we build.
• Migrating from unstructured to structured logging is probably a lot easier than you'd expect.
• And as last resort, you can redirect stdlib logger to Go kit logger too.

For more details on the evolution of the Logger interface, see The Hunt for a Logger Interface, a talk by Chris Hines.

All in all, it is a minimal and extensible structured logger

[ernado]

Currently I'm waiting for https://github.com/open-telemetry/opentelemetry-go implementation of logging API.

[ernado]

Also structured logging proposal just got accepted:
golang/go#56345