Add autoconfigure console alias for logging exporter

[jack-berg]

The spec recently merged a series of PRs which officially defines the "stdout" exporters, and defines the corresponding OTEL_{SIGNAL}_EXPORTERS value to be console:

• add definition for standard output logging exporter opentelemetry-specification#3741
• add definition for standard output span exporter opentelemetry-specification#3740
• add console as a supported env variable exporter type opentelemetry-specification#3742

This PR reflects those changes by adding support for the console value, which is simply an alias for logging.

[codecov]

Codecov Report

Attention: Patch coverage is 96.77419% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 91.05%. Comparing base (62a4810) to head (62c57f9).

Files	Patch %	Lines
...ogging/internal/ConsoleMetricExporterProvider.java	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6027      +/-   ##
============================================
- Coverage     91.06%   91.05%   -0.01%     
- Complexity     5699     5711      +12     
============================================
  Files           621      624       +3     
  Lines         16679    16699      +20     
  Branches       1709     1711       +2     
============================================
+ Hits          15188    15206      +18     
- Misses          998      999       +1     
- Partials        493      494       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[trask]

what do you think of renaming the artifact?

[jkwatson]

I'd be a little hesitant in renaming artifacts. It's definitely caused a lot of confusion in the past when suddenly an artifact no longer exists for a version, and it's been renamed. This has often led to people mixing and matching artifact versions, which is a significant foot gun for users.

[jack-berg]

An argument against renaming artifacts is that it will cause the class names to be misaligned:

• Artifact named opentelemetry-exporter-console
• Classes named Logging{Signal}Exporter

Of course we could introduce new classes named Console{Signal}Exporter and deprecate the Logging{Signal}Exporter variations.

[trask]

I find the name opentelemetry-exporter-logging to be regularly confusing (I keep thinking it's the log exporter).

I'd be a little hesitant in renaming artifacts. It's definitely caused a lot of confusion in the past when suddenly an artifact no longer exists for a version, and it's been renamed. This has often led to people mixing and matching artifact versions, which is a significant foot gun for users.

this is a great point though

maybe we can have both opentelemetry-exporter-console and keep publishing (a deprecated) opentelemetry-exporter-logging artifact (which can have a dependency on opentelemetry-exporter-console if that's helpful for reducing duplication)?

[jack-berg]

maybe we can have both opentelemetry-exporter-console and keep publishing (a deprecated) opentelemetry-exporter-logging artifact (which can have a dependency on opentelemetry-exporter-console if that's helpful for reducing duplication)?

That's an interesting idea..

While we're on the subject of making the logging exporters less confusing / more useful, would probably be good to optionally give the user more control over where the logs go. Could have an optional Consumer<String> logHandler argument which defaults to sending to JUL, but could also be configured to go to the user's desired logger (SLF4J, System.out, etc). Could apply the same principle to the logging OTLP exporter.

[jack-berg]

Opened #6263 to discuss further and track. Shouldn't be a blocker for this PR tho. Please take another look!