高级部署方案：告警引擎下沉部署方案

如果各个机房的网络链路很好，就直接让各个机器上的 agent 直连中心的 n9e 进程（就是那个 17000 端口）就可以了，如果网络链路不好，可以在边缘机房部署专门的 n9e-edge。也就是本文要介绍的方案。

20230602122823

假设中心机房部署了一套夜莺，region01、region02 是两个边缘机房，和中心机房之间的网络不好。此时，我们可以把时序库下沉部署到边缘机房，避免大量时序数据传输到中心机房带来的网络带宽压力，同时也可以避免网络不好的情况下，agent 无法及时上报数据的问题。由于时序库已经下沉部署了，夜莺的组件也需要做出相应的下沉部署。

从 v6.0.0.ga.9 开始，合并了 n9e-alert、n9e-pushgw 模块为 n9e-edge，应对边缘机房的场景。n9e-edge 不依赖 mysql、redis，只依赖中心端的 n9e，所以 edge.toml 配置文件里，需要配置中心端 n9e 的地址。

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

认证信息（BasicAuthUser、BasicAuthPass）对应中心端 n9e 的 HTTP.APIForService.BasicAuth 配置段。

可以通过如下命令启动 n9e-edge：

  1. nohup ./n9e-edge --configs etc/edge &> edge.log &

如果机房之间网络链路很好，就让所有的 categraf 和中心端的 n9e 通信即可，如果某个机房和中心端网络链路不好，就让 categraf 和 n9e-edge 通信，n9e-edge 和中心端的 n9e 通信。

边缘机房的 n9e-edge 默认的引擎名字是 edge，与中心端 n9e 的引擎名字（default）相区分。注意：边缘机房的时序库在夜莺里添加数据源的时候，要选择边缘机房的告警引擎（edge）。如果你有两个边缘机房，注意两个边缘机房的 n9e-edge 的引擎名字要不一样。下图是配置数据源的时候，选择告警引擎的地方：

20230531105059

图中 region02 的机房中采集器使用的是 vmagent，并把采集的数据直接写入时序数据库，通过 n9e-edge 对监控数据做告警判断。这种架构比较简洁，但是会有一点点小问题，由于采集数据没有流经 n9e-edge，就没法从数据流中解析出机器信息，也就没法把机器信息写入数据库 target 表，也就导致页面上机器列表页面看不到相关的机器。这不影响告警，看图这些核心功能，只是用不了机器分组，自定义标签，告警自愈之类的功能。

更推荐使用 Categraf + n9e-edge 的方式来采集数据，其架构如图 region01 所示。当 Categraf 采集的数据上报给 n9e-edge 后，n9e-edge 就可以从监控数据中解析出机器信息，然后通过中心端的 n9e 写入数据库 target 表，这样就可以在页面上看到机器列表了。就可以使用机器分组，自定义标签，告警自愈之类的功能。

边缘机房的 n9e-edge 如果只有一个实例，挂了就麻烦了，如何做高可用？简单，只需要在边缘机房部署多台 n9e-edge 就可以了，注意，同一个 edge 集群，edge.toml 里配置的 EngineName 要一样。n9e-edge 前面再搞个负载均衡，给 agent 上报数据、心跳使用，这样就可以实现 n9e-edge 的高可用了。

注意：

categraf 向 n9e-edge 心跳的话，urlpath 就不能写 /v1/n9e/heartbeat 了，而要写成 /v1/n9e/edge/heartbeat。