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

监控系统的核心逻辑

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

Prometheus 有多个组件（或者说多个进程），协同工作。下面我们逐个组件做一概述：

• GitHub - prometheus/prometheus: The Prometheus monitoring system and time series database.：这是 prometheus 进程的代码仓库，功能包括抓取远端监控指标、存储时序数据、暴露查询接口支持数据查询、支持告警规则配置并做告警判定
• GitHub - prometheus/alertmanager: 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岁之后，容易被干。