一张图详解开源监控夜莺（Nightingale）的架构

核心要点

• 夜莺监控（Nightingale）采用 All-in-One 的设计理念，把 WebUI、告警引擎、指标接收转发等能力收敛在 n9e 进程中。
• 夜莺架构可以分成三部分：左侧采集器、中间夜莺服务端、右侧告警通知通道。
• Pushgateway 是可选能力，用于接收 Categraf、datadog-agent、telegraf 等采集器推送的指标，再通过 remote write 转发到时序库。
• AlertEngine 是夜莺的核心能力，负责按告警规则周期性查询数据源并生成告警事件。
• 多机房弱网络场景下，可以使用 n9e-edge 把告警判定下沉到边缘机房，减少跨地域查询带来的不确定性。

夜莺监控是一款开源云原生观测分析工具，采用 All-in-One 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，并与云原生生态集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日在 GitHub 上发布 v1 版本，已累计迭代 100 多个版本。

夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日捐赠给中国计算机学会开源发展委员会（CCF ODC），成为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺核心研发团队也是 Open-Falcon 项目原核心研发人员，从 2014 年 Open-Falcon 开源算起，已经长期投入监控领域。

夜莺整体架构

从架构图看，夜莺可以分成三大部分：

• 中间紫色部分：夜莺服务端相关模块，是夜莺核心组件，包括 n9e 进程本身，以及依赖的 MySQL、Redis。图上也画了 VictoriaMetrics 和 Prometheus，这部分不是夜莺必需组件，而是常见的后端时序库。
• 左侧蓝色部分：各类采集器。夜莺推荐使用 Categraf，因为它和夜莺整合最顺滑；也可以使用 telegraf、datadog-agent 等社区常见采集器。
• 右侧红色部分：告警通道。夜莺可以把告警发给钉钉、企微、飞书、Slack 等 IM，也可以发邮件、电话、短信，或通过 Webhook 推给第三方。如果有告警收敛、降噪、排班、认领升级等诉求，可以接入 Flashduty 事件 OnCall 中心。

这张图的核心不是“所有组件都必须部署”，而是说明夜莺在监控体系中的位置：采集器负责把数据送进来，时序库负责存储指标，夜莺负责规则管理、告警判定和事件分发。

夜莺服务端：n9e 进程的三个职能

中间灰色部分是夜莺服务端，即 n9e 进程，包含三个主要功能：

• Pushgateway：接收各类采集器推送的指标数据，并转发给时序库。这个能力是可选的。
• WebUI：夜莺的 Web 界面，供用户配置监控、查看监控数据、查看告警事件。
• AlertEngine：告警引擎，根据用户配置的告警规则连接各个时序库数据源，查询数据并做异常判断。

下面逐一解释。

Pushgateway：接收并转发指标数据

Pushgateway 是 n9e 进程的一部分能力，可以接收各类采集器推送的指标数据，然后转发给时序库。

不同采集器推送的数据格式不同。例如 Categraf 按 Prometheus remote write 协议推送，datadog-agent 有自己的格式，telegraf 则比较开放，支持 OpenTSDB、InfluxDB、Prometheus 等格式。Pushgateway 提供多种数据接收接口，收到数据后再把监控指标转发给时序库。

以 Categraf 为例，Categraf 采集数据后推送给夜莺，需要配置服务端地址，配置样例如下：

