Datadog速率类型Metric：as_rate()聚合与per_second()的差异及选型疑问

三个表达式的核心差异 #

先明确前提：你设置的绘制间隔是10秒，当时间范围扩大时，Datadog会把多个原始数据桶合并成更大的显示桶（也就是rollup），三者的差异全在rollup阶段的聚合逻辑：

1. sum:<metric-name>.as_rate().rollup(avg) #

• 执行步骤：
  1. 先把所有主机/维度的<metric-name>数值求和，得到每个原始桶的总事件数
  2. 将总事件数转换成每秒速率（总事件数 ÷ 原始桶的时长）
  3. 合并显示桶时，取所有原始桶速率的平均值作为最终显示的速率

2. sum:<metric-name>.as_rate().rollup(sum) #

• 前两步和上面完全一致，但rollup阶段是直接把所有原始桶的速率累加。这是典型的错误用法：速率是「每秒事件数」，累加多个时间桶的速率没有任何业务意义——时间范围越大，合并的原始桶越多，数值就会越虚高，这就是你看到时间一长这个数值明显变大的原因。

3. per_second(sum:<metric-name>.as_count()) #

• 执行步骤：
  1. 先确认<metric-name>是计数类型，再把所有维度的数值求和，得到每个原始桶的总事件数
  2. 计算每秒速率；当需要rollup时，会先把显示桶内所有原始桶的总事件数求和，再除以显示桶的总时长，得到这个大桶的平均每秒速率

你的场景匹配与误区纠正 #

你要的是「时间桶内总事件数 ÷ 桶时长」的吞吐量（events/s），之前的误区主要是对rollup逻辑和指标类型的匹配没搞透：

为什么sum:<metric-name>.as_rate().rollup(avg)和累积值差值结果不一样？ #

常见原因有两种：

• 如果<metric-name>是累积计数器（数值单调递增的总事件数）：你用sum后，as_rate()是先给每个主机单独算速率再求和，而你手动用累积值差值算的是总累积值的速率，当各主机的事件增长节奏不一样时，两者结果就会有差异。这种情况应该用sum:<metric-name>.as_count().rate()来计算总速率。
• 如果<metric-name>是增量计数（每次上报的是当前周期内的事件数）：rollup(avg)取的是原始小桶速率的平均值，而你手动算的是更大时间范围的整体平均速率，当原始桶的速率波动大时，局部平均和整体平均自然会有差距。

推荐表达式 #

针对队列吞吐量场景，优先选per_second(sum:<metric-name>.as_count())：

• 它完全符合你「总事件数 ÷ 桶时长」的需求，不管时间范围多大，rollup时都会自动基于总事件数计算准确的每秒速率
• 相比sum:<metric-name>.as_rate().rollup(avg)，它避免了因原始桶速率波动导致的平均偏差，逻辑更直接靠谱

内容的提问来源于stack exchange，提问作者Sherif Abdel-Naby