夜莺v6.0中心机房部署架构

rabbit

中心机房部署架构

[color=var(--docs-v2-text)]

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

[color=var(--docs-v2-text)]对于 n9e 来说，它本身依赖的存储有两个

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

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

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

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

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

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

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

边缘下沉式混杂部署方案

[color=var(--docs-v2-text)]

[color=var(--docs-v2-text)]从 v6.0.0.ga.9 开始，合并了 n9e-alert、n9e-pushgw 模块为 n9e-edge，应对边缘机房的场景。n9e-edge 不依赖 [color=var(--docs-v2-accent-strong)]mysql、[color=var(--docs-v2-accent-strong)]redis，只依赖中心端的 n9e，所以 edge.toml 配置文件里，需要配置中心端 n9e 的地址。

复制[color=inherit !important][CenterApi][color=inherit !important]Addrs = ["http://127.0.0.1:17000"][color=inherit !important]BasicAuthUser = "user001"[color=inherit !important]BasicAuthPass = "ccc26da7b9aba533cbb263a36c07dcc5"[color=inherit !important]# unit: ms[color=inherit !important]Timeout = 9000

[color=var(--docs-v2-text)]认证信息（BasicAuthUser、BasicAuthPass）对应中心端 n9e 的 [color=var(--docs-v2-accent-strong)]HTTP.APIForService.BasicAuth 配置段。

[color=var(--docs-v2-text)]可以通过如下命令启动 n9e-edge：

复制[color=inherit !important]nohup ./n9e-edge --configs etc/edge &> edge.log &

[color=var(--docs-v2-text)]如果机房之间网络链路很好，就让所有的 categraf 和中心端的 n9e 通信即可，如果某个机房和中心端网络链路不好，就让 categraf 和 n9e-edge 通信，n9e-edge 和中心端的 n9e 通信。

[color=var(--docs-v2-text)]边缘机房的 n9e-edge 默认的引擎名字是 edge，与中心端 n9e 的引擎名字（default）相区分。注意：边缘机房的时序库在夜莺里添加数据源的时候，要选择边缘机房的告警引擎（edge）。如果你有两个边缘机房，注意两个边缘机房的 n9e-edge 的引擎名字要不一样。下图是配置数据源的时候，选择告警引擎的地方：

[color=var(--docs-v2-text)]

[color=var(--docs-v2-text)]图中 region02 的机房中采集器使用的是 vmagent，并把采集的数据直接写入时序数据库，通过 n9e-edge 对监控数据做告警判断。这种架构比较简洁，但是会有一点点小问题，由于采集数据没有流经 n9e-edge，就没法从数据流中解析出机器信息，也就没法把机器信息写入数据库 target 表，也就导致页面上机器列表页面看不到相关的机器。这不影响告警，看图这些核心功能，只是用不了机器分组，自定义标签，告警自愈之类的功能。

[color=var(--docs-v2-text)]更推荐使用 Categraf + n9e-edge 的方式来采集数据，其架构如图 region01 所示。当 Categraf 采集的数据上报给 n9e-edge 后，n9e-edge 就可以从监控数据中解析出机器信息，然后通过中心端的 n9e 写入数据库 target 表，这样就可以在页面上看到机器列表了。就可以使用机器分组，自定义标签，告警自愈之类的功能。