夜莺监控是一款开源云原生观测分析工具,采用 All-in-One 的设计理念,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日,在 github 上发布 v1 版本,已累计迭代 100 多个版本。
夜莺最初由滴滴开发和开源,并于 2022 年 5 月 11 日,捐赠予中国计算机学会开源发展委员会(CCF ODC),为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队,也是 Open-Falcon 项目原核心研发人员,从 2014 年(Open-Falcon 是 2014 年开源)算起来,也有 10 年了,只为把监控这个事情做好。
整体来看,分三大部分:
下面我们详细解释各个部分的功能。
中间灰色部分是夜莺服务端,即 n9e 进程,包含三个功能,分别是:
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 页面,用于查看监控数据、管理告警规则、查看生成的告警事件等等,页面有权限控制体系,如果您想把监控能力开放给公司所有团队,让各个团队自助服务,权限体系就比较有用了。
夜莺 v7 版本默认监听的端口是 17000,您在浏览器中使用 http://your_n9e_ip:17000
就可以访问到夜莺的 WebUI 页面,如果您想修改端口,可以修改配置文件 etc/config.toml
中的 HTTP.Port
配置项(在配置文件中搜索 17000 就可以看到具体在哪个位置了)。
告警引擎是夜莺最核心的能力。通常一个公司会有多个时序库,管理告警规则比较费劲,使用夜莺的话,可以在一个地方维护告警规则,然后生效到不同的时序库。
您要针对某些时序库的数据做告警,首先要在页面配置数据源,目前支持 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 一下留备后用。