一张图详解开源监控夜莺(Nightingale)的架构

夜莺监控是一款开源云原生观测分析工具,采用 All-in-One 的设计理念,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日,在 github 上发布 v1 版本,已累计迭代 100 多个版本。

夜莺最初由滴滴开发和开源,并于 2022 年 5 月 11 日,捐赠予中国计算机学会开源发展委员会(CCF ODC),为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队,也是 Open-Falcon 项目原核心研发人员,从 2014 年(Open-Falcon 是 2014 年开源)算起来,也有 10 年了,只为把监控这个事情做好。

夜莺架构

一张图详解开源监控夜莺(Nightingale)的架构_第1张图片

整体来看,分三大部分:

  • 中间紫色部分:夜莺的服务端相关模块,是夜莺的核心组件,包括夜莺进程本身,以及依赖的 mysql、redis,图上也画了时序库 VictoriaMetrics 和 Prometheus,这部分其实不是必须的,后面会讲到。
  • 左侧蓝色部分:是各类采集器,我们推荐您使用 categraf,和夜莺的整合最为丝滑,当然,您也可以使用 telegraf、datadog-agent 等其他社区常见采集器。
  • 右侧红色部分:是告警通道,夜莺可以把告警发给钉钉、企微、飞书、Slack 等 IM,也可以发邮件、电话、短信,也可以通过 Webhook 推给第三方,如果您对告警收敛、降噪、排班、认领升级等功能有诉求,可以接入 FlashDuty 事件 OnCall 中心。

下面我们详细解释各个部分的功能。

夜莺服务端

中间灰色部分是夜莺服务端,即 n9e 进程,包含三个功能,分别是:

  • Pushgateway:接收各类采集器推送的指标数据,这个是可选的,待会会讲到。
  • WebUI:夜莺的 Web 界面,提供给用户配置监控、查看监控数据、查看告警等功能。
  • AlertEngine:告警引擎,根据用户配置的告警规则,连到各个时序库数据源,查询数据做异常判断。

Pushgateway

Pushgateway 是 n9e 进程的一部分能力,可以接收各类采集器推送的指标数据,然后转发给时序库。不同的采集器推送的数据格式不同,比如 categraf 是按照 Prometheus remote write 协议推送的,datadog-agent 有自己的格式,telegraf 则比较开放,支持 OpenTSDB、InfluxDB、Prometheus 等格式。Pushgateway 提供多种数据接收接口,接收到数据之后,会把监控指标数据转发给时序库。

以 categraf 为例,categraf 采集了数据推送给夜莺,需要配置服务端的地址,配置样例如下:

