Grafana侧重可视化，那多数据源告警呢？

在监控、可观测性领域，Grafana 应该是使用最为广泛的开源项目了，Grafana 可以对接多种数据源，对其中的数据做可视化分析。

实际上，Grafana 也可以配置告警规则，只是设计上相对拧巴，用户用的比较少。因为大部分情况下，告警都是使用 Prometheus，所以用户就直接在 Prometheus 里配置告警规则了。当然，这样会有如下问题：

• Prometheus 的告警规则使用 YAML 文件维护，维护起来不方便
• 如果有多套 Prometheus，那维护起来更费劲
• 如果有日志告警需求，比如 ElasticSearch、ClickHouse 等，就需要寻找其他告警方案，人员权限、通知媒介等就散落各处了
• 业务数据经常存在 MySQL 等关系库中，如果对业务数据做告警，还需要有个针对 MySQL、Postgres 等 OLTP 库的告警引擎

今天为大家介绍另一款开源项目，侧重点就是多数据源告警，希望可以帮到大家。这个项目叫夜莺监控。

夜莺简介

夜莺监控最开始是滴滴开源出来的，后来捐赠给基金会运作，目前在 github 上已经上万颗星，小有影响力。

夜莺项目也算是一个监控系统，不过侧重点在告警引擎，可以对接常见的数据源，比如 Prometheus、VictoriaMetrics、Thanos、ElasticSearch、Loki、MySQL、Postgres、ClickHouse 等，根据用户配置的告警规则，对数据做判定，生成告警事件并发送。其架构示意图如下：

从图上可以看出：

• 夜莺包含两个功能模块，一个是 Webapi，用于和用户交互，对一些配置类信息做 CRUD，比如告警规则、通知规则、仪表盘等；另一个是告警引擎 AlertingEngine，根据用户配置的告警规则做告警判定
• 夜莺用到了两个存储，MySQL 存储用户、权限、规则等配置类信息；Redis 用于存储 JWT Token、机器的心跳信息等
• 夜莺可以对接多种数据源，比如下面框里的那些存储，对这些存储中的数据做告警判定
• 生成告警事件之后，可以通过不同的通知媒介发出，比如邮件、电话、短信、飞书、Flashduty、Slack 等

夜莺最核心的逻辑就是告警引擎，负责产生事件、对事件做二次处理，最终发出。我们看一下引擎的设计。

夜莺告警引擎

上图基本可以说明告警引擎的核心逻辑，里边涉及到一些概念：告警规则、屏蔽规则、通知规则、订阅规则、事件处理 Pipeline、事件处理器 Processor、通知媒介等。如果你用过 Prometheus 和 Zabbix，里边很多概念是类似的。

1.告警判定引擎

最左侧那个大的矩形框，比较告警判定引擎，里边有很多小圆圈，每个小圆圈表示一个 goroutine（go 语言中的协程，可以理解为轻量级线程），每个 goroutine 处理一个告警规则。

告警规则里通常会配置一个检测执行周期，goroutine 的核心逻辑姑且可以理解为一个死循环，每隔一段时间执行一次。执行的时候，就是根据用户配置的查询语句查询数据源，查到了数据，就要产生告警事件。

如果是 Prometheus 数据源，用户要配置 promql，如果是 VictoriaMetrics，用户要配置 Metricsql，如果是 ClickHouse、MySQL、ElasticSearch、Postgres 等数据源，用户要配置 SQL。

告警判定引擎需要从 DB 同步用户配置的告警规则，周期性同步，9秒一次。

2.屏蔽规则

产生告警事件之后，先判断屏蔽规则，如果命中了屏蔽规则，事件就被丢弃。

通常来讲，一些预期内的维护动作，可能会导致预期内的告警产生，可以通过屏蔽规则提前做屏蔽，省的大家收到告警担惊受怕。

3.事件持久化

告警事件产生之后，为了方便后面在页面查看，会持久化到 DB 里。

页面上分两个菜单，一个是活跃告警，用于展示当前未恢复的告警事件，另一个是历史告警，展示所有历史上的告警、恢复事件。

4.绑定通知规则

告警事件产生并持久化之后，下一步是关联通知规则，通知规则里可以对事件做二次处理并发送。

告警事件有很多，哪些事件绑定哪些通知规则，如何定义呢？有两个方式：

• 在告警规则里直接绑定通知规则。这个告警规则触发的所有事件都会走对应的通知规则
• 告警规则里不直接绑定通知规则，在订阅规则里绑定。订阅规则可以对告警事件做筛选，筛选到的事件走某个通知规则

5.通知规则

大公司通知规则有很多，通常每个团队一个通知规则，通知规则包含两部分：

• 事件处理器，对事件做二次处理，比如 Enrichment、Drop 等
• 通知配置，指定什么样的事件发什么通知媒介，比如 Critical 的告警打电话，Warning 的告警发短信

6.事件处理管道（Pipeline）

通知规则里可以配置多个 Pipeline，每个 Pipeline 里包含多个 Processor。事件处理器的典型场景：

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

总结

夜莺监控项目因为侧重点是告警，所以对告警事件相关的处理逻辑比较丰富，如果你也有类似需求场景，可以尝试一下试试。

参考：

• 夜莺代码仓库：https://github.com/ccfos/nightingale
• 夜莺文档地址：https://n9e.github.io/
• Grafana 官网：https://grafana.com/