Add 'logging' as new metric export type

[vpelikh]

It's useful to see metrics in the console during development, without having to set up an LGTM container or write additional code.

[jonatan-ivanov]

It might make sense to add auto-configuration for LoggingMeterRegistry but I feel your original problem statement:

It's useful to see metrics in the console during development, without having to set up an LGTM container or write additional code.

might be easier to resolve using the /actuator/metrics or the /actuator/prometheus endpoints. LoggingMeterRegistry is not on-demand, it's a "step" registry, you need to wait for the logs to be emitted (once per minute by default). Also, Boot registers quite a few metrics, finding them in the logs might not be that easy as using the actuator endpoints above.

[danish-ali]

You verify back-off when a Clock is absent, but not when LoggingMeterRegistry itself is missing.
Could we add an ApplicationContextRunner test with a FilteredClassLoader(LoggingMeterRegistry.class) to assert that neither LoggingMeterRegistry nor LoggingRegistryConfig is created? That would complement the @ConditionalOnClass(LoggingMeterRegistry.class) path.

Additionally, minor naming nit in LoggingMetricsExportPropertiesConfigAdapterTests: some methods refer to “AggregationTemporality” but assert logInactive(). Consider renaming to reflect logInactive to avoid confusion.

[vpelikh]

might be easier to resolve using the /actuator/metrics or the /actuator/prometheus endpoints.

Good suggestion. But if I remember correctly, these endpoints only shows the latest values. In this case, one of the purposes of metrics - comparing values ​​at different times during the application's execution - is lost.

LoggingMeterRegistry is not on-demand, it's a "step" registry, you need to wait for the logs to be emitted (once per minute by default).

Yep, and I think this behavior what you should expect from a metrics system - to show metric values once in a while. 😀

Also, Boot registers quite a few metrics, finding them in the logs might not be that easy as using the actuator endpoints above.

Honestly, I never had this problem. But surely new configuration options can be added in future.

It might make sense to add auto-configuration for LoggingMeterRegistry

You mean use logging registry instead of simple if other options are not suitable?
I've considered this, but decided not to change the current behavior, because what's in this MR is sufficient for my purposes. Now, thinking about it, I see the benefit of always seeing metrics by default, even if only in logs, rather than the otlp sender's error. It seems like a spring boot way.
But it is still debatable, so I guess it will be better to open another MR with this changes.

[vpelikh]

Oh, thanks for the review, @danish-ali! I will check it out later when I will be around pc.