这将是一个系列，讲解 夜莺监控 的设计思考。你可以把它理解为：原理、最佳实践和产品设计时的折中取舍。
本系列其他文章：
下面开始第 2 篇。
核心要点
- 夜莺边缘机房架构解决的是多数据中心、跨地域弱网络下的告警判定可靠性问题。
- 告警引擎会高频查询数据源，如果中心端跨机房访问远端数据源，经常超时就会影响告警准确性。
n9e-edge的作用是把告警判定下沉到边缘机房，让它靠近本地 Prometheus、VictoriaMetrics、ElasticSearch 等数据源。- 中心端
n9e仍负责统一规则管理，边缘端n9e-edge从中心同步规则并缓存到内存中执行。 - 网络临时中断时，边缘端规则短期无法更新，事件也可能无法写回中心，但本地告警判定和外部通知仍可继续工作。
上一篇遗留了一个问题：如果公司有多个数据中心，而且数据中心之间网络链路较差，此时应该怎么办？
问题场景：多数据中心和本地数据源
举个例子，假设公司有北京、上海、美东三个数据中心。北京和上海之间有良好的专线打通，但美东和国内网络链路较差。
北京、上海、美东三地都部署了服务，指标和日志都选择落在本地，而不是传输到中心。假设指标使用 VictoriaMetrics 存储，日志使用 ElasticSearch 存储，整体示例如下：
北京、上海机房之间网络链路很好，可以姑且看成一个大机房，用一套夜莺统一处理。例如把夜莺部署在北京机房，让夜莺读取北京、上海的数据源并做告警判定。
美东就不能这么处理。如果让北京机房的夜莺读取美东数据源做告警，跨地域网络经常超时，告警判定就会变得不可靠。
为什么告警引擎要靠近数据源
告警判定是周期性的，例如每 15 秒执行一次。这个动作非常频繁，并且对查询结果的稳定性很敏感。
如果告警引擎和数据源之间网络不稳定，会出现几类问题：
- 查询超时，导致本该触发的告警没有触发。
- 查询失败被误认为数据恢复，导致告警状态不准确。
- 网络抖动引入大量噪声，让排障人员难以判断是真故障还是链路问题。
- 中心端同时查询多个远端数据源时，整体延迟和失败率会被放大。
因此，弱网络场景下的最佳实践是把告警引擎部署到数据源旁边。这样告警引擎查询本机房数据源，网络链路更短、更可控。
夜莺边缘架构模式
夜莺为这种场景引入了边缘机房部署架构：把告警引擎抽离出来作为一个单独模块，部署到边缘机房。
这个边缘模块可以从中心端夜莺同步告警规则，把规则存在内存里，然后查询本地数据源的数据，做告警判定。
架构示意图如下：
夜莺中心端进程叫 n9e，n9e 是 Nightingale 的缩写。边缘机房单独部署的进程叫 n9e-edge。在图中的例子里，美东机房部署了一个 n9e-edge 进程。
n9e-edge 需要连接中心端 n9e，所以要在 n9e-edge 的配置文件中指定中心端 n9e 的 HTTP 地址和认证信息（如需）。
中心端和边缘端如何分工
夜莺边缘架构的关键，是把“规则管理”和“规则执行”分开：
| 职责 | 中心端 n9e |
边缘端 n9e-edge |
|---|---|---|
| 告警规则配置 | 负责 | 不负责 |
| 规则同步 | 提供规则接口 | 从中心拉取规则 |
| 告警判定 | 可负责中心数据源 | 负责边缘本地数据源 |
| 数据源访问 | 访问网络质量好的数据源 | 访问本机房数据源 |
| 告警事件展示 | 中心页面展示 | 尽量写回中心 |
| 外部通知 | 可通知 | 可直接通知钉钉、企微、Slack 等 |
这个分工的目标很明确：中心端统一管理，边缘端本地执行。
网络中断时会发生什么
如果美东和北京的网络临时中断，影响分几层看：
n9e-edge无法从北京的n9e同步最新告警规则。n9e-edge产生的告警事件可能无法写到中心数据库，因此页面上可能看不到相关事件。- 只要美东外网出口正常，
n9e-edge仍然可以把告警事件推送出去，因为钉钉、企微、Slack 等告警媒介都是外网 SaaS 服务。
所以，短时间网络中断不等于边缘机房失去告警能力。它主要影响规则更新和中心端事件可见性，不影响 n9e-edge 基于内存规则继续查询本地数据源并发出通知。
什么时候需要 n9e-edge
不是所有多机房都需要边缘架构。判断是否需要 n9e-edge，可以看几个条件：
| 判断问题 | 如果答案是“是” |
|---|---|
| 数据源是否分散在多个机房？ | 需要评估中心端查询延迟 |
| 跨机房网络是否经常超时或抖动？ | 倾向部署 n9e-edge |
| 告警判定是否依赖高频查询？ | 告警引擎应靠近数据源 |
| 边缘机房是否能访问外部通知媒介？ | 断网时仍可直接通知 |
| 是否需要中心统一管理规则？ | 使用中心 n9e + 边缘同步模式 |
如果北京、上海之间网络非常好，可以继续用中心 n9e 统一查询；如果美东、海外、专线不稳定机房经常出现查询超时，就应该考虑部署 n9e-edge。
FAQ
n9e-edge 是否需要直接访问中心数据库？
不需要。原文描述中，n9e-edge 是连接中心端 n9e 的 HTTP 地址和认证信息，从中心端同步告警规则，而不是直接读中心数据库。
网络断了以后，边缘规则会不会立刻失效？
不会。n9e-edge 会把同步到的规则缓存在内存中。网络断开后，规则短期无法更新，但已有规则仍然可以继续用于本地告警判定。
边缘机房产生的告警一定能在中心页面看到吗？
不一定。如果边缘机房到中心端网络中断，n9e-edge 产生的告警事件可能无法写回中心数据库，中心页面就可能看不到。但只要外网通知通道可用，告警仍然可以推送出去。
只有指标数据源才需要边缘告警吗？
不只指标。原文示例里既有 VictoriaMetrics 指标存储，也有 ElasticSearch 日志存储。只要告警判定需要频繁查询远端数据源，并且跨机房网络不稳定，都可能需要边缘化。
小结
夜莺边缘机房架构的核心不是把系统做复杂，而是让告警判定靠近数据源。
中心端 n9e 负责统一管理规则，边缘端 n9e-edge 负责在本机房查询本地数据源并执行告警判定。这样既保留中心化管理体验，又避免弱网络链路影响告警准确性。
本篇先到这里。下一篇预告：夜莺没有自研时序存储，却又提供了 agent，有点拧巴，到底是为什么？
