边缘机房部署夜莺，应对网络割裂的情况

在这个架构模式下，中心端部署 n9e + mysql + redis，边缘机房部署 n9e-edge，整体架构如下：

20240222102119

上例中，演示了 3 个机房的部署架构，其中机房 A 和中心机房之间网络链路很好，机房 B 和中心机房之间的网络链路不太好，各个机房都有时序库。所以，中心机房的夜莺告警引擎直接处理中心机房和机房 A 的时序库，机房 B 的时序库由机房 B 的告警引擎处理，也就是图中的 n9e-edge，n9e-edge 会从中心机房的夜莺同步告警规则，然后对本机房的时序库做告警判定。

这样一来，即便机房 B 和中心机房之间网络割裂，由于 n9e-edge 内存中早就同步到了告警规则，所以机房 B 的告警引擎还是可以正常处理机房 B 的两个时序库的告警判定工作。提升了监控系统整体高可用性。

n9e-edge 的配置文件默认放在了 etc/edge 目录下，启动 n9e-edge 的方法如下：

  1. ./n9e-edge -configs etc/edge

当然，生产环境需要使用 systemd 启动，上面我只是方便测试和说明问题。etc/edge/edge.toml 中的关键配置是 [CenterApi]，如下：

  1. [CenterApi]
  2. Addrs = ["http://127.0.0.1:17000"]
  3. BasicAuthUser = "user001"
  4. BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"
  5. # unit: ms
  6. Timeout = 9000

Addrs 字段配置了中心端 n9e 进程的连接地址。Timeout 是超时时间，单位是毫秒。BasicAuthUser 和 BasicAuthPass 是认证信息，如果中心端没有开启认证，这两个字段可以不填。认证信息对应中心端的 etc/config.toml 中的 [HTTP.APIForService] 配置。比如：

  1. [HTTP.APIForService]
  2. Enable = true
  3. [HTTP.APIForService.BasicAuth]
  4. user001 = "ccc26da7b9aba533cbb263a36c07dcc5"

这样就完成了边缘机房部署架构的部署。

但是，如果 n9e-edge 进程挂了怎么办？如果想提升可用性，可以在机房 B 部署多个 n9e-edge 进程，多个 n9e-edge 会互备，比如机房 B 总共有 100 条告警规则要处理，部署了两个 n9e-edge 实例，那么每个 n9e-edge 实例会处理 50 条规则，如果其中某个实例挂了，另一个实例会接管所有的 100 条规则，保证了告警引擎的高可用性。相当于机房 B 的多个 n9e-edge 实例组成了一个集群，这个 edge 集群需要一个共同的名字，配置在 etc/edge/edge.toml 中的 [Alert.Heartbeat] 部分，如下：

  1. [Alert.Heartbeat]
  2. # auto detect if blank
  3. IP = ""
  4. # unit ms
  5. Interval = 1000
  6. EngineName = "region-b"

EngineName 就是这个 edge 集群的名字，机房 B 的多个 n9e-edge 实例都要配置成这个名字。这样一来，中心端的 n9e 进程就会把机房 B 的告警规则分配给机房 B 的 n9e-edge 集群，n9e-edge 集群内部会自动分配告警规则，保证了告警引擎的高可用性。

页面上添加数据源的时候，会选择数据源要关联的告警引擎，这个告警引擎就是 n9e-edge 的名字（EngineName）。上面架构的实践方式：如果添加的是中心机房或机房 A 的数据源，就选择中心机房的告警引擎（即 default）；如果添加的是机房 B 的数据源，就选择机房 B 的告警引擎（比如 region-b，和 edge 的配置文件中的 EngineName 保持一致）。

另外，新版本 n9e-edge 需要依赖 redis，可以查看你下载的那个版本的默认配置文件，如果默认配置文件中 edge.toml 中有 redis 配置，就说明这个版本依赖 redis。如果 n9e-edge 部署了多个实例组成了集群（即多个 n9e-edge 的 EngineName 是相同的），一个集群使用一个单独的 redis 实例。