夜莺监控(Nightingale)6.x 的机器失联告警设计

机器失联告警要回答一个很直接的问题：某台机器是否还在持续上报监控数据。夜莺监控（Nightingale）5.x 通过 target_up 指标间接判断，6.x 则计划改为直接读取 target 的心跳时间。

核心要点

• 5.x 的失联判断链路是：解析 ident、写 MySQL、写 Redis、选主、生成 target_up、写入时序库。
• 这条链路能工作，但逻辑绕、即时性一般，社区理解成本也高。
• 6.x 的设计方向是取消自动生成 target_up，直接使用 MySQL 中 target 的最近心跳时间判断是否失联。
• 告警配置也随之简化：用户选择要监控的机器即可，不必手写 PromQL。

夜莺 5.x 的机器失联设计

在夜莺 5.x 中，n9e-server 模块接收监控数据，从数据中解析出 ident，把机器注册到 MySQL，同时把 ident 的最近更新时间写入 Redis。多个 n9e-server 实例之间会选主，作为 leader 的 n9e-server 周期性读取 Redis 中的 ident 信息，再生成 target_up 指标写入时序库。

简化成流程就是：

Agent 上报数据
  -> n9e-server 解析 ident
  -> 注册 target 到 MySQL
  -> 写入 ident 最近更新时间到 Redis
  -> n9e-server leader 周期性读取 Redis
  -> 生成 target_up 指标
  -> 写入时序库
  -> 告警规则基于 target_up 判断机器是否失联

这个方案的主要问题不是不能用，而是判断链路太长。失联状态需要先转成 target_up 指标，再由告警规则判断；中间涉及 Redis、leader 选主和周期性生成指标，导致即时性和可理解性都不够好。

夜莺 6.x 的机器失联设计

相比 5.x，6.x 最大的改动是去掉 target_up 指标生成逻辑，直接读取 MySQL 中的 target 心跳时间。如果某个 target 长时间没有更新，就认为它不活跃，并触发机器失联告警。

原本 5.x 中，n9e-server 往 MySQL target 表写机器信息更像是一次注册：如果数据库里已有这条记录，就不重复写；如果没有，才插入新记录。

6.x 的变化是周期性更新：如果数据库里已有这台机器，就刷新它的心跳时间。只要机器存活并正常上报监控数据，数据库里的心跳时间就会持续更新；一旦心跳长时间不变，告警引擎就可以直接判断机器失联。

夜莺 6.x 如何配置机器失联告警策略

在告警规则中，6.x 会新增一种机器失联规则配置方式。用户不需要写 PromQL，只需要选择要告警的机器范围。告警引擎会读取机器的最近更新时间：如果更新时间长时间没有变化，就说明对应 Agent 可能已经停止上报，从而产生告警事件。

配置思路可以理解为三步：

1. 选择要纳入失联检测的机器或机器范围。
2. 设置多久没有心跳更新才认为失联。
3. 配置告警级别、通知方式和处理策略。

这种方式把“机器是否还活着”从指标表达中抽离出来，变成夜莺内置的对象状态判断，配置门槛更低，也更符合用户对机器失联告警的直觉。

设计取舍

6.x 的方案减少了 target_up 指标这一层抽象，优点是链路更短、解释更容易、告警更直接。对应的取舍是：机器失联判断更依赖 target 心跳更新机制，因此 Agent 上报链路、target 注册逻辑和数据库写入稳定性要保持可靠。

对于用户来说，最重要的变化是：不再需要围绕 target_up 写 PromQL，而是直接配置机器失联规则。对于维护者来说，架构链路也从“生成指标再告警”变成“更新对象状态再告警”。

FAQ

Q1：夜莺 6.x 为什么不继续使用 target_up？ A：target_up 需要额外生成并写入时序库，链路较长。6.x 直接使用 target 心跳时间判断失联，逻辑更简单，也更容易解释。

Q2：机器失联告警是否还需要 PromQL？ A：按本文设计，6.x 会提供新的规则配置方式，不需要用户手写 PromQL，只需要选择要告警的机器。

Q3：心跳时间多久不更新才算失联？ A：具体阈值应结合 Agent 上报周期、网络抖动和业务容忍度配置。关键原则是不要把短暂网络抖动误判为真实失联。

关于作者

本文作者秦晓辉，Flashcat合伙人，文章内容是Flashcat技术团队共同沉淀的结晶，作者做了编辑整理，我们会持续输出监控、稳定性保障相关的技术文章，文章可转载，转载请注明出处，尊重技术人员的成果。