[jmx-scraper] Create weaver model for metrics of "activemq" target system

[mcmho]

This one is a sub-issue of https://github.com/open-telemetry/opentelemetry-java-contrib/issues/2072

Create a Weaver model for the "activemq" target systems of the metrics defined by jmx-scraper, so we can work to standardize them.

Here is an example of use that introduces a Weaver model to back the existing yaml files rather than directly replacing them: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/40698

We should make this is backwards-compatible and does not break the existing functionalities while expressing telemetry data in weaver model.

[SylvainJuge]

I am currently working on improving/aligning jmx metrics between contrib and instrumentation for active mq with https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/14278, so the current metrics (in contrib and in instrumentation) are about to change soon.

I am not familiar with weaver nor the expected benefits of having a weaver model for those metrics, but the changes introduced by the current work are breaking changes which the weaver might not be able to handle yet: adding/removing attributes, values conversions, units change, ...

JMX Metrics are defined in multiple places, but we are trying to simplify this, does the goal is to provide a way to migrate between those ?

• metrics in jmx-gatherer (contrib, groovy, deprecated)
• metrics in jmx-scraper (contrib, yaml, provided for migration from jmx-gatherer)
• metrics in instrumentation/jmx-metrics (instrumentation, yaml, should be the new reference)

I think it would however be interesting to have a weaver model after those changes are made, so future changes could be handled in a more graceful way.

Also, as the "reference" definitions themselves are now part of instrumentation I think it would be better to handle this directly into the java instrumentation repository.

[mcmho]

@atoulme Can you chime in on this?

[atoulme]

Please don’t break metrics. Please document them using weaver and use weaver to map the translation. Please version metrics with major version increments if you intend to break them.

[SylvainJuge]

With jmx-scraper, there are two sets of metrics depending on the value of otel.jmx.target.source configuration option

• legacy: those are likely to remain as-is, but we can document them with weaver yaml
• instrumentation: those are inherited from instrumentation and will continue to evolve over time, the metrics version is thus linked to the upstream instrumentation version.

So, for the migration between legacy and instrumentation, or the evolution of instrumentation over time, having a proper schema would definitely be helpful here. We could even provide one to help for migration from jmx-gatherer to jmx-scraper with that by adding an artificial older version in the jmx-scraper schema.

Also, I have just opened https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/15196 to attempt to generate the weaver descriptors from the JMX metrics yaml.