夜莺V6.X架构介绍

夜莺 6.x 相比 5.x 的核心变化，是把原来的 n9e-webapi 和 n9e-server 合并为一个 n9e 模块。n9e 同时承担前端 API、数据转发和告警引擎能力，默认部署形态更简单；在网络链路较差、ACL 限制较多或边缘机房无法稳定连通中心服务端时，再使用下沉部署方案。

核心要点

• 默认场景优先采用中心汇聚式部署：多个 n9e 实例组成集群，统一依赖数据库和 Redis。
• Agent 能稳定访问中心端时，Categraf、Telegraf、Grafana Agent、Datadog Agent 等都可以直接把数据推给中心 n9e。
• 网络链路不稳定时，可把时序库、告警引擎和转发网关下沉到边缘机房，减少跨机房数据传输。
• 下沉部署仍需要考虑心跳、对象注册和告警规则同步，因此数据库网络连通性要提前规划。

中心汇聚式部署方案

这个方案的架构图如下：

中心汇聚式部署适合机房之间网络链路稳定、Agent 可以直连中心服务端的场景。夜莺服务端只保留一个核心模块 n9e，可以部署多个实例组成集群。n9e 依赖两个存储组件：数据库和 Redis；数据库可以使用 MySQL 或 Postgres，按团队现有技术栈选用即可。

n9e 提供 HTTP 接口，前面可以挂 4 层或 7 层负载均衡。常见做法是使用 Nginx 对外暴露统一入口。

n9e 接收到上报数据后，需要把数据转发给后端时序库。相关配置如下：

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

也就是说，虽然数据源可以在页面中配置，但上报数据的转发链路仍需要在配置文件中指定。

在这个架构中，所有机房的 Agent（例如 Categraf、Telegraf、Grafana Agent、Datadog Agent）都直接向中心 n9e 推送数据。它的优点是架构简单、维护成本低；前提是机房之间网络质量足够好，通常需要专线或稳定的内网链路。

边缘下沉式混杂部署方案

还是先上架构图，一图胜千言：

下沉式方案主要解决网络链路不稳定的问题。图中可以拆成三种情况理解：

1. 中心直连场景：A 机房和中心网络链路很好，Categraf 可以直接把数据上报到中心 n9e。
2. 边缘下沉场景：某个机房和中心网络链路不好，需要把时序库下沉部署；时序库下沉后，对应的告警引擎和转发网关也要跟随下沉，让指标写入、查询和告警计算尽量在本机房完成。
3. 已有 Prometheus 接入场景：如果某个环境已经有 Prometheus，数据采集没有走 Categraf，只需要把 Prometheus 作为数据源接入夜莺，就可以在夜莺中看图和配置告警规则。

第三种场景需要注意：如果没有 Categraf 等 Agent 向夜莺上报心跳，对象列表里可能看不到机器的 CPU、内存使用率，也无法使用告警自愈能力；但看图、查询和告警这些核心能力不受影响。

边缘机房下沉部署时序库、告警引擎、转发网关时，要重点关注依赖关系：

因此，下沉部署不是简单地把所有组件复制到边缘机房，而是要先打通告警引擎、转发网关到数据库的网络；Redis 不在这两个下沉模块的必要依赖中，无需额外为 Redis 打通跨机房链路。

选型建议

如果目标是快速上线、减少维护复杂度，优先选择中心汇聚式部署。只有在 Agent 到中心端网络不稳定、边缘机房有独立自治要求、或跨机房数据传输成本较高时，再采用边缘下沉式部署。

实践中也可以混合使用：网络好的机房直连中心，网络差的机房下沉时序库和告警引擎，已有 Prometheus 的环境直接以数据源方式接入夜莺。

小结

夜莺 v6.x 的架构调整，本质上是用一个 n9e 模块降低默认部署复杂度，同时保留边缘下沉能力来覆盖复杂网络环境。中心汇聚式方案适合大多数网络稳定的团队；边缘下沉式方案适合多机房、弱网络、已有 Prometheus 或边缘自治场景。

FAQ

Q1：夜莺 6.x 是否必须部署多个服务端模块？ A：默认不需要。常规场景只需要部署 n9e，它同时提供前端 API、数据转发和告警引擎能力。

Q2：页面配置了数据源之后，是否还要配置写入转发链路？ A：要。页面数据源主要用于查询和告警等能力，上报数据转发到后端时序库的链路仍需要在配置文件中指定。

Q3：已有 Prometheus 的环境还能接夜莺吗？ A：可以。把 Prometheus 作为数据源接入夜莺后，可以看图和配置告警规则；但如果没有 Agent 心跳，机器对象列表和告警自愈能力会受限。