Getting Micrometer Metrics Bridge from Alpha to Stable

[ThomasVitale]

Is your feature request related to a problem? Please describe.

I opened this issue to track the work that is needed in order to get the Micrometer Metrics Bridge from the alpha status to stable.

Up until the latest release (2.16.0), the instrumentation was using a class from an incubating API. That was removed in b3233c4, so there is no more dependencies on alpha libraries from what I can see.

Describe the solution you'd like

I'm not sure what is needed to get this instrumentation to the stable state, but I'm available to help out getting there.

Describe alternatives you've considered

No response

Additional context

@brunobat perhaps you have some inputs on this from Quarkus?

[brunobat]

I Agree this should be moved to stable, @ThomasVitale

[trask]

hi @ThomasVitale! interestingly we just stumbled across something in the Micrometer Metrics Bridge in the Java SIG meeting yesterday which I've added to semantic convention SIG meeting on Monday to get clarification:

The bridge currently adds .max at the end of existing Timer and Summary metrics, e.g.

opentelemetry-java-instrumentation/instrumentation/micrometer/micrometer-1.5/library/src/main/java/io/opentelemetry/instrumentation/micrometer/v1_5/OpenTelemetryTimer.java

Line 80 in f266e6f

.gaugeBuilder(name + ".max")

Which would violate one of the semantic convention naming rules that has been sort of followed previously, but which isn't an official naming rule today: open-telemetry/semantic-conventions#50

I'll work on getting resolution to that question (one way or the other).

Separately, it may be worth opening a draft PR in this repo to add otel.stable=true to the micrometer module, which will force generation of the apidiff files, and you can help us review if the publicly exposed API looks ready for stabilization.

[laurit]

I'm not sure what is needed to get this instrumentation to the stable state, but I'm available to help out getting there.

I think first you should try to figure out what making it stable means.
Inspect the public api of the module, does everything there make sense? Or perhaps some features should be kept as experimental so they could be removed or altered in the future? Is something missing? Try documenting how the bridge works, how are micrometer instruments transformed into otel instruments, can it be improved in some way? Perhaps from such document it is easier to spot issues like adding .max suffix that @trask pointed out. It could also be helpful for the users. Meditate on implementation details such as otel bridged instruments not being readable, is that a problem?

[brunobat]

I'm not sure what is needed to get this instrumentation to the stable state, but I'm available to help out getting there.

I think first you should try to figure out what making it stable means.

Given the age of the bridge's current form with little complaints, probably it's good to go. Breaking things now, after all this time, it's not nice.

If we are modifying anything, getting feedback from the Micrometer community, would be important.

CC @jonatan-ivanov

[trask]

Which would violate one of the semantic convention naming rules that has been sort of followed previously, but which isn't an official naming rule today: open-telemetry/semantic-conventions#50

I'll work on getting resolution to that question (one way or the other).

Discussed in semantic convention SIG meeting today. It sounds like open-telemetry/semantic-conventions#50 will probably be adopted.

Any objection to just dropping the decaying .max metric? otel histograms already have a regular non-decaying max, and if otel community finds decaying max useful we should try to get it into the spec and support it more generally

[brunobat]

Which would violate one of the semantic convention naming rules that has been sort of followed previously, but which isn't an official naming rule today: open-telemetry/semantic-conventions#50
I'll work on getting resolution to that question (one way or the other).

Discussed in semantic convention SIG meeting today. It sounds like open-telemetry/semantic-conventions#50 will probably be adopted.

Any objection to just dropping the decaying .max metric? otel histograms already have a regular non-decaying max, and if otel community finds decaying max useful we should try to get it into the spec and support it more generally

Ok, we will notify the users about the breaking change.