在监控、可观测性领域，Grafana 应该是使用最为广泛的开源项目了，Grafana 可以对接多种数据源，对其中的数据做可视化分析。
核心要点
- Grafana 的优势主要在可视化，多数据源告警则涉及规则管理、判定引擎、通知、屏蔽、订阅和事件处理。
- 如果告警规则分散在 Prometheus、日志系统和数据库告警工具中，权限、通知媒介和处理流程也会随之分散。
- 夜莺监控侧重多数据源告警，可以对接 Prometheus、VictoriaMetrics、Thanos、ElasticSearch、Loki、MySQL、Postgres、ClickHouse 等数据源。
- 夜莺告警引擎的主流程包括规则判定、屏蔽、事件持久化、通知规则绑定、事件处理 Pipeline 和通知发送。
- 对告警治理来说，事件处理器可以用于标签增强、事件丢弃、智能分析、事件镜像和 CMDB 信息补充。
实际上，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 等
夜莺最核心的逻辑就是告警引擎，负责产生事件、对事件做二次处理，最终发出。我们看一下引擎的设计。
| 模块 | 主要作用 | 典型问题 |
|---|---|---|
| Webapi | 管理告警规则、通知规则、仪表盘等配置 | 谁来配置、如何授权、如何维护 |
| 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 掉，比如一些恢复事件不想发送通知
多数据源告警适合解决什么问题
夜莺这类多数据源告警引擎，适合处理“数据源已经很多，但告警能力需要统一”的场景：
- 指标在 Prometheus、VictoriaMetrics 或 Thanos 中，日志在 ElasticSearch、Loki 或 ClickHouse 中。
- 业务状态在 MySQL、Postgres 等关系库中，也需要进入统一告警流程。
- 告警规则希望通过 Web 页面管理，而不是散落在多套 YAML、SQL 或脚本中。
- 通知策略希望按团队、等级、时间段、标签和订阅规则统一治理。
- 告警事件需要经过 enrichment、drop、镜像、智能分析等二次处理。
FAQ
夜莺和 Grafana 的侧重点有什么不同？
按本文口径，Grafana 更侧重多数据源可视化，夜莺更侧重多数据源告警和告警事件处理。
为什么需要订阅规则？
订阅规则可以按事件属性筛选告警，再绑定到通知规则。这样不必在每条告警规则里硬编码所有通知逻辑。
事件处理 Pipeline 能解决什么问题？
Pipeline 用于对事件做二次加工，例如补充 CMDB 信息、调用智能分析接口、镜像事件到其他系统，或者丢弃不需要通知的事件。
总结
夜莺监控项目因为侧重点是告警，所以对告警事件相关的处理逻辑比较丰富。如果你的团队已经有 Grafana 做可视化，但告警仍分散在多套数据源、多套规则和多套通知流程里，夜莺这类多数据源告警引擎可以作为统一告警治理的一个选择。
参考：
- 夜莺代码仓库：https://github.com/ccfos/nightingale
- 夜莺文档地址：https://n9e.github.io/
- Grafana 官网：https://grafana.com/
