OpenTelemetry Semantic Conventions for JVM metrics

[lenin-jaganathan]

Please describe the feature request.
In open-telemetry/semantic-conventions#569, OpenTelemetry has made JVM metrics stable. It makes sense to adopt the stable semantic convention for OTLPMeterRegistry to keep in line with the OTEL Semantic Convention.

Additional context
Related links,

• OTEL JVM Semantic Convention
• PR marking it stable in OTEL Semonv

[shakuzen]

Since in Micrometer we consider changing existing meter names and tags a breaking change, I'm not sure how we would do this outside a new major version. Any ideas?

It makes sense to adopt the stable semantic convention for OTLPMeterRegistry to keep in line with the OTEL Semantic Convention.

I also wouldn't tie a wire format (OTLP) to a semantic convention - I think they should be separate decisions. It should be valid to use OpenTelemetry semantic conventions with a format other than OTLP and it should be valid to use OTLP without using the OpenTelemetry semantic conventions.

[ntkoopman]

Add additional OTEL specific MeterBinder implementations in addition to the JVM ones?
Or add an option to the current ones to output the updated OTEL conventions and leave it to the user to set it?

[lenin-jaganathan]

I am working on something within our organization. It is a bit of hybrid approach with using MeterFilter for renaming existing things and an additional MeterBinder for missing pieces. I can create a follow-up PR if we agree on the approach in this issue.

Yeah, this should be a opt-in thing for the reason @shakuzen mentioned above.

[jonatan-ivanov]

As an alternative to the MeterFilter, I think using a mechanism that is somewhat similar to ObservationConvention might work too but's that is a bigger change and it includes new public API components.

[shakuzen]

I've updated the labels and issue title. I suppose the most basic implementation might be to add a constructor argument (boolean?) to the relevant MeterBinder implementations so users can choose whether to use the otel semantic conventions for the relevant metrics provided by the MeterBinder. A concern I have is around future changes to the semantic conventions and how we could support that. We are planning to work on addressing that with ObservationConventions, but metrics (not through the Observation API) are outside of the scope of that. Making a MeterFilter is another option, but I think that might be more brittle than something in the MeterBinders themselves - it might depend on being configured in a certain order relative to other MeterFilters. So, I think we're still up for discussing options if anyone has ideas.

[alexgenon]

Hi,
@shakuzen last comment summarizes really well the situation.
Not only updating the relevant MeterBinder will be more robust than going for the MeterFilter option, it will also be easier to understand and reduce the cognitive load.

As for the question about the future changes in the semantic convention, why don't we adopt the same approach than the opentelemetry-java project, where a version of the project relies on a set version of the semantic convention ?

[jonatan-ivanov]

As for the question about the future changes in the semantic convention, why don't we adopt the same approach than the opentelemetry-java project, where a version of the project relies on a set version of the semantic convention ?

I think that would be the way to go but I'm not sure I see what question you are replying to.
If it is this one:

Since in Micrometer we consider changing existing meter names and tags a breaking change, I'm not sure how we would do this outside a new major version. Any ideas?

I'm afraid what you are suggesting does not help, changing the existing meter names is still a breaking change.