夜莺-Nightingale
夜莺V7
项目介绍 功能概览
部署升级 部署升级
数据接入 数据接入
告警管理 告警管理
数据查看 数据查看
功能介绍 功能介绍
API FAQ
夜莺V6
项目介绍 架构介绍
快速开始 快速开始
黄埔营
安装部署 安装部署
升级
采集器 采集器
使用手册 使用手册
API API
数据库表结构 数据库表结构
FAQ FAQ
开源生态
Prometheus
版权声明
第1章:天降奇兵 第1章:天降奇兵
第2章:探索PromQL 第2章:探索PromQL
第3章:Prometheus告警处理 第3章:Prometheus告警处理
第4章:Exporter详解 第4章:Exporter详解
第5章:数据与可视化 第5章:数据与可视化
第6章:集群与高可用 第6章:集群与高可用
第7章:Prometheus服务发现 第7章:Prometheus服务发现
第8章:监控Kubernetes 第8章:监控Kubernetes
第9章:Prometheus Operator 第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 表,这样就可以在页面上看到机器列表了。就可以使用机器分组,自定义标签,告警自愈之类的功能。

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