Jonatan Ivanov

>I thought removing the gauge due to expiration would be likely very easy to implement Since meters don't have references to the registry, I doubt this would be very easy....

I quickly looked into your reproducer and it seems you are tracking the number of active tasks (processed/pending messages). We have a component for this use-case it's called `LongTaskTimer` (`ActiveTaskTimer`...

Yes, the name does not reflect all the use-cases but we cannot change it unfortunately. 1/ You are right, this is a breaking change for the dashboards/alerts/everything that depends on...

I slept on it and I also realized that the `MultiGauge` solution does not work. :( I came up with another workaround using `Meters`, could you please take a look?...

>In general, would you recommend against a custom meter ? Can you see any downsides? Usually, you should be able to solve your use-cases without using a custom meter, but...

Thank you for the issue! What is your use-case? What are you trying to do so that you need to call `getRegistries()` concurrently? I'm especially curious about the concurrent usage...

I think the root of these issues is using the global static `Metrics` registry. We really not recommend using it especially with Frameworks like Spring where dependency injection is what...

`OtlpConfig` also lets you set you the unit, I guess you might want it to set it for every time-based meter not only for a single `Timer`.

I cleaned your project up and if you set `management.otlp.metrics.export.baseTimeUnit: seconds` (or `OtlpConfig#baseTimeUnit`), the unit is `seconds`: ``` [...] metrics { name: "http.server.request.duration" unit: "seconds" [...] ``` This is because...

OTLP does not require UCUM, what you linked is semantic conventions (which does not require it either) but I think we should make it configurable anyways and enable you to...