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

3 月 8 日妇女节，来一场职场姐妹茶话会！欢迎加入群聊

以防读者不了解夜莺，开头先做个介绍：

夜莺监控，英文名字 Nightingale，是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺是侧重在告警引擎。比如把 Prometheus、VictoriaMetrics、ElasticSearch 等作为数据源接入夜莺，即可在夜莺里配置告警规则做指标、日志的告警。当然了，夜莺也不止做告警，还提供了 ad-hoc 查询、指标视图、仪表盘等可视化能力，不过在可视化方面没有 Grafana 道行深。配合 Categraf 采集器，夜莺可以做到一站式监控。其项目地址是：https://github.com/ccfos/nightingale

近期夜莺发版 v8.0.0-beta7，这个版本最重要的变化是抽象出通知规则，增强告警通知的灵活性。为啥做这个改动？主要是解决如下需求/问题：

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

新版本的告警事件发送逻辑，整体流程变成如下这个样子：

之前的版本，是在告警规则里直接配置通知媒介+告警接收人，耦合严重。新版本是在告警规则里关联通知规则，具体如何发送是在通知规则里定义的，这样一来，告警规则和通知规则解耦，多个告警规则可以关联一个通知规则，如果想要改动通知方式，只需要改动通知规则即可。

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

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

打开通知媒介的配置，其中有个「变量配置」不太好理解。我说个场景：比如 DBA 团队和 BigData 团队都想使用企微这个通知媒介发告警，但是他们想使用不同的企微机器人，即 Webhook 地址基本相同，但是 URL 参数中的 Key 不同（不同的 Key 代表不同的机器人）。此时应该怎么做？

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

如何让通知媒介支持参数呢？就是在媒介的变量配置中进行创建。内置的企微通知媒介就是创建了两个参数，一个 Key（表示企微机器人Key），一个 Bot Name（机器人名称，自定义的，纯粹是为了方便记忆，类似备注的效果）。进而，在企微媒介的 HTTP 配置中，就可以引用这个参数，比如：

这个场景相对简单，媒介通知的时候，获取用户填写的 Key 即可。还有更复杂的场景。比如发短信，此时媒介参数如何定义？如果直接定义成 Phone，然后让用户在通知规则中手写手机号，那就有点费劲了。而且用户的联系方式如果发生变化，除了要到个人中心修改自己的手机号，还要到通知规则里改，太过麻烦。而手机号已经在个人的联系方式中了，那直接把二者贯通即可。

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

媒介变量这里，联系方式选择 Phone，然后就会有一系列的魔法，魔法效果是：

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

这个设计是最近版本中的一个巨大革新，希望能够帮助大家更方便地配置告警通知。整个逻辑很灵活，但确实稍微有点绕，恳请大家如果用好了，多写写文章分享一下你的使用心得 🙏 把社区做大做强，形成正向循环。