Description
The OTLP metric transformation for exponential histograms copies Scale and ZeroCount but does not copy metricdata.ExponentialHistogramDataPoint.ZeroThreshold into the OTLP ExponentialHistogramDataPoint. Consequently, both the gRPC and HTTP metric exporters always transmit the protobuf default of 0, even when a producer supplies a non-zero threshold.
This loses part of the metric data and changes how the receiving system interprets the zero bucket. The existing transform fixtures already use input thresholds of .01 and .02, but the expected protobuf fixtures omit the field. Exponential histogram transformation was introduced in #4222.
Environment
- OS: Linux (the behavior is platform-independent)
- Architecture: amd64
- Go Version: 1.26.4
- opentelemetry-go version:
0de413a318cb52629baefb89a1554a905e105aa3
Steps To Reproduce
Add this regression test to internal/shared/otlp/otlpmetric/transform/metricdata_test.go.tmpl and regenerate the gRPC and HTTP transform packages:
func TestExponentialHistogramDataPointsPreservesZeroThreshold(t *testing.T) {
const want = 0.01
got := ExponentialHistogramDataPoints(
[]metricdata.ExponentialHistogramDataPoint[float64]{{ZeroThreshold: want}},
)
require.Len(t, got, 1)
assert.Equal(t, want, got[0].ZeroThreshold)
}
Run the generated tests for both exporters:
cd exporters/otlp/otlpmetric/otlpmetricgrpc
go test ./internal/transform -run '^TestExponentialHistogramDataPointsPreservesZeroThreshold$' -count=1
cd ../otlpmetrichttp
go test ./internal/transform -run '^TestExponentialHistogramDataPointsPreservesZeroThreshold$' -count=1
Both tests currently fail with an expected value of 0.01 and an actual value of 0.
Expected behavior
Both OTLP metric exporters should preserve ZeroThreshold exactly when converting an exponential histogram data point to OTLP.
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.
Description
The OTLP metric transformation for exponential histograms copies
ScaleandZeroCountbut does not copymetricdata.ExponentialHistogramDataPoint.ZeroThresholdinto the OTLPExponentialHistogramDataPoint. Consequently, both the gRPC and HTTP metric exporters always transmit the protobuf default of0, even when a producer supplies a non-zero threshold.This loses part of the metric data and changes how the receiving system interprets the zero bucket. The existing transform fixtures already use input thresholds of
.01and.02, but the expected protobuf fixtures omit the field. Exponential histogram transformation was introduced in #4222.Environment
0de413a318cb52629baefb89a1554a905e105aa3Steps To Reproduce
Add this regression test to
internal/shared/otlp/otlpmetric/transform/metricdata_test.go.tmpland regenerate the gRPC and HTTP transform packages:Run the generated tests for both exporters:
Both tests currently fail with an expected value of
0.01and an actual value of0.Expected behavior
Both OTLP metric exporters should preserve
ZeroThresholdexactly when converting an exponential histogram data point to OTLP.Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.