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

架构介绍

中心机房部署架构

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 的地址。

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

开源版
Flashcat
Flashduty