Prometheus 深度指南：设计理念 · PromQL · Exporter · Thanos

Prometheus 简介

Prometheus（普罗米修斯）是一个开源的系统监控和报警工具套件，最初由 SoundCloud 在 2012 年创建。凭借活跃的开发者和用户社区，Prometheus 已被众多公司和组织采用，并于 2016 年加入云原生计算基金会（CNCF），成为继 Kubernetes 之后的第二个托管项目。Prometheus 专注于指标式监控（metrics），将监控数据保存为时间序列：即度量指标在不同时间点的取值序列，每条时间序列由指标名称和一组标签（key=value 对）标识。这种多维度的数据模型使用户可以根据丰富的标签组合对数据进行过滤和聚合查询。

作为一款为云原生时代设计的监控系统，Prometheus 常用于监控主机资源、容器和微服务等场景。它尤其适用于高度动态的分布式环境（例如 Kubernetes 编排的微服务架构），因为它对多维数据的采集和查询提供了强大的支持。Prometheus 内置了时序数据库（TSDB）用于高效存储时序数据，并提供自带的查询语言和可视化界面。此外，Prometheus 通常与 Grafana 等可视化工具配合使用，以构建丰富的监控仪表盘，实现对系统实时状态的直观展示。

值得注意的是，Prometheus 更加注重监控数据的及时性和系统的可靠性，而非数据的一致性。在设计上，每个 Prometheus 服务实例都是独立运行的，不依赖分布式存储或其他远程服务。这种架构确保了即使在基础设施出现故障时，Prometheus 服务器本身仍可用，从而在故障期间帮助工程师及时诊断问题。当然，由于采集的是近实时指标数据，并非事务性精确数据，Prometheus 并不适合需要100%精确度的场景（例如精确计费），因为在故障或重启时指标可能存在中断或丢失。

Prometheus 设计理念

Prometheus 的设计围绕简洁、高效和可靠展开，体现为以下几个核心理念：

拉取模型（Pull Model）

Prometheus 采用拉取（pull）模型从监控目标采集数据，即由 Prometheus 服务器主动定期通过 HTTP 协议去抓取（scrape）各监控目标导出的指标。每个被监控的服务只需暴露一个HTTP接口（通常为/metrics），提供当前指标的文本格式数据，Prometheus 就会在配置的抓取间隔（默认15秒）主动来拉取数据。这种模式使监控中心对采集频率和节奏有控制权，避免了过多的数据推送风暴。同时，配合服务发现机制，Prometheus 可以自动发现动态环境中的目标（如容器的新增或迁移）。

说明：对于无法由中心主动拉取的短生命周期任务（如批处理作业），Prometheus 提供了 Pushgateway 组件作为中间缓冲，允许这些任务将指标推送到 Gateway，由 Prometheus 再去拉取。但总体而言，Prometheus 默认以 pull 模式工作，以保持架构的简单可靠。

本地时序数据库（TSDB）

Prometheus 内置了高效的本地时序数据库，用于存储采集到的指标时间序列数据。每个 Prometheus 实例将抓取的数据样本首先缓存在内存中，并周期性地批量写入磁盘上的存储文件。Prometheus 2.x 引入了名为 TSDB 的存储引擎，其将数据按时间分块（默认2小时一个块）存储，并对旧数据压缩存档，从而在保证查询性能的同时有效控制存储空间占用。默认配置下，Prometheus 会保留最近 15 天的监控数据（可通过启动参数调整）。

Prometheus 强调本地存储、单机自治的原则，每台服务器在本地保存完整数据并独立提供服务。这种设计避免了对分布式存储的依赖，降低了系统复杂度和故障耦合。如果需要长期保存历史数据或集群级别的高可用，通常会借助远程存储集成或者上文将提到的 Thanos 等方案，而非让 Prometheus 自身承担分布式存储的职责。

指标类型（Counter、Gauge、Histogram、Summary）

Prometheus 客户端库定义了四种类型的指标，用于不同的度量场景：

