界面上写着「30 秒刷新」「3 分钟判失联」。这两个数字不是随手取的，背后各有一组相反的力在拉扯。
刷新间隔：快与慢之间
刷新越快，成本越高。 假设一万个节点、每 10 秒刷新一次，服务端每秒要处理 1000 次状态查询，数据库每秒被读一千次。这些查询大部分返回的是"没变化"——浪费。
刷新越慢，越容易漏。 如果 5 分钟才刷一次，一个持续 2 分钟的算力骤降就会被完全跳过。你以为的"一直正常"，其实中间出过事。
30 秒是个折中：一天的采样量是 2880 次/节点，对数据库是可承受的量级（配合归档与降采样），同时任何持续超过半分钟的异常都不会被漏掉。
更重要的是，30 秒和人的感知是对齐的。运维盯屏幕时，30 秒的间隔不会让人觉得"卡住"，也不会让人觉得"跳得太快看不清"。
判失联：3 分钟的来历
判定失联比刷新复杂，因为它要区分三种情况。
网络抖动。 网络短暂波动导致一两次心跳没送达。这种情况很常见，不应该报故障。
节点真的挂了。 进程崩溃、机器断电、网络断开。
采集端本身出问题。 采集脚本崩了，但节点还在跑。这种情况下节点是"活着但沉默"。
如果门槛定得太低，比如 1 分钟，那么一次稍长的网络抖动就会触发告警。告警多了人就麻木，真正的故障反而被忽略——这是告警系统最常见的死法。
定得太高，比如 10 分钟，客户可能在你之前发现故障。这个顺序不对——应该是我们先知道，然后告诉客户。
3 分钟的依据是：它大于绝大多数网络抖动的持续时间（通常是秒级到几十秒），小于客户从"发现异常"到"打电话投诉"的典型反应时间（通常五到十分钟）。
换句话说，3 分钟这个门槛是为了让我们"抢在客户前面"。
判定不是单一阈值
只看"多久没心跳"会误判。所以判定逻辑还看其他信号：
- 心跳断了，但区块高度还在推进——说明节点在跑，只是上报通道有问题。
- 心跳正常，但算力掉到零——节点活着但没在干活，这比失联更隐蔽。
事件生成时带上这些上下文，处置的人一眼能看出是哪种情况，不用自己去推。
一个提醒
阈值是可以调的。不同场景下的合理值不一样——比如测试环境可能希望更快发现异常（容忍误报），而生产环境更在意准确（容忍延迟）。
但调之前想清楚代价：调低门槛 = 更多误报 = 更快的告警疲劳；调高门槛 = 更少误报 = 更晚的发现。没有免费的午餐。
—— Pi Admin X 团队