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

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

如果各个机房的网络链路很好,就直接让各个机器上的 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 的地址。

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

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

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

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

开源版
Flashcat
Flashduty