核心要点
- 夜莺（Nightingale）不是要替代 Prometheus，而是补齐 Prometheus 在告警规则管理、多数据源协同和团队自服务上的短板。
- 夜莺的核心能力是高可用告警引擎：一条告警规则可以生效到多个 Prometheus、VictoriaMetrics、Thanos 等数据源。
- 对于多机房或网络链路不稳定的场景，夜莺支持把告警引擎下沉到边缘机房，降低中心网络故障对告警判定的影响。
- 夜莺内置模板中心、指标视图、告警规则和仪表盘，适合想在 Prometheus 生态上快速落地监控告警的团队。
- 夜莺的仪表盘生态和告警降噪、排班、认领、升级等事件管理能力有边界，复杂场景通常需要 Grafana 或 Flashduty 等系统配合。
为什么要关注夜莺监控
监控系统的重要性不言而喻。国内常见的开源监控方案里，Zabbix 和 Prometheus 使用都很多，但二者解决的问题并不完全相同。
| 系统 | 更擅长的场景 | 主要短板 |
|---|---|---|
| Zabbix | 资产管理式监控、设备监控、传统基础设施监控 | 监控数据存在数据库中，对微服务和云原生环境不够顺手 |
| Prometheus | 云原生指标采集、多维标签查询、生态兼容 | 告警引擎单点，规则依赖配置文件，缺少权限化规则管理 WebUI |
| 夜莺 Nightingale | 多数据源告警、告警规则统一管理、团队自服务 | 看图能力不如 Grafana，深度事件管理需要配套系统 |
随着云原生的发展，Prometheus 已经成为指标监控的重要基础设施。但当企业希望把监控能力开放给多个团队，让研发、运维、业务团队自助配置告警规则、管理通知策略时，单靠 Prometheus 的配置文件会比较吃力。夜莺要解决的核心问题，就是在 Prometheus 生态之上提供更适合团队协作的告警管理能力。
夜莺项目背景
夜莺项目的 GitHub 地址是 https://github.com/ccfos/nightingale。其中 ccfos 不是一家公司，ccf 是中国计算机学会的缩写，os 是 open source 的缩写，ccfos 是中国计算机学会开源项目的统一地址。夜莺项目最初由滴滴开源，后来捐赠给中国计算机学会进行托管。
截至原文发布时，夜莺项目的 GitHub star 数量在 9300 多，fork 数量在 1300 多，相当于每 7 个 star 就有一次 fork，docker pull 数量 178000，增长曲线比较健康。
这些数据说明夜莺已经不是一个小众实验项目，而是一个被不少基础设施团队关注和试用的国产开源监控项目。
夜莺产品架构：以告警引擎为中心
夜莺的核心定位是做一个高可用的告警引擎，支持多数据源接入。很多公司内部并不只有一套 Prometheus，可能同时存在 Prometheus、VictoriaMetrics、Thanos 等多个时序库。如果每个时序库都独立维护告警规则，规则复用、权限管理、通知模板和事件处理都会变得分散。
夜莺的产品架构如下：
在这个架构里，用户配置的告警规则可以同时生效到多个时序库，不需要为每个时序库分别维护一套规则。夜莺负责周期性查询数据源，根据规则生成告警事件，再通过通知媒介或事件平台分发出去。
多机房场景下的边缘告警引擎
如果公司有多个机房，且中心机房和边缘机房之间的网络链路不稳定，把所有告警判定都放在中心端会带来风险：告警引擎频繁查询远端数据源，一旦网络抖动，就可能出现查询超时或告警不准确。
夜莺支持把告警引擎下沉部署到各个机房。这样即便边缘机房和中心机房之间的链路中断，也不影响边缘机房基于本地数据源做告警判定。
这个设计适合多地域、多数据中心、边缘网络质量不稳定的企业。中心端仍然可以负责规则管理，边缘端则负责靠近数据源执行告警判定。
优势一：告警规则配置灵活
夜莺最核心的优势在告警引擎和告警规则管理。相比只在配置文件中维护规则，夜莺提供了更完整的 Web 化规则配置能力。
夜莺的告警规则可以覆盖这些典型需求：
- 数据源支持配置多个，也可以选择全部，让一条告警规则生效到多个数据源。
- 告警规则支持多条查询条件，可以启用级别抑制，编写 PromQL 时也可以调出内置指标。
- 事件 relabel 可以对告警事件做二次处理，例如 drop 掉不需要的标签。
- 生效时间可以控制规则在工作日、周末、白天、夜间等不同时段的生效策略。
- 告警自愈可以在告警触发之后自动执行脚本，串联固定的止损操作。
- 回调地址可以在告警触发后调用第三方接口，对接钉钉、飞书或公司内部自定义接口。
这些能力的价值在于：告警规则不只是一个 PromQL 表达式，还包括生效范围、告警级别、通知逻辑、事件处理和自动化动作。夜莺把这些内容放到同一个规则管理体系中，便于团队维护。
优势二：内置模板和指标视图
夜莺除了对接时序库，还可以对接各类采集器 agent，比如 telegraf、categraf、datadog-agent 和各类 exporter。对于不同数据库和中间件，夜莺内置了一些现成的仪表盘和告警规则，帮助用户更快上手。
PromQL 在 Prometheus 生态里非常重要，但不是每个工程师都能熟练编写。夜莺的指标视图就是为这个问题设计的：资深工程师可以提前沉淀常用 PromQL，普通工程师通过中文指标名称直接查询。
这类能力适合在公司内部做监控知识沉淀。它把“会写 PromQL 的少数人”的经验，转化成“多数人可以直接使用”的平台能力。
边界一：仪表盘生态不如 Grafana
夜莺已经内置了不少仪表盘，但在可视化生态和看图能力上，Grafana 仍然更成熟。如果夜莺内置仪表盘已经能覆盖你的日常排障和巡检，就可以直接使用；如果对大盘样式、插件生态、复杂变量和展示效果要求更高，建议仍然使用 Grafana。
下图是夜莺内置的一个仪表盘样例：
更准确地说，夜莺和 Grafana 的分工不同：Grafana 更适合做统一可视化入口，夜莺更适合做统一告警入口。
边界二：告警降噪和 OnCall 能力不是夜莺重点
夜莺侧重多数据源告警、告警规则统一管理和告警事件分发。常见通知媒介，比如邮件、企微、飞书、钉钉，都可以支持；如果需要电话、短信或公司内部通知系统，也可以通过自定义通知脚本扩展。
但告警收敛降噪、排班、认领、升级、和 IM 深度打通等功能，不是夜莺开源版的重点。夜莺核心研发团队也做了一个 Flashduty SaaS 产品，专门解决这类事件管理问题。Flashduty 不是开源产品，但有免费套餐，小公司也可以尝试。
Flashduty 的逻辑是：Prometheus、Zabbix、夜莺、云监控、蓝鲸、SkyWalking 等监控系统负责产生告警事件，Flashduty 负责告警事件后续处理，包括降噪、排班、认领、升级和 IM 协同。
适合夜莺的使用场景
如果你的团队遇到下面这些问题，夜莺值得重点了解：
| 场景 | 夜莺解决方式 |
|---|---|
| 多套 Prometheus 或 VictoriaMetrics 规则分散 | 用夜莺统一管理告警规则和通知策略 |
| 希望研发团队自助配置告警 | 提供 WebUI、权限和业务组管理 |
| PromQL 门槛较高 | 通过内置指标、模板中心沉淀常用查询 |
| 多机房网络链路不稳定 | 使用边缘告警引擎靠近数据源判定 |
| 告警规则需要生效时间、屏蔽、自愈等能力 | 在规则体系中统一配置 |
如果你的主要诉求是复杂可视化，Grafana 仍然更合适；如果主要诉求是值班排班和告警事件全生命周期管理，则需要引入专门的 OnCall 或事件管理系统。
FAQ
夜莺和 Prometheus 是替代关系吗？
不是。夜莺和 Prometheus 更像协同关系。Prometheus 负责采集、存储和查询指标，夜莺负责统一管理告警规则、查询多个数据源并产生告警事件。
夜莺适合只部署一套 Prometheus 的小团队吗？
可以。小团队可以先把夜莺作为告警规则管理和通知管理入口使用。如果暂时不需要多数据源和边缘告警，也可以从最简单的单中心架构开始。
夜莺是否必须搭配 Categraf 使用？
不是必须。夜莺可以直接对接已有的 Prometheus、VictoriaMetrics、Thanos 等数据源。使用 Categraf 的好处是可以获得机器列表、基础指标采集、部分模板和更顺滑的集成体验。
夜莺是否能替代 Grafana？
通常不建议这么理解。夜莺有仪表盘能力，但 Grafana 在可视化生态上更强。更常见的组合是 Grafana 负责看图，夜莺负责告警。
总结
夜莺没有 Prometheus 的用户广，但夜莺解决的不是“重新做一个 Prometheus”，而是把 Prometheus 生态里分散的告警规则、通知媒介、多数据源查询和团队自服务能力整合起来。
原文发布时，夜莺企业用户已经覆盖上千家，包括移动、联通、电信、米哈游、莉莉丝、途游、悠星、高济、益丰、大参林、方正证券、国泰君安、海底捞、海康、搜狐、新浪等。夜莺开源项目背后有商业公司 flashcat.cloud 持续支持，也托管在基金会，具备持续演进的基础。
如果你的团队正在使用 Prometheus、VictoriaMetrics 或 Thanos，又希望把告警能力做成统一、可管理、可开放给团队自服务的平台，夜莺值得在日常工作中尝试。
