测量失败时time series database的指标上报最佳实践是什么

• 首先明确两种常见方案的缺陷：
  • 上报-1这类自定义异常值：会直接污染正常指标的统计结果，执行avg、P95等聚合运算时必须额外添加过滤逻辑，漏加就会导致数据完全失真，主流时序数据库的默认聚合函数也不会自动排除这类非法值，后续维护成本极高。
  • 完全不写入数据：无法区分「采集任务终止」、「网络故障」、「endpoint宕机」三类完全不同的故障场景，既没法做精准告警，也无法回溯故障发生的准确时间点。
• 行业通用的标准处理方案如下：
  • 优先选择双指标拆分上报的方案：
    1. 性能指标：仅采集成功时上报正常值，例如下载时长、DNS lookup time这类数值指标，采集失败时不上报该类指标的数值点。
    2. 采集状态指标：单独新增一个枚举型指标，每次采集无论成功失败都必须上报。可以定义为network_probe_success，值为1代表采集成功，值为0代表采集失败，额外附加failure_reason标签标注具体故障类型，例如dns_timeout、endpoint_unreachable、connection_refused等。
  • 该方案的优势：
    • 统计性能指标时无需额外过滤逻辑，天然避免脏数据干扰。
    • 排查故障时优先查询采集状态指标的时序曲线，值为0的区间即为采集失败时段，结合故障标签可直接定位根因，也可直接用来统计endpoint可用率、不同故障类型占比等高阶指标。
• 极简场景兼容方案：
  如果受限于采集端逻辑复杂度，无法新增额外指标，可以使用时序数据库原生支持的*NaN（空值）*代替-1上报。主流TSDB（Prometheus、InfluxDB、TDengine等）均支持NaN类型的存储，执行聚合运算时会自动忽略NaN值，不会污染统计结果；同时只要有数据点写入就代表采集任务正常运行，值为NaN即代表采集失败，也可区分采集任务终止的场景（无任何数据点）。该方案的缺陷是无法标注具体故障原因，仅适合简单探测场景使用。

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