PID `rx_pid` dimension with JMX Extension 2.0

[StephP]

With 1.0 extensions, it was possible to add the `rx_pid` dimension under metrics definition json file. The 2.0 extensions JMX conversion tool removes this dimension from definition yaml file (metric / jmx group). By default OneAgent add several dimensions which might not be relevant for our metric. Questions are:

• How to migrate the `rx_pid` dimension? It seems not yet available anymore
  
• Is it possible to disable some default dimensions?

[JamesKitson]

Correct, it is still not possible to add that PID dimension and won't be until if/when that capability is added to the Java JMX data source.

For default dimensions, if you mean the ones that are automatically added in the case of JMX like the host details (which allow for tying the metric data points to that host) then no that is not possible. If you mean some attribute of the Mbeans you should have total control over that.

[StephP]

Thanks @JamesKitson, PID it is already available through java.lang:type=Runtime, attribute Pid, but not visible by my custom extension as I am querying my own MBean so I cannot add it as a dimension in that query:

jmx:
  groups:
    - group: jmx
      subgroups:
        - subgroup: my.package:type=library,*
          query: my.package:type=library,*
          dimensions:
            - key: ...

Can we add dimension Pid from java.lang:type=Runtime which I think is equivalent to rx_pid?

For second question, I mean:

• dt.entity.process_group_instance
• dt.entity.process_group
• dt.entity.host
• dt.entity.container_group_instance
• dt.metrics.source
• dt.extension.config.id

Only dt.entity.process_group_instance is relevant for us and is already specified in metric definition with:

- key: my.metric
    metadata:
      sourceEntityType: process_group_instance

The others are not relevant.

[JamesKitson]

In EF1 that happened automatically and wasn't dependent on some Mbean being available that had the PID, that's what is needed to enable this.

In your case if you're saying there is a PID attribute on a different Mbean than the one you want to ingest the metrics for  you wouldn't be able to use that. In most declarative data sources you would be able to define a top level group where some dimensions are set and then subgroups will automatically get those dimensions as well but that is not supported for JMX. Each subgroup is self-contained and can only use the properties an attributes of the given Mbean for metrics and dimensions.

For the second part, all those are dimensions that would be automatically added by the data source, there's no control over that. Populating all of them provides the most flexibility for possible use cases. The sourceEntityType that you are setting normally only matters if you are detecting some custom topology entities from a given metric and want things like management zones to work properly and associate the metric with the entity. In this case, that shouldn't be necessary or affect anything.