OpenTelemetry指标：混淆 CUMULATIVE 与 DELTA 为何会酿成大祸 🚨

8 月 26, 2026

—

cslab

in IT Security

“我明明在看指标……为什么数字看起来跳动得这么奇怪？🤔”

“为什么在Prometheus中看起来正常的图表，在其他监控工具中却显示异常？”

如果您曾有过这些困惑，那么您可能错过了OpenTelemetry中最核心的概念之一。那就是“Aggregation Temporality（聚合时间性）”。

今天，我们将彻底剖析许多人容易混淆的两个概念：“Aggregation Temporality”和“Temporal Reaggregation”。如果不能区分它们，数据可能会完全失真！

🕵️‍♂️ 数据的本质：Aggregation Temporality（聚合时间性）

首先，让我们了解“聚合时间性”，它定义了数据值是“从哪个时间角度”来看的。这是对一个根本问题的回答：“这个数字代表的是从何时到何时的数据？”

它有两种类型：

A) CUMULATIVE（累积）：到目前为止所有值的总和 📈

含义： 这是进程（应用程序）启动后，到目前为止发生的所有值的累积总和。
特点： 值会持续增加或至少保持不变（对于计数器而言）。
比喻： 想象一下汽车的总里程表（Odometer） 🚗。即使你关闭再启动引擎，总里程也不会重置，而是持续累积。这就是它的原理。
示例： http_requests_total 计数器如您所见，值会持续累积。

# 10:00 - 10:01 (发生5次请求)
- 보고되는 값: requests_total = 5

# 10:01 - 10:02 (额外发生3次请求)
- 보고되는 값: requests_total = 8  (기존 5 + 신규 3)

# 10:02 - 10:03 (额外发生10次请求)
- 보고되는 값: requests_total = 18 (기존 8 + 신규 10)

B) DELTA（增量/变化量）：恰好是此刻的变化 📊

含义： 仅指自上次报告以来，本次报告周期内发生的变化量。
特点： 每个报告周期都有一个独立的值。
比喻： 就像汽车的分段里程表（Trip Meter） 🛣️。在特定地点重置，只测量到下一个目的地的距离，原理完全相同。
示例： http_requests_total 计数器它清晰地显示了每个时间点的变化量。

# 10:00 - 10:01 (发生5次请求)
- 보고되는 값: requests_total = 5

# 10:01 - 10:02 (发生3次请求)
- 보고되는 값: requests_total = 3

# 10:02 - 10:03 (发生10次请求)
- 보고되는 값: requests_total = 10

👨‍🍳 数据的处理方法：Temporal Reaggregation（时间再聚合）

好了，现在我们了解了数据的“本质”，接下来是了解如何“处理”这些数据。

“时间再聚合”是改变已收集指标数据的时间粒度（granularity）的过程。例如，将以1分钟为单位精细收集的数据，合并成10分钟为单位的较大块数据，以创建摘要。为什么要这样做？为了节省数据存储空间，并在查看长期趋势时提高查询速度。🚀

核心要点：再聚合方式完全取决于原始数据的Temporality是CUMULATIVE还是DELTA！

A) DELTA数据的再聚合：直接相加即可！ ✅

方式： 非常简单。只需直接相加即可。➕ 将每个区间的变化量全部相加，即可得到整个区间的变化量。
示例： 让我们将五个1分钟的DELTA值合并，创建一个5分钟的DELTA值。

# 每1分钟的DELTA值
1분차: 5
2분차: 3
3분차: 10
4분차: 2
5분차: 7

# 5分钟内的总DELTA值
5min_delta = 5 + 3 + 10 + 2 + 7 = 27

B) CUMULATIVE数据的再聚合：减法的魔力 🔮

方式： 如果直接相加，那可就糟了！必须用最后时间点的累积值减去最初时间点的累积值，才能得到该期间内真正的变化量（DELTA）。
示例： 让我们用1分钟间隔的CUMULATIVE数据计算5分钟内的变化量。

# 各时间点的CUMULATIVE值（总里程）
T0 (시작): 100
T1: 105
T2: 108
T3: 118
T4: 120
T5 (끝): 127

# 计算5分钟内的总变化量（DELTA）
5min_delta = (T5의 누적값) - (T0의 누적값)
           = 127 - 100
           = 27

❌ 如果直接相加会怎样？ 你会得到一个巨大的数字，比如 100 + 105 + 108 + 118 + 120 + 127。这会变成“总和的总和”，一个毫无意义的数据。数据完全失真的瞬间！

💡 整体背景：那么，这为什么重要？

好的，现在我们知道了这两个概念的区别。但为什么它如此重要呢？

区分Aggregation Temporality（聚合时间性）Temporal Reaggregation（时间再聚合）


区分	Aggregation Temporality（聚合时间性）	Temporal Reaggregation（时间再聚合）
核心问题	🕵️‍♂️ “这个值是累积值还是变化量？”	👨‍🍳 “这些数据应该如何合并？”
决定主体	SDK （应用程序代码端）	Collector, Backend （采集/存储系统端）
概念	数据的 ‘根本属性’	基于该属性的 ‘数据处理方法论’

简单来说，当应用程序（SDK）创建指标时，它会附带一个标签，说明“这是累积值（CUMULATIVE）！”。然后，接收数据的采集器（Collector）或后端（Backend）会根据这个标签正确判断：“啊，这是累积值！那么在再聚合时，我应该用减法而不是加法！”并相应地进行处理。

如果这个约定没有被遵守，或者系统未能正确理解Temporality，就会发生可怕的事情。

将 CUMULATIVE 数据像 DELTA 一样相加 → 图表会显示出荒谬的飙升，冲破天际。😱
将 DELTA 数据误认为是 CUMULATIVE → 值会看起来一直徘徊在0附近，从而错过实际的变化。😥

最终，对这两个概念的准确理解和区分是准确监控、可靠告警以及正确数据分析的最基本前提条件。

结论：了解数据属性，正确处理数据！

“Aggregation Temporality”是数据的身份（What），而“Temporal Reaggregation”是与该身份相符的处理方法（How）。如果您正在基于OpenTelemetry观察系统，那么始终了解您正在查看的数据的“Temporality”是什么，并确保正在进行正确的“Reaggregation”至关重要。

现在，再次查看您的指标图表。您的数据是否因为错误的处理方法而失真了呢？😉