document & test jmx metric implicit aggregation#14111
document & test jmx metric implicit aggregation#14111trask merged 19 commits intoopen-telemetry:mainfrom
Conversation
…nstrumentation into jmx-metrics-advice
…nstrumentation into jmx-metrics-advice
…nstrumentation into jmx-metrics-advice
…nstrumentation into jmx-metrics-advice
…nstrumentation into jmx-metrics-advice
|
Just thinking about aggregating |
While this would bring some determinism, I think it would still provide unexpected results depending on which metric is being captured:
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. |
…etry/instrumentation/jmx/engine/MetricAggregationTest.java Co-authored-by: Lauri Tulmin <[email protected]>
|
🔧 The result from spotlessApply was committed to the PR branch. |
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
gaugemetrics 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.