通知规则

告警规则负责产生告警事件,通知规则负责把告警发送出去,不同的告警可以选择不同的通知媒介,比如高级别的告警打电话、发短信、发钉钉,低级别的告警发邮件等。再进行通知之前,还可以引入事件处理器,对告警事件做额外的处理,开源版本支持 Relabel、Callback、Event Update、Event Drop 四类处理器,不同的处理器可以组成一个 Pipeline,对告警事件做一些很灵活的处理。场景比如:

  • 跟内部的 CMDB 打通,附加一些更丰富的信息到告警事件上
  • 调用 DeepSeek 的接口,对告警事件做一些智能分析,然后把分析结果附加到告警事件上
  • 把所有告警事件发送到自己的系统,相当于镜像一份,做后续的分析处理
  • 一些特定的告警事件可以 Drop 掉,比如一些恢复事件不想发送通知

事件处理 Pipeline 是个相对高级的功能,普通用户用不上,本文主要介绍基础通知规则的配置。

设计初衷

老版本的夜莺没有通知规则的概念,是在告警规则里直接配置通知媒介和通知接收人,虽然直观,但是不够灵活,有如下问题:

  • 告警规则中启用抑制之后,通知媒介仍然只能写死的问题。之前版本的告警规则中如果启用了抑制规则,通常意味着,不同的阈值想要使用不同的级别,进而使用不同的通知媒介发送告警,比如 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 信息。比如:

通知媒介管理用户 Profile

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

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

具体配置举例

另外,在微信视频号:SRETALK 上也放置了一个视频教程,演示如何接入飞书告警,您可以自行搜索查看。

🎯 由于读者水平参差不齐,重口难调,社区小伙伴一直在持续更新优化文档内容,如果您觉得本页文档内容有误或不够完善,欢迎您参与到文档的编写中来,点击下方的 Edit this page on GitHub 即可编辑 👇