JMX Metrics with yaml: needed unit conversion mechanism

[robsunday]

Many JMX enabled applications provides duration metrics with milliseconds unit, while semconv recommends using seconds.
Unit conversion mechanism is needed in order to fully support semconv. This mechanism must be usable from JMX metrics definition YAML files.

The final solution will be discussed, however there are some proposals already:

1. unitConverted YAML key that would replace unit wherever conversion is needed. It should take a value from predefined enumeration of possible conversions, like ms_to_s, ns_to_s, etc.

      processingTime:
        metric: processingTime
        type: counter
        unitConverted: ms_to_s
        desc: Total time for processing all requests

2. Similar unitConverted YAML key but with different syntax. It would have 2 nested key/values: from indicating unit reported by the application, and to indicating required target unit.

      processingTime:
        metric: processingTime
        type: counter
        unitConverted:
            from: ms
            to: s
        desc: Total time for processing all requests

3. Optional sourceUnit YAML tag that would indicate that there should be a conversion performed from this unit to the one specified in unit tag.

      processingTime:
        metric: processingTime
        type: counter
        sourceUnit: ms
        unit: s
        desc: Total time for processing all requests

if requested unit conversion is not possible then error should be reported after YAML file is loaded.

[SylvainJuge]

I have a slight preference for option 3 for the following reasons:

• it just adds a single attribute and not a nested structure
• the values for sourceUnit and unit are the same so we don't need further documentation, even if ms_to_s value is pretty explicit.

[SylvainJuge]

Also, one thing that was briefly mentioned in the SIG meeting is that when modifying existing metrics changing their unit (and the captured values) would be considered to be a breaking change, and could also imply changing their metric names to prevent unexpected results.

[robsunday]

I'm too leaning towards option 3. Besides what was already mentioned - it seems to be the easiest to implement.

[SylvainJuge]

@robsunday as #13448 is now merged I'll chose this.