IOT 设备计数器突增的检测与恢复：如何区分「毛刺」和「真实跳变」本文从一个非常常见的工程问题出发——系统周期性采集设备上报的单调递增计数器，如何检测异常、如何自动恢复、以及如何区分"一次性数据毛刺"和"换表/清零导致的真实跳变"。方案不局限于某一种业务，凡是"周期性上报单调计数器 + 按增量统计 + 异常告警"的场景都适用。一、问题背景在很多物联网、遥测、计量类系统里，设备会周期性地把单调递增的累计计数器上报到服务端：电表的累计电量、水表的累计流量、网络设备的字节计数、服务的运行时长、消息序号等等。服务端拿到计数器之后，通常要做三件事：算增量：本次值减去上次值，得到本周期"新产生"的量，累加进小时 / 日 / 月等时间桶，用于统计甚至计费。发现异常：累计计数器理论上只增不减，而且增量应该和"上报间隔"成正比。如果某次增量大得离谱，多半是设备异常、传输丢包重发、或者换表 / 清零。告警与恢复：发现异常时告警，异常消失时自动恢复，避免运维一直盯着一堆"未处理"告警。这三件事里，最微妙、也最容易埋坑的，是**“异常"和"恢复"的判定**。本文用一套通用方案讲清楚：如何识别计数器突增、如何区分"一次性毛刺"和"真实跳变”，以及如何正确自动恢复，同时不污染统计口径。二、一个通用场景与第一版方案假设设备每 5 分钟上报一次累计值，单位是 kWh。我们配置了一条业务常识阈值：单台设备每小时最多能"新产生"maxDeltaPerHour（比如 100 kWh/h）。那么一次上报的"合理最大增量"就是按间隔折算：maxDelta = maxDeltaPerHour × (本次时间 - 上次时间) / 3600第一版方案很直观：delta = 本次值 - 上次基准值 if delta = 0: 回退 / 不变，跳过统计（可能是清零、乱序、重复） elif delta = maxDelta: 正常，累加 delta 到统计，并恢复告警 else: 异常突增，跳过统计，冻结基准，创建 / 刷新告警为了让"异常尖峰"不污染后续计算，异常时我们把基准（baseline）冻结在上一次有效值上——也就是不把那个离谱的 99999 写进基准，否则后面每次都会算出一个巨大的负增量（被误判为回退）。这个方案对"毛刺"效果很好：设备某次报了个垃圾值 99999，下一条又回到正常值，冻结基准 + 跳过统计恰好把这笔垃圾挡在统计之外，告警也在下一条正常上报时自动恢复。三、问题暴露：基准被冻结后，"真实跳变"永远恢复不了第一版方案在遇到真实跳变时会翻车。典型场景是换表：老表读数到 1000，换上新表，新表从 5000 开始计数。老表基准 = 1000。新表第一条 = 5000，delta = 4000，远超 maxDelta → 判为异常，冻结基准仍为 1000。新表第二条 = 5005，delta（相对冻结的 1000）= 4005，还是异常，继续冻结。……永远如此。结果有两个严重后果：统计永久少计：换表之后所有真实的消耗（5000 → 5005 → 5010… 的增量）都因为"相对冻结基准太大"被持续判为异常、持续跳过统计，能耗 / 流量长期少计。告警永远不恢复：这条"异常"告警会一直挂着，因为每次都满足"异常"条件。也就是说：用"相对基准的增量"去判断异常，一旦基准被冻结，就再也无法区分"还在异常"和"已经稳定在一个新的高位"。四、关键洞察：用两个视角看增量区分"毛刺"和"真实跳变"的关键，是引入第二个视角：视角计算方式用途相对基准本次值 - 基准判断"这次是否异常"相邻上报本次值 - 上一条原始值