[jmxreceiver] Support custom Groovy script to scrape metrics

[ItsLastDay]

Component(s)

receiver/jmx

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

I am using jmxreceiver with target_system: jvm. It exports a lot of metrics.

However, I still lack some metrics:

• number of open file descriptors
• uptime of the JVM

Describe the solution you'd like

I see that the underlying metrics gatherer supports two mutually exclusive configuration paths:

• set otel.jmx.target.system=jvm|kafka|... and get predefined set of metrics
• set otel.jmx.script.groovy=<path to script> and get metrics defined by user

However, jmxreceiver only exposes the first path through target_system field.

I would like jmxreceiver to also have script field, where I would be able to put a custom groovy script.

Describe alternatives you've considered

Currently the documentation suggests that I can build a custom metrics gatherer jar. This is very inconvenient for me, since I only want to run a 10-line Groovy script in addition to the existing jar capabilities.

Additional context

Here is the script that I would be plugging into script field (to be more precise: I would point script to a path of this file) if this functionality existed today:

def runtime = otel.mbean("java.lang:type=Runtime")
otel.instrument(runtime, "jvm.runtime.uptime", "uptime",
        "ms", "Uptime", otel.&longValueCallback)

def os = otel.mbean("java.lang:type=OperatingSystem")
otel.instrument(os, "jvm.fd.open", "open file descriptors",
        "1", "OpenFileDescriptorCount", otel.&longValueCallback)
otel.instrument(os, "jvm.cpu.time", "jvm process cpu time",
        "1", "ProcessCpuTime", otel.&longValueCallback)

I was able to make it work by changing this line to config["otel.jmx.groovy.script"] = "/my_script.groovy".

[github-actions]

Pinging code owners:

• jmxreceiver: @rmfitzpatrick
• receiver/jmx: @rmfitzpatrick

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

[rmfitzpatrick]

@ItsLastDay this limitation is the result of a security review of the component (#9685) that sought to limit arbitrary code execution so only allows the bundled targets to be evaluated. For custom scripts, running the metric gatherer directly and reporting to a Collector instance is required instead of using this receiver alone.

[ItsLastDay]

Oh, I see. Thanks for the context! Closing this issue then.