Standardize logging practices within the SDK and plugins

[connorlindsey]

I'm working on a Cortex Exporter and noticed that there isn't much consistency as to what logging package is used across the various components (instrumentation plugins, exporters, etc.). As mentioned by @MrAlias on Gitter, this should probably be configurable by the end user. The standard log package would probably be a smart default, but I'd like to start a discussion on what the default package should be and how we can make this configurable. Thanks.

[Aneurysm9]

A pattern I've had success with in the past is to define a simple interface and provide accessors that fallback to the stdlib log package if no implementation is provided.

type Logger interface {
  Print(v ...interface{})
  Printf(format string, v ...interface{})
  // etc., maybe Fatal/Fatalf
}

func FromContext(ctx context.Context) Logger {...}

I'd really like to be able to attach labels/fields to a log entry, but I'm not sure there's any consistent interface that could be expected to be common between log, logrus, zap, and any other likely candidate for a Logger implementation.

[cbandy]

https://github.com/go-logr/logr ?

[bhautikpip]

I am writing one pager doc to add standardized logging for OTel Go SDK. I am probably planning to discuss this in Thursday's SIG meeting. Feel free to review and post feedback.

[MrAlias]

I would second standardizing on the https://github.com/go-logr/logr package. The package is structured in an API and implementation fashion similar to OTel and have already addressed many of the concerns we has identified here, in the linked design doc, and in the logging implementation draft PR.

They themselves host an implementation ecosystem that supports glog, zap, zerolog, and the stdlib log package. Additionally, there seem to be many other third-party implementation of the API (including logrus and klog). Meaning OTel users will not be constrained to a single logging implementation to back OTel and will have a good chance at connecting their existing logging system as an implementation.

I would prefer to not reinvent yet-another-logging package/implementation here in OTel. Instead I would like to focus this project on delivering telemetry and utilize another open source community to focus on logging. Especially since they seems to be structured in a compatible manner, have reached a stable release, are being actively developed, and seem to be widely used.