document & test jmx metric implicit aggregation

[SylvainJuge]

Fixes #14070

After further investigation, aggregation of values over multiple MBean instances already works as expected, this PR adds proper test and documentation.

This however confirms that using this aggregation with gauge metrics can produce unpredictable results when more than one MBean instance as the "last value" aggregation is being used. Tests and documentation have been updated to reflect this.

[trask]

cc @PeterF778 @robsunday

[PeterF778]

Just thinking about aggregating gauge metrics. Would it make sense to average the values? This would solve the issue with non-deterministic aggregation of multiple values, and it would work as expected when only one value is subject to aggregation.

[SylvainJuge]

Just thinking about aggregating gauge metrics. Would it make sense to average the values? This would solve the issue with non-deterministic aggregation of multiple values, and it would work as expected when only one value is subject to aggregation.

While this would bring some determinism, I think it would still provide unexpected results depending on which metric is being captured:

• for a metric that measures an average: the result is an average of an average
• for a metric that measures a maximum: the result would be an average of two maximums

If we apply this to the context of web/application containers, one hypothetical web server could be to have two connectors, each monitored with its own MBean instance: for example one configured for http traffic and one for https. In practice most of the traffic would happen only on one of those configured connectors, which means the metrics from the other one would be zero. In such case the metrics reported would be half of the actual and expected value.

However, doing so could help to provide a "consistently less wrong value", as in example we could have either the correct expected value or a zero.

[otelbot-java-instrumentation]

🔧 The result from spotlessApply was committed to the PR branch.