Prometheus 监控平台组件深度讲解

Prometheus 的重要性和流行度已经无需多言。直入主题,本文对 Prometheus 监控平台的各个组件做深度讲解,希望能帮助读者更好地理解 Prometheus。

监控系统的核心逻辑

对于一套监控系统而言,核心就是采集数据并存储,然后做告警判定、数据展示分析,这个 专栏文章 详细讲解了这个数据流架构,整个流程图如下:

Prometheus 有多个组件(或者说多个进程),协同工作。下面我们逐个组件做一概述:

  • https://github.com/prometheus/prometheus:这是 prometheus 进程的代码仓库,功能包括抓取远端监控指标、存储时序数据、暴露查询接口支持数据查询、支持告警规则配置并做告警判定
  • https://github.com/prometheus/alertmanager:这是 alertmanager 进程的代码仓库,功能包括接收 prometheus 产生的告警事件,对事件做去重、分组、路由、通知等操作

我把监控系统的流程图给变换一下颜色:

  • prometheus 进程承接了图中蓝色功能,即:采集器、时序库、告警判定引擎
  • alertmanager 进程负责告警事件分发,即图中红色部分
  • 数据展示分析,橙色部分,Prometheus 做的比较少,Prometheus 确实有一个简单的 Web UI,不过比较简陋,一般使用更为强大的 Grafana 来做数据展示分析

大家可能还听过各类 Exporter,难道这些 Exporter 就没有一席之地了么?Exporter 也是很重要的,可以看做是一个适配器,把监控目标的指标暴露出来,让 Prometheus 来抓取。或者把 Exporter 看做是采集器的一部分也行,无伤大雅,理解整个数据流就可以,无需在词汇上纠结。

想象一下,假设你有一个 Application,一个 Go 程序或者 Java Spring Boot 程序,Application 把自身的运行状态指标通过 /metrics 接口暴露出来,Prometheus 直接抓取即可,这里不需要什么 Exporter。但是一些成熟的数据库、中间件,比如 MySQL,Redis,这些软件没有直接暴露 Prometheus 格式的指标,Prometheus 没法直接来抓取,怎么办呢?当然,可以完善 Prometheus 的抓取器,让他不仅可以抓取 HTTP 协议的 /metrics 数据,也可以抓取 MySQL、Redis 等的数据,但是这样的话,Prometheus 代码会变得臃肿,不利于维护。所以,Prometheus 采用了 Exporter 的设计,Exporter 就是一个适配器,使用 Exporter 去抓取这些监控目标的指标,然后暴露为 Prometheus 格式的指标,Prometheus 再去抓取这些 Exporter 暴露的指标。这样做的好处是,Prometheus 代码保持简洁,Exporter 代码可以独立维护,提升整体可维护性。而且 Exporter 可以发动全网力量,让大家共建,一举多得。

但是,Exporter 会有很多不同的进程,水平参差不齐,从部署的角度可能略麻烦,所以市面上也有一些开源项目,把众多 Exporter 整合在一起变成一个进程,比如 Grafana-agent、Cprobe,当然,还有大名鼎鼎的 OpenTelemetry 也是这个思路。

了解了上述知识,我们再来看 Prometheus 官网的架构图。

