[jmx-scraper] Package jmx scraper as a deb/rpm/tar.gz package

[atoulme]

Component(s)

jmx-scraper

Is your feature request related to a problem? Please describe.

There is no installation package for the JMX scraper at this time.

Describe the solution you'd like

Package the JMX scraper tooling as a deb/rpm/tar.gz to allow installation in unix systems.

It should come with the following features:

• Systemd unit file
• Default config file

Optionally, the package should have dependencies such as jre spelled out for installation as part of this installation method.

Describe alternatives you've considered

No response

Additional context

No response

[mcmho]

Hey @atoulme! I'm trying to get more involved in the community. I wonder if this issue is still needed to be fixed?

[atoulme]

yes please feel free to take it.

[SylvainJuge]

While I definitely see some benefits to provide a one-liner command to install jmx-scraper, doing so also brings some extra complexity and maintenance challenges. In particular, there are potentially lots of architectures/distributions/variants to test and support, as we can see with the collector install instructions.

As an alternative, instead of providing "ready to use" packages for multiple distributions/OSes, do you think we could provide instructions how to deploy jmx-scraper as a system service ?

EDIT: I'm not familiar with most of the distribution-specific archive formats and descriptors, and I am not sure any of the current maintainers of jmx-scraper is. However, providing a few shell scripts and instructions to help run it would definitely be something most of the maintainers would be able to.

[atoulme]

@SylvainJuge anything towards the end goal described in this issue helps.

[mcmho]

@SylvainJuge Here is a proposed change for this issue - https://github.com/open-telemetry/opentelemetry-java-contrib/pull/2099/files Generally systemd file is pretty universal across all flavors of modern linux distributions.

Please decide and let me know whether we want to proceed with this commit or not.

[trask]

While I definitely see some benefits to provide a one-liner command to install jmx-scraper, doing so also brings some extra complexity and maintenance challenges. In particular, there are potentially lots of architectures/distributions/variants to test and support, as we can see with the collector install instructions.

I have the same sentiment.

@atoulme how important is this? are we expecting most users to use it via the collector integration?

[breedx-splk]

While I definitely see some benefits to provide a one-liner command to install jmx-scraper, doing so also brings some extra complexity and maintenance challenges. In particular, there are potentially lots of architectures/distributions/variants to test and support, as we can see with the collector install instructions.

I have the same sentiment.

Adding my +1 here too. I don't think we should do this. I think that providing a systemd file and instructions on how to use it is probably fine, but I don't think we should provide additional packaging or deploy artifacts.

[atoulme]

The collector is in go and is statically compiled for each OS and architecture, this is a Java application that is going to work with Java 11+, iirc. I don't think the comparison holds.

@atoulme how important is this? are we expecting most users to use it via the collector integration?

I apologize as I'm not sure what you refer to. Please correct me if I am missing something - I opened this issue in part to test my assumptions and make sure I hear back if this is addressed already elsewhere, or if there's a community need for this development.

To go back to your original question, the jar files produced for the jmx-scraper or the jmx-metrics-gatherer are not currently shipping with the collector. You can see the Dockerfile of the collector contrib distribution: https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-contrib/Dockerfile

You can also see how the RPM and deb of the collectors are built here: https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-contrib/.goreleaser.yaml

The JMX scraper is a standalone Java application that sends data over OTLP to a remote endpoint, and its lifecycle is not attached to the collector.

At this time, the only way to consume the JMX jars is to download and install them from Maven Central or maybe release artifacts. This slows down the maturation of the solution as adoption requires an indirect distribution channel such as a vendor-based solution or a dedicated homegrown set-up.

I don't mind if this project prefers to stay uninvolved with the complexities of shipping software that can be directly adopted by end users. Is there a separate location where such a development may occur?