Add support for cli params/custom label in groovy script

[jatan28]

Currently, when you are trying to monitor the JVM metrics(using JMX receiver) for multiple processes/applications on a single host, it is impossible to differentiate which process the metrics originated from.
Having support for adding custom labels to the groovy script through command line params or a config would provide the required flexibility to re-use the same groovy script to solve the problem stated above and also give end users the option to add more labels.
Example

 jmx:
 jmx/service1:
  jar_path: /home/opentelemetry-java-contrib-jmx-metrics-0.0.1-SNAPSHOT.jar
  endpoint: localhost:9050
  target_system: jvm
  custom_lables: 
     <label-key>: <label-value>
  collection_interval: 10s

OR

 jmx:
 jmx/service1:
  jar_path: /home/opentelemetry-java-contrib-jmx-metrics-0.0.1-SNAPSHOT.jar
  endpoint: localhost:9050
  groovy_script: test.groovy --labels [<key>:<value>, ...]
  collection_interval: 10s

[rmfitzpatrick]

@jatan28 after looking into this a bit I think the use case you're describing may better match resource attributes than labels for individual points. The metric gatherer uses the autoconfigure sdk extension that provides a property for setting these.

Allowing for arbitrary labels for each datapoint would require wrapping the OTel instrument methods to inject them, and this seems undesirable. The label function feature and labels parameter for recording values should already provide the ability to do this where desired in custom script functionality.

Would it be acceptable for me to add a properties config option in the JMX Receiver that will allow propagating these as system properties?

 jmx/service1:
  jar_path: /home/opentelemetry-java-contrib-jmx-metrics-0.0.1-SNAPSHOT.jar
  endpoint: localhost:9050
  target_system: jvm
  properties: 
     - otel.resource.attributes=my.resource.attr=attrvalue,my.other.resource.attr=othervalue
  collection_interval: 10s

The Collector's configuration library doesn't support case sensitive map keys, so I think this would need to be an array of strings to reduce the potential for unexpected behavior.

[jatan28]

@rmfitzpatrick Yes, this solution would solve the problem in hand. With this and a custom groovy script, we should be able to differentiate the jmx metrics

[rmfitzpatrick]

@jatan28 appears the Collector contrib project has just released a new version with the added functionality in the JMX receiver: https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.28.0

https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/jmxreceiver#properties

Thanks for your patience, and if you run into any issues using it please don't hesitate to open an issue in that project.