架构介绍

中心机房部署架构

20230531103435

首先上图中间的飞鸟代表夜莺的核心进程 n9e （下文以 n9e 代替），它的集群方式非常简单只需部署多节点即可实现。

对于 n9e 来说，它本身依赖的存储有两个

  • Mysql : 存放配置类别信息，如用户，监控大盘，告警规则等
  • Redis : 存放访问令牌(JWT Token)，心跳信息，如机器列表中CPU、内存、时间偏移、核数、操作系统、CPU架构等

从 v6 版本开始，夜莺尝试转型为统一可观测性平台，n9e 不再仅支持接入时序数据源(Prometheus、Victoriametrics、M3DB、Thanos)，也可以接入日志类数据源（Elasticsearch，Loki【预】），链路追踪数据源（Jaeger）。

左侧就是 n9e 的数据来源，n9e 可以支持多种采集器 agent，比如 Datadog-Agent，Telegraf，Grafana-Agent，OpenTSDB agent，Node-Exporter，vmagent 都可以对接，不过最推荐的还是 Categraf。比如在 n9e 中机器列表页面的心跳信息都是 Categraf 才会去采集并上报的，所以为了更丝滑使用更推荐使用 Categraf，并且 Categraf 采用 All-In-One 的设计，采集日志，指标，链路追踪，所有的采集工作使用一个 agent 来解决。

介绍完中心部署架构，我们再来描述一下它的数据流：假设是时序指标数据的采集，agent 把采集到的数据推送给 n9e （端口:17000），然后经由 n9e 加工（自动添加附加标签）转发给对应的时序数据库保存。另外在 n9e 把数据的转发给时序数据库之前，会先从监控数据中提取出 ident 标签写入 mysql 的 target 表（机器列表）中，同时如果 agent 用的是 Categraf 并且配置了心跳(heartbeat=true)，则会把心跳上报的 metadata 存入 Redis（就是那些核数、操作系统、CPU架构等）。

具体在生产环境部署的话，建议在 n9e 前面架设负载均衡，可以是 4 层的，也可以是 7 层的。让 agent 通过负载均衡上报监控数据，上层访问 n9e 也通过负载均衡，这样 n9e 任何一个实例挂掉，不会影响到整个服务可用性，从而做到高可用。而且集群中多个 n9e 实例会均分告警规则，分片处理，从而可以处理更大量的告警规则。

那么在多机房的场景下推荐的架构是怎么样的？简单来说，在边缘机房在和中心机房网络连接比较好的情况下，目标机器只需部署 Categraf，直连中心机房即可（公网一定要注意添加好安全相关配置）。

可是当边缘机房和中心机房网络链路不是很好的情况下，除了目标机器部署 Categraf 外，还推荐把告警引擎（n9e-alert）和时序数据库一起下沉部署。n9e-alert 是 n9e 的一个只保留告警引擎模块的独立可执行程序。

边缘下沉式混杂部署方案

20230724100252

从 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 表，这样就可以在页面上看到机器列表了。就可以使用机器分组，自定义标签，告警自愈之类的功能。