Prometheus 架构

  • Prometheus Server:是 prometheus 进程的一部分功能,负责数据的抓取、存储、HTTP 接口查询
    • Retrieval:数据抓取,从监控目标那里拉取监控指标,Prometheus 定义了一个标准协议,只要监控目标支持这个协议,Prometheus 就可以抓取
    • TSDB:时序库,Prometheus 会把抓取到的监控指标存储在本地,单点的。如果想要高可用,可以使用 Thanos、VictoriaMetrics 等
    • HTTP server:Prometheus 会暴露 HTTP 接口,供外部查询监控指标
  • Service Discovery:服务发现,是 prometheus 进程的一部分功能,Prometheus 会定期去服务发现组件那里拉取监控目标的列表,省去了手动配置的繁琐,当然,前提是这些监控目标得注册到服务发现组件上
    • Kubernetes SD:基于 Kubernetes 的服务发现机制,比如通过 apiserver 拉取 pod 列表、service 列表作为监控目标
    • File SD:基于文件的服务发现机制,从配置文件中读取监控目标列表
    • HTTP SD:基于 HTTP 的服务发现机制,从 HTTP 接口中读取监控目标列表
    • Consul SD:基于 Consul 的服务发现机制,从 Consul 中读取监控目标列表
    • 等等
  • Pushgateway:是一个单独的进程,用于接收短生命周期的监控指标,比如批处理任务的监控指标,因为批处理任务通常不会暴露 HTTP 接口,Prometheus 就没法拉取了,所以批处理任务需要主动推送监控指标到 Pushgateway,Prometheus 再去拉取 Pushgateway 的监控指标
  • Alertmanager:负责接收 prometheus 产生的告警事件,对事件做去重、分组、路由、通知等操作。如果想要更高阶的收敛、降噪、排班、认领、升级等功能,可以把 Alertmanager 和一些第三方工具结合使用,比如 PagerDuty、FlashDuty、OpsGenie 等
  • Prometheus web UI:prometheus 进程启动之后,会暴露一个简单的 Web UI,可以查看监控指标,但是功能比较简陋,一般使用 Grafana 来做数据展示分析
  • Grafana:是一个独立的进程,不属于 Prometheus 项目的一部分,不过可以和 Prometheus 整合。用于数据展示分析,功能非常强大,支持多种数据源,比如 Prometheus、Elasticsearch、Loki 等,支持多种图表类型,比如折线图、柱状图、饼图、热力图等

Prometheus 架构的问题

主要问题的容量扩展问题。Prometheus 一个进程干了很多事情,部署非常简单,弊端就是单点没法扩展,比如告警引擎是单点、存储是单点、采集是单点,如果体量很大或者对稳定性要求比较高,就需要通过其他手段来解决了。

比如 VictoriaMetrics 项目,就是完全兼容 Prometheus 生态的协议和接口,但是提供了分布式能力。存储使用 vmstorage 进程,查询使用 vmselect 进程,数据接收使用 vminsert,告警使用 vmalert,数据抓取使用 vmagent,组件确实多了,但是每个组件都可以部署多个实例组成集群,提升了整体的可用性和容量。VictoriaMetrics 项目的架构图如下:

或者还有一个办法,就是直接部署多套 Prometheus,比如 DBA 自己用一个 Prometheus,Hadoop 团队自己用一个 Prometheus,这样可以解决容量问题,没法解决数据单点存储问题。如何解决单点问题?双写!比如 DBA 团队,部署两个 Prometheus,采集相同的数据,两个 Prometheus 数据相同,规则相同,告警也会产生两份,可以通过 Alertmanager 做告警去重,这样就解决了单点问题。

Prometheus 规则管理问题

最后一个问题,简单聊聊 Prometheus 的规则管理问题。Prometheus 的规则是通过配置文件定义的,这个配置文件是一个 yaml 文件,里面定义了监控规则、告警规则等。如果一个公司有很多套 Prometheus,规则分散在多个 yaml 中不方便管理,希望能有一套易用的、权限隔离的 UI,把监控能力开放给全公司各个团队并让他们自服务,别啥事都来找监控团队,这个时候就需要一个规则管理系统,比如夜莺(Nightingale)。如果有这方面的痛点可以去了解一下,如果 Prometheus 自身的玩法就感觉够用了,那更好,不用再引入新的组件。

小结

文本详细介绍了 Prometheus 监控平台的各个组件,希望能帮助读者更好地理解 Prometheus。使用任何一个开源项目,都要了解其原理,这样才能了解其最佳实践,出了问题也能有排查思路。切莫只是解决一些表面问题,得过且过,这样是不会有长进的,35岁之后,容易被干。

热门相关:定制孔   约泡之疯狂夜生活   方言 未删版   私人岛屿   越战先锋越战尖兵