jmx receiver: migration plan to use jmx-scraper

[SylvainJuge]

Component(s)

receiver/jmx

Describe the issue you're reporting

This relates to #34825.

The path we took to implement this involved the creation of a new jmx-scraper artifact which is now published in maven central with version 1.46.0 of java contrib.

The next step is to allow users of jmxreceiver to start using it.

On the collector/jmxreceiver side @rogercoll is likely to handle most of the contributions, on the java side @SylvainJuge and @robsunday can help with testing and implementation details of jmx-scraper.

Steps

1) Provide the ability to use jmx-scraper with jmxreceiver

• add an option to switch between jmx-gatherer (still default for now) and jmx-scraper (new)
• modify the reference artifact hashes to include jmx-scraper + update automation that updates it
• provide documentation and start defining a migration path for existing users

2) Add an option to allow using custom metric definitions yaml files:

This is a new feature that wasn't previously available with jmx-gatherer because it relied on groovy scripts which could lead to code execution.

This depends on aligning the config name + using multiple custom yaml files (in jmx-scraper):

• [jmx-scraper] align custom configuration with instrumentation opentelemetry-java-contrib#1662

Future steps: providing ability to select which variant of metrics definitions to use

Those are here mostly for documentation and to give a glimpse at future direction, they will need to be refined in the future.

UPDATE: I opened another issue to further discuss the possible options.

• we currently have 3 metrics definitions: 2 in yaml with jmx-gatherer and jmx-insight (in java instrumentation), and one in groovy.
• we need to define a single location to define them in yaml that will be shared between jmx-scraper and java instrumentation
• we need to align the metrics definitions, which is expected to take a bit of time and effort and will introduce some breaking changes.
• we need to provide the ability to switch the version of the yaml files that are being used, or at least to toggle between "current yaml definition in jmx-scraper that is mostly 1:1 to the jmx-gatherer groovy" and "common yaml definitions shared with instrumentation"

[github-actions]

Pinging code owners:

• receiver/jmx: @atoulme

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[SylvainJuge]

Status update:

• YAML metrics definitions are being added to instrumentation, they will be inherited by jmx-scraper
• jmx-scraper now provides the otel.jmx.target.source configuration option to select the priority between existing definitions (close to jmx-gatherer) and reusing the ones from instrumentation (for now there is none merged yet).

There will still be 3 places for JMX metrics definitions, but 2 of them are expected to be static:

• JMX Gatherer groovy definitions, deprecated.
• JMX Scraper legacy YAML definitions, very close to JMX Gatherer and provided for compatibility only
• Java Instrumentation YAML definitions: the new reference for up-to-date and maintained metrics definitions, is automatically inherited by JMX scraper.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/jmxreceiver: @atoulme @rogercoll

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[SylvainJuge]

This issue has been flagged as inactive due to higher priorities, but I'm still hoping we'll make progress on it soon.

As an alternative, we could also think about shading the jmx-scraper directly into the jmx-gatherer jar and use that to replace the existing jmx-gatherer implementation with jmx-scraper. However that would be just working around the change and would likely push us to maintain jmx-gatherer for even longer as the artifact would still be needed. So, if possible I'd like us to do it "the proper way" by directly using jmx-scraper in place of jmx-gatherer, this would also enable to provide new configuration options to end-users.

[atoulme]

@rogercoll are you looking to help with this issue? You are mentioned in the initial comment. OK to assign to you?

[rogercoll]

@rogercoll are you looking to help with this issue? You are mentioned in the initial comment. OK to assign to you?

Sounds good, planning to work on it soon.