Prometheus 体系貌似已经成为新时代的监控标准。运维出去找工作，很多公司都要求掌握 Prometheus 相关知识。
但 Prometheus 真正落地之后，经常会遇到一个很具体的问题：告警规则怎么管理。
摘要
- Prometheus alerting rules 通常写在 YAML 文件里，再通过 Git 做版本管理；这套方式适合工程化审计，但对全公司自助使用不够友好。
- 当研发团队、业务团队都要配置告警时，规则评审、权限隔离、归属管理、通知策略和误改风险会成为运维团队的负担。
- Nightingale，即夜莺监控，可以作为 Prometheus 的告警引擎，让用户在 UI 中管理告警规则，并通过业务组和权限控制隔离不同团队的规则。
- 夜莺不只支持 Prometheus 时序数据，也可以对 VictoriaMetrics、Thanos、Mimir、ElasticSearch、Loki、ClickHouse、MySQL、Postgres 等数据源做告警。
- 已有 Prometheus YAML 告警规则可以导入夜莺，适合把存量规则迁移到页面化、协作化的管理方式里。
Prometheus 告警规则管理为什么会痛苦
很多公司希望把 Prometheus 能力开放给全公司各个团队自助使用。但 Prometheus 告警规则需要编写 YAML 文件，虽然不少公司已经使用 Git 来管理这些规则，最终仍然需要运维团队统一 Code Review 之后才能 Merge 进主干。
原因很直接：大家担心某个人提交规则时，影响了其他人的规则。
更重一点的流程是，研发团队给运维团队提工单，由运维团队统一维护和管理这些 Prometheus 告警规则。这种方式可以降低误操作风险，但效率也很低。
从规则管理角度看，问题可以拆成几类：
| 管理问题 | 在 Prometheus YAML/Git 流程中的表现 | 夜莺监控的处理方式 |
|---|---|---|
| 自助配置门槛高 | 研发或业务团队需要理解 YAML、PromQL、Git 提交流程 | 在 UI 中创建、编辑、导入告警规则 |
| 规则互相影响 | 多个团队共用规则仓库，错误提交可能影响其他规则 | 通过业务组和权限控制隔离规则归属 |
| 运维评审压力大 | 规则变更都要运维统一 Code Review 或代配置 | 让团队在权限范围内自助管理规则 |
| 通知治理复杂 | 规则、通知人、通知媒介和升级策略容易混在一起 | 在告警规则之外配置通知规则，按告警分发 |
| 存量迁移成本 | 已有 Prometheus 规则多为 YAML | 支持导入 Prometheus 告警规则 |
有痛苦必有解法。今天为大家介绍一个开源项目，就是来解决这个问题的，它的名字是 Nightingale，即夜莺监控。
Nightingale 如何为 Prometheus 增加 UI 管理能力
夜莺监控可以充当 Prometheus 的告警引擎。用户可以在 Nightingale 的 UI 中管理告警规则，UI 有权限控制，不同的规则相互之间没有影响。
它的核心价值不是简单把 YAML 换成表单，而是把 Prometheus 告警规则管理里常见的协作问题一起纳管：谁能创建规则、规则属于哪个业务组、规则查询哪个数据源、触发后通知谁、是否要重复通知、是否要关联自愈脚本。
夜莺告警引擎还有两个基础能力：
- 夜莺的告警引擎是高可用的，可以部署多个夜莺进程组成集群，某个节点挂了，整体告警功能不受影响。
- 夜莺不但可以对 Prometheus 时序数据做告警，也可以对 VictoriaMetrics、Thanos、Mimir 等其他时序库告警；也可以对 ElasticSearch、Loki 告警；还可以对 ClickHouse、MySQL、Postgres 等其他存储的数据做告警。
夜莺项目相关地址：
从代码仓库地址可以看出，其 GitHub group 是 ccfos。ccfos 是中国计算机学会开源技术发展委员会的 group，夜莺项目托管在基金会下运作，不会突然闭源或修改开源协议。
下面演示夜莺项目的部署，以及如何用它配置和导入 Prometheus 告警规则。
部署夜莺监控
夜莺监控作为一款开源项目，发布包在 GitHub Releases 页面：
https://github.com/ccfos/nightingale/releases
本文演示使用的是 v8.2.2。我是 arm64 的环境，所以下载 n9e-v8.2.2-linux-arm64.tar.gz。
一般生产环境都是 Linux，所以夜莺默认提供的是 Linux 发布包。实际上，夜莺也可以跑在 Windows 或者 Mac 上，只是官方没有提供默认的发布包，需要自行编译。
使用如下命令解压缩：
mkdir n9e
tar zxvf n9e-v8.2.2-linux-arm64.tar.gz -C n9e
然后进入 n9e 目录直接启动：
./n9e
默认监听在 17000 端口，可以使用浏览器访问 WEB UI。默认用户名是 root，默认密码是 root.2020。
之所以可以一键启动，是因为默认使用的存储是 sqlite，默认使用的缓存是 miniredis，也就是内置到进程内存里。如果是生产环境，请使用单独的 MySQL 和 Redis。
MySQL 和 Redis 相关连接配置在 n9e 二进制同级目录下的 etc/config.toml 里。配置文件里各项是什么含义，可以参考：夜莺配置文件详解。
OK，夜莺部署完了。接下来配置 Prometheus 数据源和告警规则。
接入 Prometheus 数据源
进入夜莺的 集成中心-数据源 管理页面，把 Prometheus 作为数据源配进来。这点跟 Grafana 很像：
配置完成之后，需要验证数据源是否可用。到 指标-即时查询，查询时序库中的监控数据。如果能够查到数据，说明数据源配置没有问题。
在 UI 中配置 Prometheus 告警规则
菜单位置是 告警-规则管理。
由于告警规则可能会有很多，不同团队希望分门别类管理，所以夜莺里抽象了一个业务组的概念。安装完成之后有个默认业务组，选中这个业务组后，右侧会出现新增、导入按钮，用于创建或导入告警规则。
可以先点击新增，大概浏览一下夜莺的告警规则有哪些配置：
基础配置：对应 Prometheus 的 alertname、labels 和 annotations
基础配置用于配置告警规则名称、附加标签和备注。
- 告警规则名称：对应 Prometheus 里的
alertname。 - 附加标签：对应 Prometheus 里的
labels。 - 备注：对应 Prometheus 里的
annotations.description。
因为夜莺里有权限管控，告警规则会归属于某个业务组。刚才我们点击 Default Busi Group 之后再创建规则，所以这个页面会自动填充业务组信息。
查询条件：配置 PromQL、执行频率和持续时长
这里配置 PromQL 查询条件，可以配置多个查询条件，多个条件之间支持抑制，也可以启用变量。如果只是简单使用，只需要配置 PromQL 即可。
这里有两个字段和 Prometheus alerting rules 的语义很接近：
- 执行频率：多久查询一次这个 PromQL。如果查到了就表示数据异常，相当于 Prometheus 里的 eval interval。夜莺的执行频率支持 cron 写法。
- 持续时长：相当于 Prometheus 里的
for关键字。
各个字段的标题旁边都有一个小问号 icon，鼠标挪上去，有些需要点击，会展示用法提示。
事件 relabel：对告警事件做加工
事件 relabel 是对告警事件做 relabel 操作。Prometheus 生态里也有 relabel 的逻辑，不过常见场景是对 metrics 做 relabel；夜莺这里可以对告警事件做 relabel。
后面还会在告警规则颗粒度引入更多 Processor，支持事件的 Pipeline 处理，那就极为灵活了。
生效时间：控制规则什么时候运行
生效时间配置就是告警规则的生效时间。这个能力对一些证券类场景很有用。
有些时候，告警规则只想白天运行，晚上不想运行；或者白天一个阈值，晚上一个阈值。在夜莺里都可以实现。
通知规则、自愈和附加信息
告警事件产生之后要通知出去，所以后面要配置通知规则。通知规则在其他菜单管理，主要用于配置不同的告警发给不同的人，不同的告警使用不同的通知媒介。
比如，高优先级告警可以打电话，低优先级告警可以发邮件。
留观时长、重复通知间隔、最大通知次数，见名知意。右侧也都有小问号 icon，可以点击查看具体用法提示。
另外还有两个常用配置：
- 告警自愈：夜莺支持在告警的时候去告警机器上执行一个脚本，比如磁盘满了自动清理一下，或者自动抓个现场。所以告警规则这里可以关联自愈脚本。
- 附加信息：类似 Prometheus 中的 annotations，比如把 SOP 的 URL 放进来。
除了手工创建告警规则，也可以导入 Prometheus 之前的告警规则。
导入已有 Prometheus 告警规则
Prometheus 生态有很多人分享了告警规则，比如 awesome-prometheus-alerts。这个项目的每个目录下都是 YAML 格式的告警规则，比如 host-and-hardware 目录下就是常见的 node-exporter 告警规则。
可以拷贝 YAML 内容，然后在夜莺里点击导入按钮，导入 Prometheus 的规则：
对于已经沉淀了 Prometheus alerting rules 的团队，这个能力比较关键。它不是要求从零开始重建规则，而是把已有 YAML 规则纳入夜莺的 UI 管理、业务组权限和通知治理流程。
夜莺告警引擎的其他能力
除了页面化管理告警规则、支持引擎高可用之外，夜莺的告警规则还有另外两个有意思的点：
- 可以使用一套告警规则，生效到多个时序库，这样管理起来更方便。
- 可以处理边缘时序库场景。比如有个时序库能连中心的夜莺进程，但是夜莺进程连不上边缘时序库，这种场景也可以支持。具体可以参考夜莺文档，或者等后面的文章。
FAQ
夜莺是替代 Prometheus 吗？
不是。本文讨论的是 Prometheus 告警规则管理问题。夜莺可以作为告警引擎来管理和执行告警规则，也可以接入 Prometheus 作为数据源。
为什么不用 Git 继续管理 Prometheus 告警规则？
Git 管理规则有版本记录和评审流程，适合工程化管理。但当目标是把 Prometheus 告警能力开放给全公司自助使用时，纯 YAML/Git 流程会把规则编写、权限隔离、通知治理和跨团队协作压力集中到运维团队身上。夜莺的价值在于把这些管理动作放到 UI 和权限体系里。
夜莺能导入已有的 Prometheus YAML 规则吗？
可以。可以把已有 Prometheus 告警规则的 YAML 内容复制出来，在夜莺的规则管理页面点击导入，把存量规则纳入夜莺管理。
夜莺只支持 Prometheus 数据源吗？
不只支持 Prometheus。夜莺还可以对 VictoriaMetrics、Thanos、Mimir 等其他时序库告警，也可以对 ElasticSearch、Loki 告警，还可以对 ClickHouse、MySQL、Postgres 等其他存储的数据做告警。
结论
Prometheus 告警规则真正难的地方，不只是 PromQL 怎么写，而是规则如何在团队之间协作管理：谁能改、改什么、影响谁、触发后通知谁、是否需要自愈、存量规则如何迁移。
夜莺监控提供了一条比较直接的路径：把 Prometheus alerting rules 从 YAML/Git 的单一工程流程，扩展成带 UI、权限、业务组、通知规则和导入能力的告警规则管理体系。
本文介绍了夜莺开源项目如何纳管 Prometheus 告警规则，希望对你有用。
