夜莺监控设计思考（二）边缘机房架构思考
这将是一个系列，讲解 夜莺监控 的设计思考，可以理解为原理+最佳实践+产品设计时的折中取舍。
本系列其他文章：
下面开始第2篇。
上一篇我们遗留了一个话题，就是如果贵司有多个数据中心，而且数据中心之间网络链路较差，此时应该怎么办？
夜莺边缘架构模式
举个例子，假设有北京、上海、美东三个数据中心，北京和上海之间有良好的专线打通，而美东和国内网络链路较差。
北京、上海、美东三地均部署了服务，指标和日志都选择落在本地，而非传输到中心。假设指标使用 VictoriaMetrics 存储，日志使用 ElasticSearch 存储，整体示例如下：
北京、上海机房既然网络链路很好，姑且可以看做是同一个机房，用一套夜莺统一处理，比如就把夜莺部署在北京机房，让夜莺读取北京、上海的数据源，做告警判定。那美东呢？让北京机房的夜莺读取美东的数据源做告警是不行的，因为网络链路不好，经常超时。
告警判定是周期性的，比如15秒一次，很频繁，我们需要确保查询时网络链路是好的，最佳实践就是把告警引擎直接部署到美东，这样本机房查询，就没问题了。
所以，夜莺引入了边缘机房部署架构。可以把告警引擎抽离出来作为一个单独的模块，部署到美东。这个模块可以从中心端夜莺同步告警规则，把告警规则存在内存里，然后查询本地数据源的数据，做告警判定。
架构示意图：
夜莺中心端的进程叫 n9e，n9e 是 nightingale 的缩写，边缘机房（这里是指美东机房）单独部署了一个 n9e-edge 进程。
n9e-edge 进程要连中心端的 n9e，所以你在 n9e-edge 的配置文件里，需要指定 n9e 的 HTTP 地址和认证信息（如需）。
如果美东和北京的网络临时中断了，影响也不大，美东的 n9e-edge 没法从北京的 n9e 同步告警规则了，不算太大的问题。另外 n9e-edge 产生的告警事件没法写到中心数据库了，所以你在页面上没法看到相关的告警事件，但只要美东的外网出口没问题，n9e-edge 产生的告警事件还是可以推送出去的，因为告警媒介都是走的外网，比如钉钉、企微、Slack，都是外网 SaaS 服务。
预告
本篇先到这里。下一篇预告：夜莺没有自研时序存储，却又提供了 agent，有点拧巴，到底是为啥？
