核心改造
夜莺监控（Nightingale）V5 基本覆盖了指标监控的主要场景，可以对多种数据源完成统一可视化、统一告警配置和统一管理。不过，可观测性领域通常说的“三支柱”是 metrics、logs、traces，只解决 metrics 还不够。
夜莺 6.x 的核心改造方向，就是从指标监控扩展到 metrics、logs、traces 的统一接入和使用。这里的思路不是在日志、链路追踪领域重复造轮子，而是把 DataSource 的概念从 metrics 扩展到 logs、traces：通过配置不同 DataSource，把指标、日志、链路追踪数据集成进来，完成统一可视化、统一告警，并提升监控分析效率。
这次改造主要包含三件事：
- DataSource 产品化管理：夜莺 5.x 在配置文件里管理 DataSource，也就是 Readers 配置项。6.x 希望把这部分管理逻辑做到页面上。
- 重新规划模块：夜莺 5.x 包含
n9e-webapi和n9e-server两个模块。6.x 希望合并为一个中心进程，姑且称为n9e-center，让用户部署一个进程即可接入多个 DataSource。 - 优化 agent 失联告警：在 PUSH 模型下，agent 失联比较难处理。当前逻辑是自动生成
target_up指标标识 agent 是否存活，但数据存在滞后性，6.x 计划解决这个问题。
对于网络连通性较差的地域，监控数据通常会下沉到地域内存储。此时，告警引擎和数据转发模块也应尽量离数据更近。因此，中心的 n9e-center 是必选的，可选的 n9e-alerting-engine 和 n9e-pushgateway 可以下沉到各个地域。
贪多嚼不烂，先把这些做好，系统就已经具备比较清晰的架构基础。
系统架构
下面是一个前期架构图，用来表达当时的设计想法。后续细节可能调整，但总体框架大体如此：
图中画了 4 个 Region：
- Beijing 区域部署中心的
n9e-center、MySQL，以及中心时序库 VictoriaMetrics。 - Beijing 和 Shanghai 的网络链路比较好。Shanghai 部署 CK、ES、Jaeger，Beijing 的
n9e-center可以直连读取 Shanghai 区的数据，并对 Shanghai 区的数据做告警判断。 - Beijing 和 Sgp 的两个机房链路不好，因此告警引擎
n9e-alerting-engine下沉到 Sgp 的两个机房，只对本机房数据做告警判断。 n9e-pushgateway只下沉到 Sgp02，没有部署在 Sgp01，是因为 Sgp01 使用 Prometheus 拉取各个 Exporter 的数据，走 PULL 模型；Sgp02 使用各种 PUSH 型 agent。
register targets 表示设备注册。这个能力可以没有：比如已有 Prometheus 通过 PULL 方式拉取监控数据，拉到数据后直接写入时序库，数据没有流经 n9e-pushgateway。这种场景不影响看图，也不影响告警。
但对于 PUSH 型架构，如果需要对 agent 是否存活做告警，注册 target 的逻辑就很关键。这个部分后续可以单独写文章分享。
部署方式怎么选
这个架构的判断原则很简单：看网络连通性，也看数据存储位置。
| 场景 | 推荐部署方式 | 原因 |
|---|---|---|
| 多个机房之间网络连通性好 | 中心部署一个 n9e-center，对接多个数据源 |
中心可以直接读取各地数据并统一告警 |
| 某个地域网络链路不好 | 地域内单独搭建时序库 + 告警引擎 + 可选 Pushgateway | 告警计算尽量靠近数据，减少跨地域链路依赖 |
| PULL 模型为主 | 不一定需要 Pushgateway | Prometheus 可直接拉取 exporter 并写入时序库 |
| PUSH 型 agent 为主 | 需要关注 Pushgateway 和 target 注册 | agent 存活判断、设备注册和上报链路更关键 |
后记
通过这次架构改造，夜莺和 Grafana 会有相似之处，也会保持各自侧重。
Grafana 专注于可视化，可以对接不同数据源，提供强大的可视化能力，并附带简单的告警功能。夜莺更擅长告警：对接各种数据源，覆盖“三支柱”，并在告警规则、订阅规则、屏蔽规则、告警事件、自愈机制、设备管理等方面继续强化。
同时，夜莺在 V5 版本中，可视化能力已经有了明显进步。到 6.x 架构里，夜莺希望在保持告警优势的同时，把 DataSource、日志、链路追踪和多地域部署的能力进一步产品化。
