open-telemetry
[jmx-scraper] Package jmx scraper as a deb/rpm/tar.gz package
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
Hey @atoulme! I'm trying to get more involved in the community. I wonder if this issue is still needed to be fixed?
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.
@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.
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?
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.
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?
are we expecting most users to use it via the collector integration?
I apologize as I'm not sure what you refer to
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/jmxreceiver
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/jmxreceiver
Right, the page says:
jar_path (default: /opt/opentelemetry-java-contrib-jmx-metrics.jar)
Supported by: jmx-scraper, jmx-gatherer
The path for the JMX JAR (JMX Metric Gatherer or JMX Scraper) to run. This must represent a released version 1.9+ of the jar, which can be downloaded from [github](https://github.com/open-telemetry/opentelemetry-java-contrib/releases).
So the jar file is offered separately. It is not installed with the collector. The collector also doesn't install the necessary JRE.
It is not installed with the collector
yeah, but I'm not clear how a deb/rpm package makes it easier to set up the collector jmxreceiver integration?
We actually won't need a specific collector receiver in the future. The JMX scraper can run on its own and export data over OTLP to any endpoint. The IBM MQ jar is the same way. I expect users will want to install those and manage them independently of the collector.
A good example of dissonance here: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/40794#issuecomment-3259592947