jmx metrics generate weaver yaml from jmx metrics yaml

[SylvainJuge]

Relates to open-telemetry/opentelemetry-java-contrib#2362

Using weaver yaml as source of truth and generating JMX metrics yaml from it adds extra complexity.

We could however easily extend the JMX metrics yaml and generate the weaver yaml directly from it, which also provides the following benefits:

• minimal impact on current implemetation
• should be quite straightforward to generate the weaver yaml
• allows to generate weaver yaml with user-provided JMX metrics definitions
• allows to reuse the feature directly into jmx-scraper in contrib, hence allowing to easily cover all the "legacy" definitions that are close to the deprecated "jmx-gatherer"
• should be integrated into the current build system

EDIT: found that it might be easier to implement once #15220 is merged as it helps to provide a high-level API for JMX metrics without exposing the internal implementation.

[jsuereth]

I think in the long run, you'd be better served using Weaver straight up and generating other yaml if needed from it.

With annotations, you should be able to record JMX-specific information you can use in your templates/codegen, and then the weaver yaml is directly consumable from your git repo if needed (Note: weaver can resolve from git repositories). This can help give you a weaver diff / backwards compatibility and version-to-version break detection story if the weaver.yaml is checked in.

Additionally, we're hoping to have localized / per-instrumentation weaver usage improve get better over time.

cc @open-telemetry/weaver-maintainers for more thoughts

[SylvainJuge]

I think in the long run, you'd be better served using Weaver straight up and generating other yaml if needed from it.

Do you suggest here we should use weaver yaml format to replace the existing JMX metrics format or just generate the JMX metrics yaml from it ?

Do you have any particular scenario on mind where this would be simpler or easier to maintain with this approach ?