夜莺-Nightingale
夜莺V6
项目介绍 架构介绍
快速开始
黄埔营
安装部署
升级
采集器
使用手册
API
数据库表结构
FAQ
夜莺专业版
开源生态
Prometheus
版权声明
第1章:天降奇兵
第2章:探索PromQL
第3章:Prometheus告警处理
第4章:Exporter详解
第5章:数据与可视化
第6章:集群与高可用
第7章:Prometheus服务发现
第8章:监控Kubernetes
第9章:Prometheus Operator
参考资料

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

在这个架构模式下,中心端部署 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 的方法如下:

./n9e-edge -configs etc/edge

当然,生产环境需要使用 nohup 或者 systemd 启动。etc/edge/edge.toml 中的关键配置是 [CenterApi],如下:

[CenterApi]
Addrs = ["http://127.0.0.1:17000"]
BasicAuthUser = "user001"
BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"
# unit: ms
Timeout = 9000

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

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

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

但是,如果 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] 部分,如下:

[Alert.Heartbeat]
# auto detect if blank
IP = ""
# unit ms
Interval = 1000
EngineName = "region-b"

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

页面上添加数据源的时候,会选择数据源要关联的告警引擎,这个告警引擎就是 n9e-edge 的名字(EngineName)。上面架构的实践方式:如果添加的是中心机房或机房 A 的数据源,就选择中心机房的告警引擎(即 default);如果添加的是机房 B 的数据源,就选择机房 B 的告警引擎(即 region-b)。

开源版
Flashcat
Flashduty