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

在这个架构模式下,中心端部署 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 实例。