Uptime-Kuma中Push监控的心跳机制问题分析

问题背景

在Uptime-Kuma监控系统中，Push类型的监控器存在一个心跳机制的行为异常问题。当设备主动推送"down"状态时，系统仍然会触发心跳超时检测，这显然不符合Push监控的设计初衷。

当前机制分析

当前实现中，Push监控的心跳机制工作流程如下：

1. 正常状态：设备每900秒(可配置)推送一次"ok"状态，监控状态保持绿色
2. 设备故障：设备停止推送任何状态，系统依次显示：
   • 橙色警告("No heartbeat in the time window")
   • 最终变为红色宕机状态
3. 主动推送宕机：设备明确推送"down"状态时，系统仍会：
   • 先显示红色宕机状态
   • 随后进入橙色心跳超时警告状态
   • 最终再次变为红色宕机状态

问题本质

问题的核心在于系统没有区分"无响应"和"主动报告故障"这两种情况。对于Push监控而言，设备主动推送的任何状态(包括"down")都应被视为有效心跳，因为这证明设备仍在运行且能够通信。

技术影响

当前实现会导致：

1. 监控状态显示混乱，无法准确反映设备真实状态
2. 告警信息冗余，可能产生不必要的通知
3. 历史记录中出现不合理的状态转换

解决方案建议

理想的实现应该是：

1. 任何形式的推送(无论"ok"还是"down")都应重置心跳计时器
2. 只有在完全没有任何推送(包括故障报告)时才触发心跳超时检测
3. 主动推送的"down"状态应保持到下一次推送，不进入中间状态

实现考量

修改此行为需要注意：

1. 保持与现有配置的兼容性
2. 确保状态转换逻辑清晰
3. 不影响其他监控类型的行为
4. 更新相关文档说明

这种改进将使Push监控的行为更加符合实际运维场景的需求，特别是对于能够主动报告故障状态的智能设备监控场景。