当前位置：首页 > article >正文

夜莺监控 - 边缘告警引擎架构详解

article 2026/4/4 2:36:59

前言

夜莺类似 Grafana 可以接入多个数据源，查询数据源的数据做告警和展示。但是有些数据源所在的机房和中心机房之间网络链路不好，如果由 n9e 进程去周期性查询数据并判定告警，那在网络链路抖动或拥塞的时候，告警就不稳定了。所以，夜莺引入了边缘告警引擎：n9e-edge。n9e-edge 进程部署在边缘机房，和边缘机房的时序库部署在一起，由 n9e-edge 负责边缘机房的告警判定工作，这样整个架构就稳定的多了。

架构详解

为了说明这个架构下的告警引擎工作原理，我画了一张架构图：

我们这里假设贵司有 3 个机房：中心主力机房、边缘机房 A 和边缘机房 B，其中边缘机房 A 和中心机房之间有专线，网络链路很好，边缘机房 B 和中心机房之间没有专线，走公网，网络链路不够可靠。

n9e 进程部署在中心主力机房，n9e 依赖 mysql 和 redis，所以 mysql 和 redis 也部署在中心主力机房。如果你想做高可用，中心机房的 n9e 可以部署多个实例，配置文件保持一致，连同一个 mysql 和 redis 即可。

上图中，我们有 5 个数据源：

中心机房有一套 Loki，一套 ElasticSearch
边缘机房 A 有一套 ElasticSearch，一套 Prometheus
边缘机房 B 有一套 VictoriaMetrics

我们希望在中心 n9e 统一查看这 5 个数据源的数据，所以要把这 5 个数据源的访问地址配置到夜莺中，菜单位置：集成中心-数据源，如下图所示：

中心 n9e 可以通过内网地址直接连通中心机房和边缘机房 A 的数据源，但是无法直接连通边缘机房 B 的数据源（因为没有专线），那只能把边缘机房 B 的 VictoriaMetrics 暴露一个公网地址（假设地址为 ex.a.com）出来，中心 n9e 通过公网地址访问边缘机房 B 的 VictoriaMetrics，如下：

架构图中的 1、2、3、4、5 这 5 条线，表示中心 n9e 和 5 个数据源的连接关系。用户在查询数据的时候，是在 n9e 的 web 上查的，发请求给 n9e 进程，n9e 进程此时相当于一个 proxy，把请求代理给后端的各个数据源，然后把数据源的数据返回给用户。

n9e-edge 部署在边缘机房 B，用于处理 B 机房 VictoriaMetrics 的告警判定，n9e-edge 会从中心 n9e 同步告警规则（即图中的 A 那条线），然后把告警规则缓存在内存里，对本机房的 VictoriaMetrics 做告警判定工作。这样的架构下，n9e-edge 和 VictoriaMetrics 是内网连通的，所以告警比较可靠，另外即便 n9e-edge 连不通中心机房的 n9e 了，也不影响 B 机房的告警判定工作，因为 n9e-edge 内存中已经缓存了告警规则。

n9e-edge 产生的告警事件会调用 n9e 的接口写回中心 mysql，调用钉钉、飞书、FlashDuty 等的接口发送通知。如果 n9e-edge 和 n9e 之间网络断了，告警事件就写不到 mysql 了，但是只要 n9e-edge 所在机房的外网出口是好的，告警通知还是可以发出去的。

架构图中：

中心机房的 n9e 负责中心机房的 Loki、ElasticSearch 的告警判定，也负责机房 A 的 ElasticSearch 和 Prometheus 的告警判定
边缘机房 B 的 n9e-edge 负责机房 B 的 VictoriaMetrics 的告警判定

那如何指定不同的数据源和告警引擎之间的关联关系呢？其实是在数据源的管理页面：

上图中：

URL 是中心 n9e 读取数据的地址，在上例架构中，需要配置为 B 机房 VictoriaMetrics 的公网地址
时序库内网地址是 n9e-edge 连接 VictoriaMetrics 的地址，如果 URL 已经是一个内网地址了，这个配置项就可以留空，留空之后 n9e-edge 就会使用 URL 中的地址。上例中，由于 n9e-edge 和 VictoriaMetrics 在同一个机房，所以这个地址应该配置为内网地址，这样告警判定更可靠
Remote Write URL 是 VictoriaMetrics 的 remote write 写入地址，用于记录规则，即 recording rule，n9e-edge 负责处理记录规则，把结果写回时序库，所以需要知道时序库的 remote write 地址，因为是给 n9e-edge 用的，所以使用内网地址。如果你没有用到夜莺的记录规则，这里可以不用配置
关联告警引擎集群，上图选择的是 edge-b，这是 B 机房 n9e-edge 的名字（由 edge.toml 的 EngineName 字段指定），这样配置之后，就建立了 B 机房 n9e-edge 和 B 机房 VictoriaMetrics 之间的关联关系，就会由这个 n9e-edge 来处理 B 机房 VictoriaMetrics 的告警规则和记录规则