• Counter（计数器）：单调递增的计数器，只能增加或在重启时重置为0。适用于累积计数场景，如请求总次数、错误发生次数等。计数器的值随时间不断累加，例如HTTP请求总数http_requests_total就是典型的Counter。通过对Counter求速率，可以得到事件发生的频率。
• Gauge（仪表）：可增可减的仪表值。Gauge用于表示瞬时状态值，如当前温度、内存使用量、CPU利用率等，其值可上升也可下降。Gauge直接表示系统的当前状态数值。
• Histogram（直方图）：将数据样本按大小分布到预定义的桶（bucket）中，并记录每个桶的计数累积值以及总和。常用于统计请求延迟或响应大小等分布情况。Histogram在Prometheus中会产生一组相关的时间序列（例如带有_bucket、_count、_sum后缀的指标），可结合特殊函数计算出所需的分位值。
• Summary（摘要）：类似于Histogram，也用于统计数据的分布，不过是由客户端直接预计算特定分位数并上报。Summary 会维护分位数值以及总和、数量。它适用于单个实例内部统计延迟等，但由于分位数是在客户端计算的，无法像Histogram那样方便地在服务端聚合计算全局分位指标。

举例来说，如果要监控HTTP请求的延迟分布，既可以使用Histogram类型指标（记录各延迟区间的计数），事后通过查询计算99百分位响应时间；也可以使用Summary类型直接在客户端统计并上报99线延迟。但是使用Summary时无法将多个实例的结果合并出全局的99线，而Histogram可以在Prometheus聚合各实例的数据后再计算分位数。这是Histogram与Summary的重要区别之一。

四个黄金指标（Four Golden Signals）

Google SRE 手册中提出了监控系统的四个黄金指标，即延迟、流量、错误和饱和度。这四项是衡量分布式服务健康状况的关键维度，Prometheus 非常适合采集和观察这四类指标：

• 延迟（Latency）：处理请求所需的时间，即服务响应的延迟。高延迟通常意味着性能瓶颈或资源不足。例子：HTTP 请求的平均响应时间、99%分位响应时间等。
• 流量（Traffic）：系统的吞吐量或负载，如请求率或每秒查询数QPS。流量反映了用户对服务的需求，监控流量可以帮助发现异常流量峰值或趋势。
• 错误率（Errors）：请求失败的比例或数量。高错误率表示系统出现故障或错误。如每秒发生的HTTP 5xx错误数或错误百分比。
• 饱和度（Saturation）：资源饱和程度，即系统关键资源的利用率。当资源（CPU、内存、磁盘IO等）接近饱和时，系统性能可能下降甚至崩溃。监控饱和度可帮助预先发现容量问题。

以上四个指标覆盖了系统性能和可靠性的主要方面：延迟体现用户体验，流量体现负载水平，错误率体现可靠性，饱和度体现资源极限。通过在监控中重点关注这“四黄金”，运维团队可以更全面地了解系统健康状况。Prometheus 能方便地采集这些数据（例如通过应用埋点上报延迟、计数请求总量和错误总量、采集主机资源利用率等），结合其强大的查询语言和告警功能，可以对四项黄金指标设定告警阈值，及时发现异常并定位瓶颈。

PromQL 查询语言

Prometheus 提供了功能强大的专用查询语言 PromQL（Prometheus Query Language），用于检索和聚合存储的时间序列数据。PromQL 语法允许按照指标名称和标签筛选时间序列，并对数据执行计算、聚合和函数变换，以提取有意义的信息。下面介绍 PromQL 的基本用法和常用函数示例：

基本查询语法

PromQL 最基本的查询由指标名称和可选的标签过滤组成，形式如：

<指标名称>{标签1="值1", 标签2!="值2", ...}

        

          
        
        
        

          

          AI 代码解读
        
      
      

例如，查询某 API 服务5分钟内每秒请求率最高的HTTP路径，可以使用：

topk(5, rate(http_requests_total{job="api", status=~"5.."}[5m]))

        

          
        
        
        

          

          AI 代码解读
        
      
      

