核心要点
- 夜莺监控（Nightingale）的核心定位是告警引擎，重点解决多数据源告警规则统一管理、告警判定和事件分发问题。
- 最经典的夜莺部署模式是：数据采集和存储由 Prometheus、VictoriaMetrics、ElasticSearch 等系统负责，夜莺只周期性查询数据源做告警判定。
- 如果希望指标数据统一从采集器推送到夜莺，再由夜莺转存到时序库，可以使用 Categraf + 夜莺 Pushgw 的模式。
- 多机房或弱网络场景下，可以部署
n9e-edge，让边缘告警引擎靠近本地数据源执行告警判定。 - 选择架构时不要先追求复杂形态，应先判断夜莺是否需要介入数据链路，以及告警引擎是否必须下沉到边缘机房。
为什么夜莺要提供多种架构模式
IT 稳定性保障越来越重要。原文提到，国外数据统计中，监控、可观测性相关支出大概占总体 IT 支出的 5%～8%。CNCF 旗下 Kubernetes、OpenTelemetry、Prometheus 等项目，也都和云原生与可观测性紧密相关。
可观测性领域通常讲三大支柱：Metrics、Logs、Traces，也就是三类数据。
为了建设这些可观测性数据基座，各个公司往往会建设多套系统：
- Metrics：Zabbix、Prometheus、VictoriaMetrics
- Logs：ELK、ClickHouse、OpenSearch、Splunk
- Traces：Jaeger、Skywalking、SigNoz
再加上公有云上的云监控、云日志等系统，一个中型公司相关系统超过 5 套很常见。系统一多，就会出现一个自然问题：哪些能力可以整合为一个系统，避免体验分散、入口不一致、规则管理重复？
Grafana 主要整合看图可视化能力；ClickHouse 在存储领域有很强的扩展野心；PagerDuty、Flashduty 侧重事件 OnCall。夜莺尝试整合的是告警能力：对接常见数据源，让用户配置告警规则，周期性查询数据源里的数据，对数据做异常判定并生成告警事件。
夜莺项目简介
夜莺监控（Nightingale）是一款侧重告警的监控类开源项目。它和 Grafana 一样支持对接多种既有数据源，但二者重点不同：Grafana 更侧重可视化，夜莺更侧重告警引擎、告警事件处理和告警分发。
夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日捐赠给中国计算机学会开源发展委员会（CCF ODC），是 CCF ODC 成立后接受捐赠的第一个开源项目。
项目地址如下：
架构模式一：夜莺仅作为告警引擎
夜莺最经典、最精简的架构，是不介入数据采集和传输链路，只作为告警引擎使用。
在这个模式里，夜莺可以对接各类数据源，比如 Prometheus、VictoriaMetrics、ElasticSearch、MySQL、ClickHouse、Doris、OpenSearch、PostgreSQL 等。用户在夜莺里配置数据源和告警规则，夜莺内置的告警引擎周期性查询数据源并生成告警事件。
生成告警事件之后，夜莺再通过 Flashduty、Slack 或其他通知媒介把告警分发出去。为了让用户配置告警规则、查看告警事件，夜莺提供 Web UI 和 API；为了保存规则、用户、权限、缓存等数据，夜莺依赖 MySQL 和 Redis。
需要注意的是，Nightingale-Web-API 和 Nightingale-Alerting-Engine 是 n9e 进程里的两个职能，并不是两个独立进程。
这个模式适合谁
如果你已经有 Prometheus、VictoriaMetrics、ElasticSearch、ClickHouse 等数据源，并且数据采集链路已经稳定，建议从这个模式开始。它最简单，也最贴近夜莺的核心定位：让夜莺只做告警规则管理、告警判定和事件分发。
架构模式二：让指标数据流经夜莺
如果希望夜莺参与指标数据链路，也可以让采集器把数据推送给夜莺，再由夜莺转存到时序库。不过，夜莺本身不负责采集数据，需要和采集器协同。
夜莺可以和 Categraf 配合，采集 OS、数据库、中间件、SNMP 等监控数据。Categraf 会把采集到的数据推送给夜莺；夜莺没有内置时序数据存储（TSDB），所以会把数据转发到 Prometheus、VictoriaMetrics 等时序库。
如果把数据采集和转存逻辑也画进架构图，就会变成下面这样：
上图省略了通知媒介，也没有展开 n9e 进程内部的两个职能，重点是突出数据采集和转存链路。
Categraf 需要部署在所有待监控机器上，因为 CPU、内存、磁盘、网络、IO 等监控数据需要读取本机信息。所有 Categraf 把采集的监控数据推送给夜莺，夜莺再转存到 TSDB。图中示例转存到 VictoriaMetrics，它是和 Prometheus 兼容的时序库，并支持集群模式。
具体而言，需要在夜莺配置文件 config.toml 中配置 Pushgw.Writers，指向时序库的 Remote Write 地址。夜莺收到监控数据之后，就会转发给这个地址。
这个模式适合谁
如果你希望通过 Categraf 统一采集机器、中间件、数据库等指标，并且希望机器列表、心跳、元信息、Nodata 告警等能力和夜莺打通，可以选择这个模式。
如果你已经完全使用 Prometheus + Exporter 采集，并且采集链路管理得很好，就不一定要让数据流经夜莺。
架构模式三：边缘告警架构
边缘架构模式主要解决多机房、弱网络或单向网络场景。典型前提包括：
- 公司有多个机房，不同机房之间网络链路不稳定，甚至只有单向连通。
- 不同机房可能单独部署了时序库、日志库等数据源。
- 希望在中心端夜莺 Web 上统一管理告警规则。
- 告警引擎需要频繁访问数据源，因此最好部署在数据源旁边，避免网络问题影响告警判定。
在这种情况下，除了中心端的 n9e，边缘机房还可以部署 n9e-edge。引入 n9e-edge 后，架构如下：
以图中场景为例，中心机房部署夜莺 n9e 进程。机房 A 和中心机房之间网络质量较好，中心机房的 Prometheus、VictoriaMetrics 可以直接交给中心 n9e 进程负责告警判定。
但机房 B 和中心机房之间网络链路不好，而机房 B 内部也有 Prometheus、VictoriaMetrics。此时建议在机房 B 内部部署 n9e-edge 进程，负责机房 B 两个时序库的告警判定。
n9e-edge 会从中心端 n9e 同步告警规则到内存。如果网络断了，短期内只是告警规则无法更新；n9e-edge 仍然可以根据内存中的规则周期性查询本机房时序库，生成告警事件，并通过外网出口投递给钉钉、飞书、Slack、Flashduty 等通知媒介。
这个模式适合谁
如果你的告警数据源分布在多个机房，且跨机房网络延迟高、抖动大或不稳定，就应该考虑边缘告警架构。告警判定是高频动作，把判定逻辑放在数据源附近，可靠性通常更高。
三种模式如何选择
| 架构模式 | 夜莺是否介入采集链路 | 是否需要 n9e-edge |
适合场景 |
|---|---|---|---|
| 仅作为告警引擎 | 否 | 否 | 已有稳定采集和存储，只想统一告警 |
| 数据流经夜莺 | 是 | 否 | 使用 Categraf，想打通机器列表、心跳和指标转发 |
| 边缘告警架构 | 可选 | 是 | 多机房、弱网络、数据源分散在边缘机房 |
实践中不建议一开始就把三种能力全部用上。更稳妥的路径是：
- 先让夜莺作为告警引擎，对接已有数据源。
- 如果需要更好的机器采集体验，再引入 Categraf 和 Pushgw 转发链路。
- 如果跨机房网络影响告警判定，再部署
n9e-edge。
FAQ
夜莺必须负责采集数据吗？
不必须。夜莺最核心的用法是作为告警引擎，直接查询已有数据源。如果数据采集和存储已经由 Prometheus、VictoriaMetrics 等系统完成，夜莺不需要介入采集链路。
夜莺为什么依赖 MySQL 和 Redis？
夜莺需要保存用户、权限、数据源、告警规则、通知配置和历史告警事件等数据，因此依赖 MySQL；部分缓存数据则使用 Redis。
n9e-edge 断网后还能继续告警吗？
在已同步规则的前提下，可以继续基于内存中的告警规则查询本机房数据源并做告警判定。断网期间的主要影响是规则无法从中心端更新，部分事件也可能无法写回中心端。
总结
夜莺监控的架构可以从一个问题出发理解：告警引擎应该离数据源多近？
如果数据源集中、网络可靠，中心端 n9e 直接查询数据源即可；如果希望统一采集机器指标，可以让 Categraf 把数据推给夜莺，再由夜莺转发到时序库；如果数据源分散在弱网络机房，则应该把 n9e-edge 部署到边缘机房，让告警判定靠近数据源。
更多信息可以参考夜莺 官方文档。
