Describe the bug

When using OpenTelemetry javagent with Micrometer enabled on a Spring Boot application, Counter.count returns NaN instead of the counter value.

Steps to reproduce

1. Create a Spring Boot application with Micrometer
2. From business code increment a counter and log the counter value calling Counter.count method
3. Auto-instrument application with OpenTelemetry JavaAgent and Micrometer extension enabled
4. The Counter.count may return NaN or the real value

Expected behavior

• Adding the OpenTelemetry Javaagent shouldn't break Counter.count Micrometer interface contract and return a value
• Adding a child MeterRegistry to a Micrometer CompositeMeterRegistry should be consistent in terms of ordering to avoid flaky behaviour depending it's first or not.

Actual behavior

• OpenTelemetryCounter.count method always returns NaN.
• Counter.count returns NaN or the real value depending whether OpenTelemetryMeterRegistry is first or not in the parent CompositeCounter. See CompositeCounter
  • When it is first the Counter is an OpenTelemetryCounter, it always returns NaN as count
  • When another type of Counter (CumulativeCounter, PrometheusCounter...) is firts it, returns the real value
• The parent CompositeCounter is a Map of Counters where the MeterRegistry is the key. (see AbstractCompositeMeter)
  • So being first or second depends on the hashCode of MeterRegistry implementation. As MeterRegistry doesn't have proper hashCode implementation, the ordering is random.

The ordering only changes on application restart, which results in flaky behaviour.

The problem may occur on other types of Meters as well.

Javaagent or library instrumentation version

2.11.3

Environment

JDK: Corretto 21
OS: Linux

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}