夜莺监控巨大革新：抽象出通知规则，增强告警通知的灵活性

夜莺监控 v8.0.0-beta7 的核心变化，是把“怎么发通知”从告警规则里抽象出来，形成独立的“通知规则”。这个设计让告警规则只负责判断事件，通知规则负责选择媒介、接收人、模板和参数，从而提升告警通知的灵活性。

核心要点

v8.0.0-beta7 新增通知规则，让告警规则和通知方式解耦。
不同告警级别可以使用不同通知媒介，例如 Critical 走电话或短信，Info 走 Email。
通知媒介支持通用 HTTP 和脚本方式，便于接入电话、短信等非内置通道。
消息模板可以自定义，不同团队即使用同一种通知媒介，也可以配置不同模板。
通知媒介支持变量配置，可以把用户填写的参数或用户 Profile 信息带入发送逻辑。

夜莺监控是什么

夜莺监控，英文名字 Nightingale，是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺可以对接多种既有数据源；不同的是，Grafana 更侧重可视化，夜莺更侧重告警引擎。

把 Prometheus、VictoriaMetrics、ElasticSearch 等作为数据源接入夜莺后，就可以在夜莺里配置指标和日志告警。夜莺也提供 ad-hoc 查询、指标视图、仪表盘等可视化能力；配合 Categraf 采集器，可以组成一站式监控方案。

项目地址：https://github.com/ccfos/nightingale

为什么要抽象通知规则

v8.0.0-beta7 之前，告警规则里直接配置通知媒介和接收人。这个模型简单，但在团队规模变大、通知媒介变多之后，会遇到几个典型问题：

告警规则中启用抑制之后，通知媒介仍然只能写死的问题。之前版本的告警规则中如果启用了抑制规则，通常意味着，不同的阈值想要使用不同的级别，进而使用不同的通知媒介发送告警，比如 Critical 级别的告警使用电话、短信，Info 级别的告警使用 Email。但是之前版本的告警规则中，通知媒介是写死的，无法做到不同的级别不同的媒介。
接入电话、短信等通知方式不方便。这次我们提供了通用的 HTTP、脚本发送方式，HTTP 的参数、Header、Body 都可以自定义，这样一来，可以更方便接入不同通知媒介了。
之前的通知方式和告警规则强耦合，不方便改动。新版本抽象了「通知规则」的概念，告警规则直接关联的是通知规则，通知规则中可以定义灵活的发送方式。每个小研发团队通常只需要定义一个通知规则，然后所有的告警规则都关联这个通知规则即可。后面改动通知规则也是非常方便的，改一个地方即可影响所有告警规则。
之前版本消息模板比较死板，每个类型的通知媒介只能固定使用一个消息模板。新版本支持消息模板自定义，而且每个通知媒介可以关联不同的消息模板，比如 DBA 团队和大数据团队都要使用钉钉机器人发告警，但是希望使用不同的消息模板，现在就可以做到了。

这次改动的本质，是把“告警是否触发”和“告警如何通知”拆开。告警规则负责生成事件，通知规则负责决定事件发给谁、通过什么媒介发、用什么模板发。

新版本的告警发送逻辑

新版本的告警事件发送逻辑变成如下结构：

夜莺通知规则

之前是在告警规则里直接配置“通知媒介 + 告警接收人”，耦合比较重。新版本是在告警规则里关联通知规则，具体发送方式由通知规则定义。多个告警规则可以关联同一个通知规则，后续如果要调整通知方式，只需要修改通知规则，不必逐条修改告警规则。

通知规则可以支持不同的通知媒介，而且可以定义不同的媒介适用的范围，比如电话这个通知媒介，只适用于 Critical 的告警，而 Email 则适用于 Critical、Warning、Info 所有告警。下面是一个通知规则配置样例：

夜莺通知规则

场景	旧方式的问题	通知规则的价值
不同级别走不同媒介	告警规则里通知媒介容易写死	按告警级别选择电话、短信、Email 等媒介
多团队共用同一媒介	需要复制媒介或复制规则	一个媒介通过变量区分不同团队参数
模板差异化	同一媒介模板固定	不同通知规则可关联不同消息模板
通知方式变更	需要逐条修改告警规则	修改通知规则即可影响关联规则

通知媒介和变量配置

对于通知媒介，我们会内置一些，方便大家开箱即用：

夜莺通知媒介

打开通知媒介配置后，其中有个「变量配置」不太好理解。可以用一个企微机器人场景解释。

假设 DBA 团队和 BigData 团队都想使用企微这个通知媒介发告警，但他们希望使用不同的企微机器人。两个机器人的 Webhook 地址基本相同，只是 URL 参数中的 Key 不同，不同 Key 代表不同机器人。此时应该怎么做？

在夜莺的设计里，不希望创建两个不同的通知媒介。还是希望只有企微一个通知媒介，但是这个通知媒介支持传参，DBA 同学在配置告警通知规则的时候，选择企微这个通知媒介的同时，要填写自己的机器人的 Key，BigData 同学也是一样，也是配置企微通知媒介 + BigData 的企微机器人 Key。这样一来，一个通知媒介就可以支持多个机器人了。

让通知媒介支持参数的方法，就是在媒介的变量配置中创建变量。内置的企微通知媒介创建了两个参数：

Key：表示企微机器人 Key。
Bot Name：机器人名称，自定义字段，主要用于备注和识别。

随后，在企微媒介的 HTTP 配置中，就可以引用这些参数：

这个场景相对简单，媒介发送时获取用户填写的 Key 即可。更复杂的场景是短信。

如果短信媒介直接定义一个 Phone 参数，让用户在通知规则中手写手机号，会带来两个问题：配置麻烦；用户手机号变化时，除了修改个人中心，还要修改通知规则。既然手机号已经在个人联系方式里，就应该直接复用用户 Profile 信息。

对于这类场景，可以概括为：媒介需要的参数来自用户的 Profile 信息。这个时候，就需要在媒介的变量配置中，引用用户的 Profile 信息。比如：

媒介变量里，联系方式选择 Phone 后，会产生两个效果：

通知规则那里，系统根据媒介里的 Phone 联系方式，知道用户想发通知给某些人，通知规则那里就可以选择联系人或团队了，而不是手写手机号。
在 HTTP 的 request body 或 query string 中，可以引用一个魔法变量：{{ $sendto }}，表示被通知对象的手机号。这样一来，通知媒介就可以根据这个变量，把告警通知发给正确的人了。{{ $sendto }} 这个设计是从 Zabbix 学的，如果你用过 Zabbix，应该会很熟悉。