夜莺V6.X架构介绍

秦晓辉@快猫星云 2023-03-27 05:06:10

夜莺 6.x 版本相比 5.x 在架构上做了巨大的调整,之前服务端有两个模块,n9e-webapi 和 n9e-server,6.x 之后合并成了一个,就是 n9e,这个模块既可以提供接口给前端调用,也可以提供告警引擎的能力。但是有的时候机房网络链路不好,或者有acl限制,很多 agent 没法连通服务端,此时就需要下沉部署方案。

中心汇聚式部署方案

这个方案的架构图如下:

中心汇聚式部署方案

夜莺只有一个模块了,就是 n9e,可以部署多个 n9e 实例组成集群,n9e 依赖 2 个存储,数据库、Redis,数据库可以使用 MySQL 或 Postgres,自己按需选用。

n9e 提供的是 HTTP 接口,前面负载均衡可以是 4 层的,也可以是 7 层的。一般就选用 Nginx 就可以了。

n9e 这个模块接收到数据之后,需要转发给后端的时序库,相关配置是:

[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]] 
Url = "http://127.0.0.1:9090/api/v1/write"

相当于是,虽然数据源可以在页面配置了,但是上报转发链路,还是需要在配置文件指定。

所有机房的 agent( 比如 Categraf、Telegraf、 Grafana-agent、Datadog-agent ),都直接推数据给 n9e,这个架构最为简单,维护成本最低。当然,前提是要求机房之间网络链路比较好,一般有专线。如果网络链路不好,则要使用下面的部署方式了。

边缘下沉式混杂部署方案

还是先上架构图,一图胜千言:

边缘下沉式混杂部署方案

这个图尝试解释 3 种不同的情形,比如 A 机房和中心网络链路很好,Categraf 可以直接汇报数据给中心 n9e 模块,另一个机房网络链路不好,就需要把时序库下沉部署,时序库下沉了,对应的告警引擎和转发网关也都要跟随下沉,这样数据不会跨机房传输,比较稳定。但是心跳还是需要往中心心跳,要不然在对象列表里看不到机器的 CPU、内存使用率。还有的时候,可能是接入的一个已有的 Prometheus,数据采集没有走 Categraf,那此时只需要把 Prometheus 作为数据源接入夜莺即可,可以在夜莺里看图、配告警规则,但是就是在对象列表里看不到,也不能使用告警自愈的功能,问题也不大,核心功能都不受影响。

边缘机房,下沉部署时序库、告警引擎、转发网关的时候,要注意,告警引擎需要依赖数据库,因为要同步告警规则,转发网关也要依赖数据库,因为要注册对象到数据库里去,需要打通相关网络,告警引擎和转发网关都不用Redis,所以无需为Redis打通网络。

小结

夜莺 v6.x 发布了 ga 版本,就是基本可用的版本,正式版还需要再稳定一段时间,预计 4.27 与大家见面,敬请期待。

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat
FlashDuty
Flashduty