Datadog中能否使用单一指标同时追踪成功与失败事件

核心结论 #

不建议采用「成功加1、失败加0，总请求减成功数算失败」的方案，保留拆分指标或改用带状态标签的单指标才是可落地的做法。

先解释你遇到的sum和count聚合结果不一致的问题 #

你观察到的现象本质是对两个聚合函数的计算逻辑理解有偏差：

• sum:a.b.c.success{*}.as_count() 是对时间窗口内所有上报点的指标值做求和，如果你成功报1、失败报0，这个值确实等于窗口内的成功请求总数。
• count:a.b.c.success{*}.as_count() 统计的是时间窗口内监控系统收到的指标上报总次数，完全不关心你上报的数值是多少——哪怕你上报的是0，只要上报请求被服务端收到，count就会加1。
  你看到每个时间片count增量固定为10，说明当前测试场景下每个统计时间片正好产生10次请求，每次请求都会触发一次指标上报，所以统计上报次数的count结果固定为10，比sum高的部分就是上报值为0的失败请求数量。

注意：绝对不要依赖count聚合统计总请求数。count统计的是上报事件的数量，一旦后续开了指标采样、上报链路出现丢包、或者上报逻辑调整为不是每次请求都发一个点，count的结果就会完全失真，所有业务指标的统计都必须基于指标值的sum聚合，不能靠上报次数计算。

为什么不推荐你说的单指标差值方案 #

这个方案看起来省了一个指标，实际隐患非常多：

• 零值上报存在兼容风险
  绝大多数时序监控系统（包括Datadog、Prometheus等主流实现）对counter类型指标默认会丢弃值为0的上报点——因为counter是单调递增的，0值通常被判定为无意义的指标重置点。一旦失败时上报的0被系统丢弃，你既没法通过sum拿到准确的成功数，也没法通过count拿到准确的总请求数，最后算出来的失败数完全不准。
• 没有任何成本优势
  这个方案要求你失败时也要上报一条值为0的指标，和直接给failure指标加1的上报开销、存储开销完全一致，根本达不到精简指标的目的。
• 扩展性极差
  后续如果需要按错误码、错误类型、请求来源等维度拆分失败原因，这个方案完全无法支撑——你没法给值为0的点附加不同的错误标签后再做聚合计算，总不能为了区分错误类型给每种错误设一个固定的0值偏移量，完全不符合指标设计的基本逻辑。
• 语义模糊容易出错
  失败数靠差值计算属于隐式逻辑，新接手的开发、运维人员很容易直接拿success的sum值当总请求数配置告警、做大盘，导致故障漏报、统计数据错误。

推荐的落地方式 #

二选一即可，都比差值方案靠谱：

• 保留现有两个独立指标a.b.c.success和a.b.c.failure，对应事件触发时给对应指标加1即可。语义直白，计算简单，失败数直接sum failure指标就能拿到，不需要额外做差值运算。
• （更推荐，长期维护成本更低）收敛为一个统一的请求总量指标，比如a.b.c.request_total，增加status标签区分结果：成功时上报{status:success}值加1，失败时上报{status:failure}值加1。需要统计成功数就聚合status=success的sum值，失败数聚合status=failure的sum值，总请求数直接跨标签sum即可，后续要扩展错误码、接口名等维度也非常方便。

内容的提问来源于stack exchange，提问作者andrw