Delta exponential histogram never goes back to the maximum scale after a wide-range interval
维护者通常 2 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 88/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
调研方向
从 opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/aggregation.py 中的 _ExponentialBucketHistogramAggregation.collect 及其 DELTA→DELTA 分支开始。使用提供的脚本重现该问题，然后检查 metrics 测试以找到合适的回归测试位置。完成的标准是，后续的单值 delta 区间能够恢复到最大 scale，同时不破坏现有的 metrics 测试套件。
由索引模型根据 Issue 内容生成。
描述
Describe your environment
OS: macOS (arm64)
Python version: 3.12
SDK version: main at 18d7e24 (opentelemetry-sdk installed from source)
API version: main at 18d7e24
What happened?
With DELTA temporality, the exponential histogram aggregation lowers its scale when an interval's values span a wide range, but never raises it again. Collection resets the buckets but not self._mapping (_ExponentialBucketHistogramAggregation.collect, the DELTA→DELTA branch in opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/aggregation.py). So every later delta point keeps the lowest scale any earlier interval needed, even when it holds a single value.
The SDK spec says: "When the histogram contains not more than one value in either of the positive or negative ranges, the implementation SHOULD use the maximum scale." A delta point covers only its own interval.
Steps to Reproduce
from opentelemetry.sdk.metrics import Histogram, MeterProvider
from opentelemetry.sdk.metrics.export import AggregationTemporality, InMemoryMetricReader
from opentelemetry.sdk.metrics.view import ExponentialBucketHistogramAggregation, View
reader = InMemoryMetricReader(preferred_temporality={Histogram: AggregationTemporality.DELTA})
provider = MeterProvider(
metric_readers=[reader],
views=[View(instrument_name="latency", aggregation=ExponentialBucketHistogramAggregation())],
)
hist = provider.get_meter("demo").create_histogram("latency")
def point():
return reader.get_metrics_data().resource_metrics[0].scope_metrics[0].metrics[0].data.data_points[0]
hist.record(1e-6)
hist.record(1e6)
print(point().scale) # interval 1: 2
for _ in range(3):
hist.record(5.0)
print(point().scale) # each later interval holds one value: 2, 2, 2
Expected Result
Each interval after the first holds a single value, so it's exported at the maximum scale (20 by default), with positive.offset = 2434718.
Actual Result
Every later interval is exported at scale 2, with positive.offset = 9. That bucket is (4.757, 5.657], a relative error of about 8.6% instead of about 3.3e-7 at scale 20. It never recovers.
In a worse case, one interval that records 1e-300 and 1e300 pins later intervals at scale -4. After that, four measurements of 10, 12, 15 and 20 ms all land in the single bucket (2^-16, 1].
Additional context
Adding self._mapping = self._new_mapping(self._max_scale) in that DELTA→DELTA branch, next to the bucket reset, restores the maximum scale for every interval. With it, the reproduction above prints 20 for each later interval, and the outlier case goes back to scale 7 with the four values in separate buckets. The 335 tests in opentelemetry-sdk/tests/metrics pass with and without the change, so none of them currently covers this.
For comparison, jmacd noted during review of #2964 that when the structure goes from 0 measurements to 1, "the scale is supposed to reset to the maximum scale again".
Found while auditing the metrics SDK with Claude Code. The outputs above come from running the script against main at 18d7e24.
Would you like to implement a fix?
Not at the moment. The one-line change above is what I tested, and anyone is welcome to pick it up.
- 主要语言
- Python
- 星标
- 2.7k
- 派生
- 1k
- 平均合并
- 3 天 5 小时
- 30 天内合并 PR
- 45
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
open-telemetry/opentelemetry-python 的其他 Issue
-
W3CBaggagePropagator.extract ignores all but the first baggage header可能已有人在做 @knowprasad 于 1 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 78/100
open-telemetry/opentelemetry-python#5811 ·
维护者通常 2 天内回复
-
难度 1/5 1 小时以内 新手友好度 70/100
open-telemetry/opentelemetry-python#5700 · 1 条评论 ·
维护者通常 2 天内回复
-
Tests in test_metric_reader_storage.py assert on process-global mock state instead of on the storage under test可能已有人在做 @ocelotl 于 45 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
open-telemetry/opentelemetry-python#5638 ·
维护者通常 2 天内回复
-
`SpanProcessor.on_end` exceptions escape cleanup and replace application exceptions可能已有人在做 @somuai 于 49 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 84/100
open-telemetry/opentelemetry-python#5624 ·
维护者通常 2 天内回复
-
PeriodicExportingMetricReader discards its shutdown timeout可能已有人在做 @dwin-gharibi 于 61 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 78/100
open-telemetry/opentelemetry-python#5574 · 1 条评论 ·
维护者通常 2 天内回复
查看 open-telemetry/opentelemetry-python 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
enhancement good first issue
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
iceboundrock/AutoForge#304 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 72/100
fossasia/visdom-dev#77 ·
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
aws-cloudformation/cfn-lint#4890 ·
维护者通常 2 天内回复