上述查询含义：筛选指标http_requests_total中job标签为"api"且状态码为5xx的时间序列，计算它们过去5分钟的每秒请求增长率（使用rate函数），然后取前5高的系列。PromQL 支持多种比较运算符和正则用于标签匹配，例如=,!=,=~（正则匹配）等，以灵活筛选目标数据。

常用聚合操作

PromQL 提供了丰富的聚合算子，如 sum（求和）、avg（均值）、max（最大值）、min（最小值）、count（计数）等。这些聚合可以按标签维度进行分组或去除标签。例如：

• sum(rate(http_requests_total[1m])) ：计算所有请求每秒总和（不区分来源）。
• sum by (service)(rate(http_requests_total[5m]))：按service标签分组，计算各服务每秒请求率。
• max by (instance)(node_cpu_usage)：比较各实例的CPU使用率，找出每个实例上的最大CPU使用率。

通过组合聚合算子和标签维度，用户可以方便地从大批指标中按服务、按实例、按数据中心等不同维度提炼汇总结果。

内置函数示例

PromQL 内置了几十种函数，用于时间序列的数学计算和分析。以下介绍几种常用函数及其使用场景：

• rate()：计算计数器在指定时间区间内的平均增长速率（每秒增量）。只适用于 Counter 类型指标。典型用法如：

  rate(http_requests_total[5m])
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  上述表达式表示计算过去 5 分钟内 http_requests_total 每秒平均增加量。这常用于获取 QPS、TPS 等指标。例如结合聚合：sum by (status) (rate(http_requests_total[1m])) 可以按HTTP状态码分类计算每秒请求数。
• irate()：计算计数器在区间内瞬时增长速率，即基于最后两个样本点近似计算当前每秒增速。例如 irate(http_requests_total[5m]) 更侧重瞬时值，适合捕捉短时峰值变化。一般来说，rate()输出更平滑，适合观察平均趋势，而irate()反映最新速率，适合告警检测突增。
• increase()：计算计数器在指定时间区间内的增量总和。这实质上等价于 rate()*时间秒数 的结果。例如：

  increase(http_requests_total{job="api-server"}[5m])
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  返回该 API 服务过去5分钟内处理的请求总次数。increase()对人来说易读，可直接用于显示“在某时段内发生了多少次事件”。
• histogram_quantile(φ, b)：计算直方图数据的 φ 分位数。该函数通常与直方图指标的 _bucket 度量配合使用。例如，对于名为http_request_duration_seconds的直方图（其桶指标为http_request_duration_seconds_bucket），计算 90% 分位响应时间的查询为：

  histogram_quantile(0.9, rate(http_request_duration_seconds_bucket[10m]))
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  以上表达式会基于过去10分钟的直方图桶频率计算出请求延迟的90th百分位值。通常会按服务或接口分组使用，如：

  histogram_quantile(0.9, sum by(service, le) (rate(http_request_duration_seconds_bucket[10m])))
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  这将针对每个服务计算90线延迟。需要注意，对于直方图应尽量使用rate()等函数先求增量再算分位，这样得到的是基于速率的近似分位值，更符合实际。

除上述函数外，PromQL 还有许多实用函数，例如：avg_over_time() 计算区间平均值、max_over_time()计算区间最大值、abs()取绝对值、ceil()/floor()取整等，不一一列举。掌握 PromQL 能够灵活组合指标、函数和聚合算子，可以从海量监控数据中提炼有意义的信息，用于问题诊断和性能分析。

PromQL 查询示例

以下通过几个实际示例，演示 PromQL 在监控查询中的应用：

