[jmx-scraper] Support scraping from jolokia over HTTP

[breedx-splk]

Related to #1362.

See also this issue in the collector-contrib repo: open-telemetry/opentelemetry-collector-contrib#41270

Some users want to run the jolokia agent, which can expose mbeans and jmx metrics over http+json. Right now, I think that the jmx-scraper really only supports the java standard rmi connector, so it could be helpful if the scraper was able to do its scraping via http, specifically targeting the jolokia endpoints.

I suspect the implementation isn't too bad, but I'm not sure how often the jolokia wire format changes or how much of a long-term maintenance and testing burden this might be.

[trask]

Some users want to run the jolokia agent, which can expose mbeans and jmx metrics over http+json.

if they're willing to run an agent already, maybe they can switch to otel java agent? (now what we're building out equivalent support for exporting directly and scraping)

[breedx-splk]

Some users want to run the jolokia agent, which can expose mbeans and jmx metrics over http+json.

if they're willing to run an agent already, maybe they can switch to otel java agent? (now what we're building out equivalent support for exporting directly and scraping)

I hear ya. I will admit that I don't fully understand why someone would be willing to run jolokia agent but shy away from an (otel) instrumentation agent...but I guess those people exist?

[SylvainJuge]

I think that scraping JMX metrics from Jolokia endpoint is definitely not a trivial effort, so unless there are strong arguments to implement it I would suggest to NOT do it.

My main points are the following:

• may add an extra dependency if we use the recommended java client
• jolokia does not provide a standard JMX (JSR-160) implementation, so the way to interact with JMX would be completely different from current implementation
• would require to add testing for this setup, which could be tedious/error-prone as the implementation is completely distinct from the JMX one
• this potentially brings all the complexity and configuration options that any jolokia client might have, which we can infer from the current list of jolokia java client options.

The following alternatives are already possible:

• use instrumentation agent, which can be deployed alongside jolokia agent if needed
• use jmx-scraper remotely from another host, which requires to have remote JMX and network access
• use jmx-scraper locally on the host/app, which still requires to configure remote JMX access on the target JVM.

[breedx-splk]

I think @SylvainJuge makes some salient points on this topic, so I'm happy to close. If someone else would like to revisit this in the future, I'd be happy to discuss...but I do agree that the maintenance burden probably shadows the amount of people who actually want this. 👍🏻