[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"
basic_auth_user = ""
...

这里的 127.0.0.1:17000 要替换成你的夜莺地址。/prometheus/v1/write 是夜莺提供的 API，用于接收 Prometheus remote write 协议的数据。夜莺还提供其他数据接收 API，具体可以参考这里。

夜莺收到数据后，需要知道转发给哪个时序库。这个目标地址在夜莺配置文件 etc/config.toml 中配置：

[[Pushgw.Writers]]
Url = "http://127.0.0.1:9090/api/v1/write"
...

这里的 127.0.0.1:9090 是 Prometheus 地址样例。夜莺转发数据给时序库也走 Prometheus remote write 协议，因此 URL path 是 /api/v1/write。配置文件是 TOML 格式，[[]] 表示数组，所以可以配置多份 [[Pushgw.Writers]] 区块，让夜莺同时转发数据给多个时序库。

什么时候不需要 Pushgateway

如果你不用 Categraf，而是使用 Prometheus 直接抓取各类 exporter 的数据，数据已经写入时序库，那么 Pushgateway 就不是必需能力，夜莺配置文件里也不需要配置 Pushgw 相关信息。

但如果不使用 Categraf，夜莺的机器列表会为空，告警自愈功能也无法使用。因此推荐至少用 Categraf 采集机器常规指标，并部署到每台机器上；至于中间件、数据库等监控数据，可以继续使用你熟悉的采集方式。

另外，Categraf 的 conf/config.toml 中还有 heartbeat 配置，需要把地址改成夜莺的 heartbeat 地址。heartbeat 会采集机器元信息上报给夜莺，之后可以在夜莺机器列表中点击机器查看元信息。

WebUI：规则、数据和事件的管理入口

夜莺提供 WebUI 页面，用于查看监控数据、管理告警规则、查看生成的告警事件等。页面有权限控制体系，如果你想把监控能力开放给公司所有团队，让各团队自助配置规则和查看数据，权限体系就很有价值。

夜莺 v7 默认监听端口是 17000，可以在浏览器中使用：

http://your_n9e_ip:17000

如果想修改端口，可以修改配置文件 etc/config.toml 中的 HTTP.Port 配置项，在配置文件中搜索 17000 就能找到对应位置。

AlertEngine：夜莺的核心告警引擎

告警引擎是夜莺最核心的能力。很多公司有多个时序库，如果每个时序库都单独管理告警规则，维护成本会很高。使用夜莺后，可以在一个地方维护告警规则，再生效到不同的数据源。

要让夜莺对某些时序库做告警，首先需要在页面配置数据源。夜莺支持 Prometheus 兼容的各类数据源，比如 Thanos、VictoriaMetrics、M3DB、Prometheus，也支持接入 TDEngine、Loki 等数据源，对这些数据源的数据做告警判断。

注意：即便某个时序库已经在夜莺 etc/config.toml 的 [[Pushgw.Writers]] 中配置过，仍然需要在夜莺 WebUI 页面配置数据源。原因是 Pushgw 配置解决的是“数据往哪里写”，而告警引擎的数据源配置解决的是“告警规则去哪里查”。

告警引擎会根据告警规则中的 PromQL，周期性查询时序库。如果查到了数据，就产生告警事件；查到几条数据，就产生几条事件。如果规则配置了持续时长，则需要连续几次查询都查到异常数据，才会产生告警事件。

告警引擎的判定逻辑可参考：触发告警和恢复的底层逻辑是什么？。

服务端高可用

夜莺依赖 MySQL、Redis。MySQL 和 Redis 的高可用方案社区里有很多，这里不展开。

对于 n9e 进程本身，高可用设计比较简单：找多台机器，每台机器部署一个 n9e 进程，集群中的多个 n9e 进程配置保持一致。

多个 n9e 前面最好放一个负载均衡。用户访问夜莺使用负载均衡地址，Categraf 中配置的夜莺地址也建议使用负载均衡地址。

边缘模式：让告警引擎靠近数据源

如果某公司有多个机房，且某个机房与其他机房网络质量很差，就会出现告警判定不稳定的问题。

例如，夜莺 n9e 进程部署在北京，某个时序库部署在美东。美东和北京网络不好时，中心 n9e 作为告警引擎周期性查询美东时序库，就可能经常超时，导致告警不准确。

夜莺提供 n9e-edge 模块用于这类边缘机房场景。可以把 n9e-edge 部署在美东，它会从中心 n9e 同步告警规则并缓存在内存中，然后查询美东本地时序库做告警判定。即便美东和国内网络断了，n9e-edge 内存中仍缓存了一份告警规则，可以继续判定告警。

n9e-edge 需要连接中心 n9e 的 API，因此要在 n9e-edge 配置文件中填写中心 n9e 地址，即 CenterApi 相关配置项。具体可以参考：边缘机房部署夜莺，应对网络割裂的情况。

常见部署选择

FAQ

夜莺的 n9e 是多个进程吗？

不是。WebUI、Pushgateway、AlertEngine 都是 n9e 进程内的职能，不是三个独立进程。

Pushgw 配置和 WebUI 数据源配置有什么区别？

Pushgw 配置决定采集器推来的指标数据要写入哪个时序库；WebUI 数据源配置决定告警规则要查询哪个数据源。一个负责写入链路，一个负责查询链路。

不使用 Categraf 会影响夜莺告警吗？

不影响夜莺对已有数据源做告警判定。但不使用 Categraf 时，夜莺机器列表、机器元信息和部分告警自愈相关能力无法使用。

总结

夜莺架构的核心可以概括为一句话：采集器和时序库负责数据，夜莺负责告警规则管理、告警判定和告警事件分发。

如果你只需要统一告警，部署 n9e 并对接已有数据源即可；如果希望打通机器采集体验，可以引入 Categraf 和 Pushgateway；如果存在多机房弱网络场景，则使用 n9e-edge 把告警引擎部署到数据源附近。

夜莺 GitHub 地址是：https://github.com/ccfos/nightingale。如果你对这个开源项目感兴趣，可以 star 一下留备后用。