新版本的夜莺，n9e-edge 依赖一个 redis，所以需要在 B 机房部署一个 redis 给 n9e-edge 使用，注意，n9e-edge 所用的 redis 和中心机房 n9e 所用的 redis 不是一个。架构图中我特意标注了 R1、R2 两个名字，表示两个 redis，分别给 n9e 和 n9e-edge 使用。

最后说一下 categraf，如果网络链路比较好，categraf 可以把数据直接上报到中心机房的 n9e，比如中心机房和 A 机房的 categraf 都可以直接对接到中心机房的 n9e，但是 B 机房部署了 n9e-edge，那 B 机房的 categraf 就应该对接到 B 机房的 n9e-edge。

配置样例

要达到上述架构，各个组件的配置文件应该如何配置？这里给出一个示例。

中心机房 n9e 配置

中心机房 n9e 的默认配置文件是 etc/config.toml：

[HTTP.APIForService]
Enable = true
[HTTP.APIForService.BasicAuth]
user001 = "ccc26da7b9aba533cbb263a36c07dcc5"
user002 = "ccc26da7b9aba533cbb263a36c07dcc6"

重点就是 HTTP.APIForService 这块的配置。默认 Enable 是 false 是为了安全考虑，即默认不支持 n9e-edge 架构，如果要支持，需要改成 true。n9e-edge 调用 n9e 的接口时，可以使用 BasicAuth 认证，即 HTTP.APIForService.BasicAuth 下面的部分，上例中配置了两个用户，分别是 user001 和 user002，密码是 ccc26da7b9aba533cbb263a36c07dcc5 和 ccc26da7b9aba533cbb263a36c07dcc6。其实配置一个用户就行，我配置两个只是为了演示。另外，如果你的 n9e 暴露在公网，千万要修改 BasicAuth 的默认密码，不然很容易被攻击。

边缘机房 n9e-edge 配置

边缘机房 n9e-edge 的默认配置文件是 etc/edge/edge.toml，首先 n9e-edge 要调用中心 n9e 的接口，所以要配置中心 n9e 的地址：

[CenterApi]
Addrs = ["http://N9E-CENTER-SERVER:17000"]
BasicAuthUser = "user001"
BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"
# unit: ms
Timeout = 9000

N9E-CENTER-SERVER:17000 表示中心 n9e 的地址，你按照自己的环境调整即可。BasicAuthUser 和 BasicAuthPass 是中心 n9e 的 BasicAuth 用户名和密码，如果中心 n9e 没有开启 BasicAuth，这两个字段可以不填。还是那句话，千万要修改 BasicAuth 的默认密码，不然很容易被攻击。

新版本 n9e-edge 依赖 redis，所以要配置 redis 地址，默认应该是在 edge.toml 的最下面，自行修改即可。如果你是老版本，不依赖 redis，那就不用配置了。如何分辨你的版本的 n9e-edge 是否依赖 redis？就看你下载下来的 edge.toml 默认配置中是否带有 redis 配置，带了就说明依赖 redis。

边缘机房 categraf 配置

主要是注意 2 个地方，writer 的地址和 heartbeat 的地址，都配置为 n9e-edge 的地址：

...
[[writers]]
url = "http://N9E-EDGE:19000/prometheus/v1/write"...
[heartbeat]
enable = true# report os version cpu.util mem.util metadata
url = "http://N9E-EDGE:19000/v1/n9e/heartbeat"
...

N9E-EDGE:19000 表示 n9e-edge 的地址，注意，n9e-edge 默认监听的端口是 19000，也可以在 edge.toml 中自行修改。

ibex 配置

ibex 部分，即故障自愈的功能，这个功能有些公司担心安全问题不开放。如果你们要开启这个功能，同样的道理，在 edge.toml 中开启：

[Ibex]
Enable = true
RPCListen = "0.0.0.0:20090"

然后边缘机房的 categraf 连边缘机房的 n9e-edge 的 20090 端口即可，即 categraf 的 config.toml 要做如下配置：

[ibex]
enable = true
## ibex flush interval
interval = "1000ms"
## n9e ibex server rpc address
servers = ["N9E-EDGE-IP:20090"]
## temp script dir
meta_dir = "./meta"

N9E-EDGE-IP:20090 表示 n9e-edge 的 RPC 地址。注意这是 RPC 地址，不是 HTTP 地址，所以，不要在 N9E-EDGE-IP 前面画蛇添足加上 http:// 啦。

其他适用场景

除了网络链路不好的场景之外，有时为了安全考虑，网络也会有分区，比如某个网络区域只有一台中转机可以连通中心的 n9e，其他机器都不能连通，这时候就可以在中转机上部署 n9e-edge，然后其他机器的 categraf 连中转机的 n9e-edge 即可。

总结

这个边缘机房告警引擎的模式听起来稍微有点复杂，不过对提高监控系统的可用性有很大帮助，多读两遍本文，理解架构了就容易了，希望本文可以帮到你，加油！

前言