[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"
basic_auth_user = ""
...

这里的 127.0.0.1:17000,要改成您的环境的夜莺的地址。这里的 /prometheus/v1/write 就是夜莺提供的一个 API,用于接收 prometheus remote write 协议的数据。夜莺还提供了其他数据接收的 API,具体可以参考这里。

夜莺收到数据后,需要转发给时序库,那夜莺怎么知道要转发给那些地址呢?在夜莺的配置文件 etc/config.toml 中配置:

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

这里的 127.0.0.1:9090 是 prometheus 地址样例,夜莺转发数据给时序库也是走的 prometheus remote write 协议,所以上面的 Url 的 urlpath 是 /api/v1/write,这是 prometheus 的数据接收路径。注意,这个配置文件是 toml 格式,在 toml 中 [[]] 表示数组,这意味着,你可以配置多份 [[Pushgw.Writers]] 区块,即,夜莺可以同时转发数据给多个时序库。

上面讲解的数据流是 categraf 作为采集器,采集了数据推给夜莺,夜莺再转发给时序库,那如果你不用 categraf,比如你使用 prometheus 直接抓取各类 exporter 的数据,数据已经在时序库了,那这个 Pushgateway 其实就没用了,夜莺的配置文件 etc/config.toml 中也不需要配置 Pushgw 相关的信息。

不过,如果不使用 categraf,夜莺的机器列表就会为空,告警自愈功能也没法用了,所以我们推荐您使用 categraf 作为机器常规指标的采集器,在每个机器上部署 categraf,至于各类中间件、数据库的监控数据,倒不强求使用 categraf 采集。

另外,categraf 的配置文件 conf/config.toml 中还有 heartbeat 的配置,配置的是夜莺的 heartbeat 地址,注意修改为您的夜莺地址。heartbeat 会采集机器的一些元信息上报给夜莺,之后您可以在夜莺页面的机器列表中,点击各个机器,看到具体有哪些元信息。

WebUI

夜莺提供了一个 WebUI 页面,用于查看监控数据、管理告警规则、查看生成的告警事件等等,页面有权限控制体系,如果您想把监控能力开放给公司所有团队,让各个团队自助服务,权限体系就比较有用了。

夜莺 v7 版本默认监听的端口是 17000,您在浏览器中使用 http://your_n9e_ip:17000 就可以访问到夜莺的 WebUI 页面,如果您想修改端口,可以修改配置文件 etc/config.toml 中的 HTTP.Port 配置项(在配置文件中搜索 17000 就可以看到具体在哪个位置了)。

AlertEngine

告警引擎是夜莺最核心的能力。通常一个公司会有多个时序库,管理告警规则比较费劲,使用夜莺的话,可以在一个地方维护告警规则,然后生效到不同的时序库。

您要针对某些时序库的数据做告警,首先要在页面配置数据源,目前支持 Prometheus 兼容的各类数据源,比如 Thanos、VictoriaMetrics、M3DB、Prometheus 等,也支持接入 TDEngine、Loki 数据源,对这些数据源的数据做告警判断。

注意,对于某个时序库,即便已经在夜莺的 etc/config.toml 中配置在 [[Pushgw.Writers]] 下面了。也还是需要在夜莺的 WebUI 页面配置数据源,这是因为,夜莺的告警引擎是根据数据源中配置的 URL 来查询数据的。

告警引擎会根据告警规则的配置,拿着规则中的 promql,周期性查询时序库,如果查到了就产生告警事件,查到几条数据就产生几条事件。当然,如果告警规则中配置了持续时长,那就是说,只有连续几次查询都查到了,才会产生告警事件。告警引擎的判定逻辑参考这里:触发告警和恢复的底层逻辑是什么?。

服务端高可用

夜莺依赖 mysql、redis,mysql 和 redis 的高可用社区有很多方案,这里不再赘述。对于 n9e 进程本身的高可用,非常简单,就是找多个机器,每个机器部署一个 n9e 进程即可,集群中的多个 n9e 进程,其配置完全一样。

多个 n9e 前面最好是搞一个负载均衡,用户使用负载均衡的地址来访问夜莺,Categraf 中的夜莺的地址也配置为负载均衡的地址。

边缘模式

如果某公司是多机房,某个机房与其他机房的网络质量很差。比如,夜莺 n9e 进程部署在北京,某个时序库部署在美东,美东和北京的网络不好,此时 n9e 作为告警引擎,周期性查询美东的时序库,就经常会超时,导致告警不准确。怎么办呢?

我们提供了 n9e-edge 模块,用于这类边缘机房的场景。在这里,可以把 n9e-edge 部署在美东,n9e-edge 会从中心 n9e 同步告警规则,缓存在内存中,然后查询美东的时序库做告警判定,即便美东和国内网络断了,美东的 n9e-edge 内存中还缓存了一份告警引擎,可以继续判定告警。

n9e-edge 要连 n9e 进程的 API,所以,我们要在 n9e-edge 的配置文件中给出中心 n9e 的地址,即 CenterApi 相关的配置项,具体可以参考:边缘机房部署夜莺,应对网络割裂的情况。

总结

本文从大面上讲解了开源夜莺的架构,希望对您有帮助,夜莺的 github 地址是:GitHub - ccfos/nightingale: An all-in-one observability solution which aims to combine the advantages of Prometheus and Grafana. It manages alert rules and visualizes metrics, logs, traces in a beautiful web UI. 如果您对此开源项目感兴趣,可以 star 一下留备后用。

你可能感兴趣的:(开源,架构,夜莺监控,Nightingale,开源夜莺)