[API] Introduce a new global level api.diag for internal Diagnostic Logging (Part 1)

[MSNev]

Introduction of new api.diag global logger as discussed during SIG meetings and linked to #1754

Basic outline

• Provide a top-level diagnostic logger from the API as api.diag with methods like api.diag.warn, api.diag.debug, etc.
• diag logger is no-op by default
• register a default logging implementation by calling api.diag.setLogger(loggingImpl)

Part 1

• For now we should keep but deprecate direct use of the NoopLogger and ConsoleLogger classes

Part 2

Will include breaking changes

• Once contrib is changed to use api.diag, these exports will be removed, this will require that they stop using local Logger instances
• This will also have breaking changes for
  • Configuration definitions that use api.Logger and core.LogLevel
  • Functions that currently get or pass api.Logger instances
  • The type of the environment OTEL_LOG_LEVEL

[MSNev]

Please assign to me as I can't assign it myself

[vmarchaud]

Quick question: does the exact name has been discussed in the SIG today (i couldn't attend sadly), i feel like shortening to diag kinda "obsfucate" its usage, what about just using api.diagnostics ?

[MSNev]

It was originally discussed 2 Sig's back, and part of the reason for the shortened name is to better support code minification, which is also the reason for introducing in the first place see #1754 for part of the discussion

[vmarchaud]

Okay cool i didn't miss anything then. I understand the code minification issue that of course impact everyone using otel, however i want to be sure that we all agree on "sacrificing" readability (at least in my opinion) for this goal.

[aabmass]

Quick question, is this logger intended to be usable by instrumentations and exporters or truly "internal"? I maintain the Google Cloud OTel exporters (in a different repo) where the code base also has plenty options.logger || new NoopLogger(). I want to know if I can use this when its ready.

[MSNev]

Yes, this is designed to be used for all "internal" diagnostic logging of the Api, Sdk's, instrumentations, exporters and all contributed components.

So read "internal" as the OpenTelemetry and supporting components vs the "application" that uses OpenTelemetry as the diagnostic logs are local to the executing environment.

[MSNev]

This is included in v0.17