• CPU 使用率告警：获取每个实例最近5分钟的CPU平均使用率，并筛选出超过80%的实例：

  avg by(instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 > 80
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  这里 node_cpu_seconds_total{mode!="idle"} 是Node Exporter提供的每秒CPU使用时间计数，过滤掉空闲时间后求和并计算5分钟平均占用率，再乘100转化为百分比。当表达式结果为 true 时表示某实例 CPU 利用率高于80%。
• 内存泄漏检测：检查应用进程内存使用的时间趋势，如在30分钟窗口内持续增加：

  increase(process_resident_memory_bytes[30m]) > 0
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  process_resident_memory_bytes 是应用当前内存占用。用increase计算半小时内增量，若一直增长则结果为正，可能暗示内存泄漏风险。可进一步结合offset函数比较不同时间段数值做趋势分析。
• 99线延迟监控：对于使用Histogram的服务请求延迟指标，监控其99th分位是否异常升高：

  histogram_quantile(0.99, sum by(le) (rate(api_request_duration_seconds_bucket{service="pay"}[5m])))
  
          
  
            
          
          
          
  
            
  
            AI 代码解读
          
        
        

  该查询计算service="pay"服务过去5分钟内请求延迟99线值。如果这一值持续升高接近超出SLO阈值，就需要引起关注。结合for语句可设定告警在高延迟保持一段时间后触发。

以上示例只是冰山一角，PromQL 还支持子查询、语义化的排序函数（如topk/bottomk）、集合运算符等高级用法，能够满足复杂的监控分析需求。在掌握PromQL之后，运维和开发人员几乎可以对监控数据“随心所欲”地提问，例如比较不同版本部署的性能、统计某错误率占比、计算资源利用率的95线等等，为系统优化提供依据。

Exporter 机制

在 Prometheus 体系中，Exporter 指的是向 Prometheus 提供监控指标数据的服务组件。广义上说，任何能够按照 Prometheus 暴露格式提供指标数据的程序都可以称为一个 Exporter，每个 Exporter 实例对应 Prometheus 配置中的一个采集目标（target）。Exporter 的来源主要有两种：一是官方或社区提供的现成 Exporter，开箱即用；二是用户根据特定需求自定义开发的 Exporter。

典型的社区 Exporter 如：Node Exporter（采集操作系统主机指标）、MySQL Exporter（采集 MySQL 数据库内部统计）、Blackbox Exporter（通过探针检测外部服务可用性）等。这些 Exporter 通常作为独立进程运行，定期收集所在系统或服务的状态，并在HTTP接口提供符合 Prometheus 文本格式的 /metrics 输出。Prometheus 服务通过配置静态目标或服务发现找到 Exporter 的地址，定期抓取其指标，实现对相应系统的监控。

对于一些特殊的软件或自定义应用，可能官方并没有合适的 Exporter。这时我们可以使用 Prometheus 提供的各语言客户端库，将应用程序包装成自定义 Exporter。例如使用 Python 客户端库，我们可以很容易地编写一个 Exporter 来暴露程序内部的运行指标。下面是一个用 Python 编写简单 Exporter 的示例：

from prometheus_client import Gauge, start_http_server
import time, psutil

# 定义一个Gauge类型的指标，监控系统CPU利用率(%)
cpu_usage = Gauge('system_cpu_usage_percent', 'System CPU usage in percent')

if __name__ == '__main__':
    start_http_server(8000)         # 在本地启动一个HTTP服务，端口8000
    while True:
        cpu_usage.set(psutil.cpu_percent())  # 设置当前CPU利用率
        time.sleep(5)                        # 每5秒更新一次

        

          
        
        
        

          

          AI 代码解读
        
      
      

上述代码借助 prometheus_client 库定义了一个名为system_cpu_usage_percent的 Gauge 指标，并启动一个HTTP服务器来暴露指标数据。其中 psutil.cpu_percent() 用于获取系统CPU利用率，并赋值给 Gauge。运行脚本后，Prometheus 就可以通过抓取 http://<Exporter主机>:8000/（默认路径即/metrics）获取到如下格式的数据：

# HELP system_cpu_usage_percent System CPU usage in percent
# TYPE system_cpu_usage_percent gauge
system_cpu_usage_percent 12.5

        

          
        
        
        

          

          AI 代码解读
        
      
      

这表示当前CPU利用率为12.5%。我们需要在 Prometheus 的配置文件中添加该 Exporter 作为抓取目标，例如：

scrape_configs:
- job_name: "custom-exporter"
  static_configs:
    - targets: ["localhost:8000"]

        

          
        
        
        

          

          AI 代码解读
        
      
      

重新加载 Prometheus 配置后，就开始定期从这个 Exporter 拉取数据。我们可以在 Prometheus 的查询界面或 Grafana 中使用 system_cpu_usage_percent 指标名来查看其随时间的变化。

采集流程解析：自定义 Exporter 的开发和集成流程一般如下——首先在应用中埋点或收集所需监控的数据，然后使用 Prometheus 客户端库定义指标，将数据赋值给指标对象。接着启动一个HTTP服务监听指定端口并暴露指标（客户端库通常提供便捷的方法，如上述 start_http_server）。最后在 Prometheus 中配置该 Exporter 服务地址为抓取目标。这样 Prometheus 会按照设定频率主动来拉取 /metrics，将获取的样本存入本地时序库。整个过程数据流向是应用/系统 -> Exporter -> Prometheus。由于 Exporter 通常设计得较为轻量，且使用Pull模式，不会对被监控系统产生明显影响。当需要监控新的指标时，只需在 Exporter 中增加相应的度量，无需修改 Prometheus 主程序。

通过 Exporter 机制，Prometheus 实现了与被监控系统的松耦合。几乎所有常见的软件（数据库、中间件、硬件设备等）都有社区维护的 Exporter，可供直接部署使用。而自定义 Exporter 则为特殊场景下的数据采集提供了灵活性，使 Prometheus 的监控范围可以覆盖到任何有数据接口的地方。

高可用解决方案：Thanos

单个 Prometheus 服务在可靠性和性能上有一些天然限制：例如本地存储容量有限（默认仅保留15天数据）、单机处理能力有上限且缺乏跨实例的数据同步。当监控规模扩大到集群多副本或需要长期保存数据时，就需要在 Prometheus 之上引入额外的方案。Thanos 正是一款用于扩展 Prometheus 实现高可用、全局视图和长时存储的开源系统。它通过松散耦合的架构，将多个 Prometheus 实例连接起来，提供统一查询接口和历史数据存储功能，被形象地称为让多个 Prometheus 汇聚在一起的“灭霸”（Thanos）。

Thanos 本质上由一组协同工作的组件构成，每个组件以独立进程形式运行。部署 Thanos 后，即使有多台 Prometheus 实例（例如分别部署在不同数据中心或作为冗余），用户也可以通过一个查询入口获取全局的监控视图，并保障在单点故障或重启时指标数据不丢失。下面介绍 Thanos 的主要组件及其作用：

• Sidecar（边车）：以“边车”模式伴随每个 Prometheus 实例部署。Sidecar 连接到本地 Prometheus，拦截其数据用于两方面用途：(1) 实现 Thanos 的 Store API，相当于一个代理，使得 Thanos 的查询模块可以通过 Sidecar 从本地 Prometheus 实时读取最新数据；(2) 将 Prometheus 本地的时间序列数据块定期上传到远程对象存储（如 S3、GCS 等）。借助 Sidecar，Prometheus 实例对外提供统一的数据接口，并且能够将历史数据备份到集中存储，实现长期保存。需要注意，数据块通常每2小时才上传一次，因此 Prometheus 重启可能导致最近2小时数据丢失；为降低风险，本地 Prometheus 仍应适当加大 retention 或通过双实例冗余保证数据不丢。
• Store Gateway（存储网关）：负责从对象存储中读取历史数据并提供给查询模块。当查询的时间范围包含了较久之前的数据时，Thanos Query 会向 Store Gateway 请求。Store Gateway会将对应的远程分区数据下载或流式读取，返回查询结果。通过按需加载对象存储的数据，Store Gateway 实现了对无限长历史数据的查询支持，而本身并不需要大量本地存储。它也可以水平扩展，多实例共同缓存和加速数据访问。
• Query（查询网关）：也称 Querier，是 Thanos 的查询聚合层。它实现了与 Prometheus 相同的 HTTP 查询接口（Prometheus HTTP v1 API），充当统一入口。当用户（或 Grafana）发出 PromQL 查询请求时，Query 组件会将查询拆分并并行发送给后端数据源，包括最新数据从各 Sidecar 获取、历史数据从 Store Gateway 获取，然后合并结果后返回给用户。在有冗余 Prometheus 实例（多副本采集相同指标）的场景下，Query 还会对重复的数据进行去重，避免同一时间序列出现多份。通过 Query 组件，用户仿佛与一个全局的 Prometheus 交互，它屏蔽了后端多个数据源的复杂性。
• Compact（压缩器）：负责对长时间序列数据进行压缩和下采样。Compact 从对象存储中定期拉取一定时间范围的原始数据块，进行合并压缩，降低存储占用。同时，它支持对很久远的数据做下采样（如将原始15秒粒度数据下采样为5分钟粒度）。这样查询大的时间范围时可以读取经过降采样的数据，大大提升查询效率。Compact 运行在后台，不影响在线查询，其产出的压缩块仍存回对象存储供 Store Gateway 使用。
• Ruler（规则评估器）：提供类似 Prometheus 中 Recording Rules 和 Alerting Rules 的功能。Ruler 可以从 Query 查询聚合后的全局数据，基于预先定义的规则计算派生的指标或触发告警，将新生成的时间序列数据存储到对象存储中。这使得跨集群的聚合指标也能长期保存，并统一由 Thanos 进行告警判断，实现全局告警的能力。简单来说，Ruler 是 Thanos 环境下的“集中告警/记录规则执行器”。
• Receive（接收器）：这是 Thanos 的可选组件，用于替代 Sidecar 模式的另一种架构选择。在 Sidecar 模式下，各 Prometheus 实例各自存储新数据，Query 需要向每个实例查询最新值。而 Receiver 引入后，Prometheus 可以通过远程写（Remote Write）接口将数据主动推送给 Thanos Receive。多个 Receiver 组成集群接收所有 Prometheus 的数据，实现最新数据的集中存储和冗余备份，然后同样上传对象存储。Query 查询时则直接从 Receiver 获取当前数据，不必连接每个 Prometheus。Receiver 采用一致性哈希实现水平扩展，解决单点瓶颈。这种模式适合 Prometheus 实例非常多、希望统一接收的场景。不过相对增加了实时处理组件，通常在超大规模部署或对数据可靠性要求极高时采用。

典型使用场景：引入 Thanos 后，可以方便地构建高可用的集中监控体系。例如，某公司在不同区域有多个 Kubernetes 集群，各自运行着 Prometheus 来监控本集群内部的服务。通过为每个 Prometheus 部署一个 Sidecar，并接入统一的 Thanos Query 和对象存储，该公司可以实现一个全局监控视图：运维人员在 Grafana 中查询时，无需关心数据来自哪个集群，Thanos 会自动聚合所有来源的数据。一旦某个数据中心的 Prometheus 宕机或重启，Thanos 仍可以从对象存储或另一个副本获取数据，避免监控中断。同时，历史监控数据被持久化在便宜的云存储中，哪怕要查询一年前的指标也触手可及，而不必让 Prometheus 自己保存海量数据。实际案例中，Thanos 能支撑起上百个 Prometheus 实例、跨多地域的超大规模监控集群，在社区中已有很多成功实践。

总的来说，Thanos 扩展了 Prometheus 在数据保留期限和横向扩展能力方面的限制，提供了企业级所需的高可用特性。在需要全局统一监控、大规模长周期指标分析的场景下，Thanos 是Prometheus生态中非常重要的组件。值得一提的是，除了 Thanos，业界还有 Cortex、M3DB、VictoriaMetrics 等方案也可实现类似目标，不同方案在架构上各有trade-off。但对于已经熟悉 Prometheus 的团队来说，Thanos 无疑是最贴近 Prometheus 设计哲学且易于集成的选择。