夜莺监控：机器告警配置详解

巴辉特 2025-12-16 12:28:55

机器，作为 Infra 层面的重要对象之一，自身的健康状况是需要监控的，比如机器的存活与否、时间偏移大小、CPU 使用率、内存使用率、磁盘使用率等。在 Prometheus 生态里，统一使用标签对机器分组，使用 Promql 语句进行告警规则配置。

夜莺监控（Nightingale）也可以使用 Promql 对机器做规则配置，但对于机器存活监控有不同的设计。另外夜莺里有业务组的概念，是和标签类似的分组机制，也给机器监控带来了很多便利，使得机器普通指标的监控，也有一些新的设计，本文逐一介绍。

机器存活监控

我们推荐使用 Categraf 采集机器监控数据，Categraf 通过 Prometheus remote write 协议将数据上报到夜莺监控（Nightingale）。这种模式，在业内称为 PUSH 模式，Prometheus 生态里，对于机器监控是在机器上面安装 Node Exporter，然后 Prometheus 进程去拉取，这种模式称为 PULL 模式。

PULL 模式可以很容易感知机器的存活状态，如果 Prometheus 去拉取 Node Exporter 失败，就说明机器不可达了，可以通过 up 指标进行告警配置：

up{job="node-exporter"} == 0

但是在 PUSH 模式下，是没法有这么一个 up 指标的。细想一下，如果 Categraf 存活，可以上报 up=1，如果 Categraf 宕机了，自然没法上报任何指标，也就没法上报 up=0 了，这样就没法通过 up 指标来感知机器的存活状态了。

所以在夜莺监控（Nightingale）的告警规则里，专门提供了 Host 类型的告警规则：

原理是：服务端周期性判断机器是否有心跳或者是否有监控数据上报，如果有就认为是存活的，如果太久（告警规则里配置的时间）没有心跳或者监控数据上报，就认为机器不可达了，从而触发告警。

⚠️ Host 告警模式下，除了机器失联，还有一个时间偏移的告警方式。注意，机器时间偏移并非是机器和 NTP Server 之间的时间偏移，而是 Categraf 所在的机器和夜莺服务端的时间偏移，如果用了 n9e-edge 边缘模块，就是 Categraf 所在的机器和 n9e-edge 所在机器的时间偏移。

机器普通指标监控

这里说的普通指标监控，就是通过 Prometheus 数据源配置 Promql 的方式，对机器的 CPU、内存、磁盘等指标进行监控。当然，也可以对机器上报的自定义指标进行监控。只要指标里有机器的唯一标识（在夜莺里是 ident 标签），我们姑且就称之为机器指标监控。

使用标签过滤

这是 Prometheus 生态里最常见的方式了，通过标签过滤出某一类机器，然后进行告警规则配置。比如我只想对 env="prod" 的机器做 CPU 使用率告警：

cpu_usage_active{env="prod"} > 90

除了 env="prod" 的机器，其他机器的 CPU 使用率超过 80% 就告警，那就要配置另外一条规则：

cpu_usage_active{env!="prod"} > 80

但如果有些指标里没有 env 标签，那就尴尬了，上面两个规则都无法命中这些没有 env 标签的机器。

仅在本业务组生效

原理：拿着告警规则里的 promql 去查询时序库里的所有满足条件的数据，可能查到很多机器都告警了，然后再根据机器的归属关系做过滤，只保留自己业务组下的机器的相关告警。

如果 Promql 查到的数据中没有 ident 标签（在夜莺里 ident 标签表示机器的唯一标识），那就歇菜了，此时就不管「仅在本业务组生效」这个配置了，直接报出来。只有 Promql 查到的数据里有 ident 标签，才会进行业务组过滤。

如果有 10 个业务组，每个下面都有机器相关的告警规则，并且都勾选了「仅在本业务组生效」，可以想象性能是不太好的，因为每个规则都要查询 TSDB 里的所有数据，然后再做业务组过滤。

「仅在本业务组生效」这种方式在新版夜莺里已经不推荐使用了。

使用业务组变量

比如我配置了一个告警规则，只想对 Default Busi Group 和 DevOps 这俩业务组下面的机器生效，那我可以这么配置：

上图中，创建了一个 ident 变量，变量类型是机器标识，机器范围是 Default Busi Group 和 DevOps 两个业务组下的机器。然后在 promql 中引用了 ident 标签作为过滤条件。

上例用的变量模式，还有另一个好处，是用于特殊机器的阈值配置，比如 Default Busi Group 和 DevOps 两个业务组下的机器默认 CPU 阈值都是 80，但是其中有1台机器很特殊，平时负载就很高，CPU 阈值要设置为 88，那就可以再加一个阈值变量，同时继续配置 变量筛选 条件：

这个配置方式稍微有点复杂，不过没办法，问题场景本身就是复杂的。

这种方式适合各个团队分散管理的模式。大家分别配置自己的告警规则，相互之间互不影响。但有些公司的运维是统一来管理机器相关的告警规则，此时则推荐下面即将介绍的方式。

在通知规则里灵活分配通知人

对于某个指标，我们使用 Promql 配置告警规则，查询所有异常的机器，触发告警事件，然后这些事件交给某个通知规则，在通知规则里，再根据机器的归属关系，灵活分配通知人。

上例中配置了一个通知规则，这个通知规则是发送的阿里云电话，针对特定的业务组的机器生效，利用「机器业务组」这个属性做的过滤。上例中，如果发现告警事件里有 ident 标签，即机器信息，而且发现机器所属的业务组是 DBA-MySQL、DBA-Oracle、DBA-Postgres 之一，就会发送给对应的通知人。

当然，如果接告警的人是不同的团队，这里的配置会比较复杂。后面我们会继续优化，让订阅规则也支持根据机器所属业务组过滤和分配，届时管理起来会更方便一些。