Component(s)

processor/metricstransform

Description

In OTLP, the sum field on a histogram data point is optional — HasSum() returns false when the sum was not recorded, which happens with Prometheus native histograms when --no-native-histogram-sum is used. When aggregateLabels or aggregateLabelValues operations are applied to histogram metrics, mergeHistogramDataPoints in aggregate.go merges multiple data points into one. On line 257 it calls dp.SetSum(dp.Sum() + dps.At(i).Sum()) unconditionally. Since SetSum always sets HasSum=true, any merged data point where the inputs had no sum ends up with HasSum=true and Sum=0.0 — which is incorrect. The inconsistency is visible in the same function: HasMin and HasMax are both guarded before SetMin/SetMax are called (lines 258-263), but Sum has no equivalent guard. The same issue exists for ExponentialHistogram in mergeExponentialHistogramDataPoints at line 288.

Steps to Reproduce

• Configure metricstransformprocessor with aggregateLabels or aggregateLabelValues on a histogram metric
• Input histogram data points should have HasSum=false (no sum field set)
• Run the collector and observe the output histogram data points

Expected Result

• Merged output DP should have HasSum=false when all input DPs had no sum
• Same behavior as HasMin/HasMax which are already guarded correctly in the same function

Actual Result

• Merged output DP has HasSum=true with Sum=0.0
• The spurious sum of 0 is incorrect and misleads downstream consumers that differentiate between "sum not present" and "sum equals zero"
• Same corruption happens for ExponentialHistogram

Collector version

0.155.0

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}