OpenTelemetry Rust 中 ObservableGauge 指标数据点泄漏问题分析

问题背景

在 OpenTelemetry Rust 实现中，从 0.24 版本升级到 0.26 版本后，ObservableGauge 及其他异步指标工具出现了一个重要的行为变更。这个变更导致了一个不符合 OpenTelemetry 规范的数据点泄漏问题。

问题现象

在 0.26 版本中，一旦为特定属性组合记录了一个读数，该读数就会在后续的所有收集操作中被持续发送。这意味着：

1. 任何曾经出现过的属性组合都会被永久保留
2. 无法移除不再存在于当前数据中的旧属性
3. 指标数据会随着时间推移不断累积增长

规范要求

根据 OpenTelemetry 规范，对于使用 Delta 或 Cumulative 聚合时间性的异步仪器，MetricReader.Collect 方法应该只接收自上次收集以来记录的测量数据点。这意味着：

• 对于 Delta 时间性：每次收集后应该重置状态
• 对于 Cumulative 时间性：虽然保留历史数据，但对于 Observable 仪器仍应遵循"仅报告当前周期数据"的原则

技术分析

问题的根源在于指标聚合的实现方式。当前实现使用 HashMap 来跟踪所有键值属性组合：

1. Cumulative 时间性：HashMap 被读取但不被清空，导致所有曾经出现过的键值属性组合会被永久保留和报告
2. Delta 时间性：HashMap 会被清空，只有当前周期报告的键值属性组合会被导出

对于 ObservableCounter 和 ObservableGauge 这类异步仪器，规范明确要求无论使用哪种时间性，都应该只导出当前周期报告的键值属性组合。

影响范围

这个问题主要影响以下场景：

1. 使用 Prometheus 导出器（默认强制使用 Cumulative 时间性）
2. 动态变化的属性值场景（如用户ID、会话ID等）
3. 长时间运行的服务，会导致内存和网络流量持续增长

解决方案

正确的实现应该：

1. 对于 Observable 仪器，即使使用 Cumulative 时间性，也应该在收集周期之间进行适当的清理
2. 保持 Delta 时间性的现有行为（清空 HashMap）
3. 修改 Cumulative 时间性的处理逻辑，使其符合 Observable 仪器的特殊要求

最佳实践建议

在问题修复前，用户可以：

1. 考虑切换到 Delta 时间性（注意其与 Cumulative 的不同特性）
2. 定期重启服务来清理累积的指标数据
3. 避免在高基数维度上使用 Observable 仪器

总结

这个问题的本质是指标聚合逻辑没有正确处理 Observable 仪器的生命周期要求。正确的实现应该区分普通仪器和 Observable 仪器在 Cumulative 时间性下的不同行为，确保符合 OpenTelemetry 规范的语义。对于开发者而言，理解指标时间性的差异和仪器类型的影响，对于构建可靠的观测系统至关重要。