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.

[jonatan-ivanov]

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.

For gauges, yes. Counters are cumulative (shows the running total not the latest value) both for the metrics- and prometheus endpoints. I guess once you are in the realm of "comparing values ​​at different times", you might also need a metrics backend so you might want to consider running Prometheus from docker-compose so that you can even keep execution results between application restarts.

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

People usually don't want to wait a minute just to see if a value was updated or not. That's why, for local development, using an on-demand output is usually more convenient. I'm not sure this is what you meant but LoggingMeterRegistry is not pushing to a metrics backend (system) and there are backends (Prometheus) that do not work like that either (they are on-demand/pull based not scheduled/push based).

You mean use logging registry instead of simple if other options are not suitable?

No, I meant adding opt-in auto-configuration for LoggingMeterRegistry to make it simple to enable it in case one wants to use it (disabled by default, users need to explicitly enable it using a property).
(I'm not arguing that it should not be added, I just wanted to show you other options for local development.)

[vpelikh]

Guess I need to give more context.
I already have an application configuration for local dev with testcontainers (and lgtm for observability things), but not all our environments have the ability to spin up containers and still want to have metrics under hand as one more instrument to check for application health. For this reason, I created LoggingMeterRegistry configuration to let manage it throught properties instead of code.
I saw it can be useful in upstream as missing peace for consistency - other meters can be handled with config file - and created PR. I understand that this change value is not big, so feel free to decline.

[wilkinsona]

Thanks for the suggestion but we don't feel that we've seen sufficient need for this to warrant merging the change. There are good existing alternatives discussed above. For those that do want to use LoggingMeterRegistry it's a handful of lines of code to define the bean.