掌握Prometheus四大指标类型：从原理到实战PromQL查询

摘要： 要高效使用Prometheus进行监控，深入理解其四种核心指标类型（Counter、Gauge、Histogram、Summary）是基础。本文将详细解析每种类型的设计原理、适用场景，并通过丰富的PromQL实例演示如何查询和分析这些指标，助您真正玩转Prometheus监控。

---

一、 概述：为什么需要不同的指标类型？

Prometheus的监控数据基于时间序列，而每个时间序列都有一个唯一的指标名称和一组标签。为了高效地表示不同类型的监控数据，Prometheus定义了四种核心指标类型。理解它们的差异是写出有效PromQL查询的关键。

二、 四大指标类型详解与PromQL实战

1. Counter（计数器）

• 作用与特点：

  • 一种只增不减的单调递增计数器。其值在进程重启时会被重置为零，但Prometheus会在抓取间隔中识别并处理这种重置情况。
  • 非常适合用来表示累计数量，例如：请求总数、错误发生总次数、任务完成总数等。

• 常见指标名称： http_requests_total， errors_total， process_cpu_seconds_total。

• PromQL实战应用：

  • 场景： 我们通常不直接使用Counter的当前值，而是关注其在一定时间内的增长速率。
  • 查询1：计算QPS（每秒请求率）

    PromQL: rate(http_requests_total{job="api-server"}[5m])

    解释： 计算最近5分钟内，api-server 作业的HTTP请求每秒速率。rate() 函数会自动处理计数器重置，是使用Counter时最核心的函数。
    
    

  • 查询2：计算1小时内的总请求量

    PromQL: increase(http_requests_total{job="api-server"}[1h])

    解释： 计算最近1小时内请求总量的增加值，等同于 rate(...)[1h] * 3600。increase() 是 rate() 的语法糖，更适于计算时间段内的总量。

  下图直观展示了Counter的增长与rate()函数的关系：

  graph LR A[应用收到请求] --> B(Counter值增加) B --> C{Prometheus抓取} C --> D[获取当前计数值] D --> E[使用rate/increase函数<br>计算区间内的增长量] E --> F(得到速率或增量)

2. Gauge（仪表盘）

• 作用与特点：

  • 一种可增可减的度量值，用于反映当前状态的瞬时快照。
  • 非常适合用来表示可以上下变化的数量，例如：CPU/内存使用率、当前连接数、队列长度、温度等。

• 常见指标名称： memory_usage_bytes， node_load1， go_goroutines。

• PromQL实战应用：

  • 场景： 直接查询当前值，或进行聚合、排序等操作。
  • 查询1：查看当前内存使用量

    PromQL: memory_usage_bytes{instance="host-01"}

    解释： 直接获取主机 host-01 的瞬时内存使用量。
    
    

  • 查询2：按实例排序，显示CPU使用率最高的3台主机

    PromQL: topk(3, memory_usage_bytes)

    解释： 使用 topk() 函数找出当前内存使用量最高的3个时间序列。
    
    

  • 查询3：计算当前平均队列长度

    PromQL: avg_over_time(queue_length[10m])

    解释： 计算队列长度在最近10分钟内的平均值，用于观察较长时间段的整体水位。

3. Histogram（直方图）

• 作用与特点：

  • 用于测量一组值的分布情况（如请求延迟、响应体大小）。它会对观测值进行分桶（Bucket）计数，从而可以计算分位数（如P90， P99）。
  • 自动生成多个时序：
    1. 基础指标： <basename>_bucket{le="<upper bound>"} (各桶的计数，只增不减)
    2. 总和： <basename>_sum (所有观测值的总和，只增不减)
    3. 总数： <basename>_count (总的观测次数，只增不减)

• 常见指标名称： http_request_duration_seconds。

• PromQL实战应用：

  • 场景： 分析请求延迟的分布，例如“95%的请求在多少秒内完成？”
  • 查询1：计算近5分钟内99%的请求延迟

    PromQL: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

    解释：

    1. rate(...[5m])： 先计算每个桶在5分钟内的增长速率。
    2. histogram_quantile(0.99, ...)： 根据每个桶的速率数据，计算出99%的请求延迟都小于的数值。
       注意： Histogram是先天配置（桶的边界是预先定义好的），查询时可以灵活计算任意分位数，但精度受桶边界影响。

  • 查询2：计算平均请求延迟

    PromQL: rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

    解释： 用总延迟除以总请求数，得到平均延迟。

4. Summary（摘要）

• 作用与特点：

  • 与Histogram类似，也用于测量值的分布情况。
  • 关键区别： Summary在客户端直接计算分位数（如P99）。
  • 自动生成多个时序：
    1. 分位数指标： <basename>{quantile="<φ>"} (如 φ=0.99)
    2. 总和： <basename>_sum
    3. 总数： <basename>_count

• 常见指标名称： go_gc_duration_seconds。

• PromQL实战应用：

  • 场景： 直接获取在客户端计算好的分位数。
  • 查询：直接获取99%的GC延迟

    PromQL: go_gc_duration_seconds{quantile="0.99"}

    解释： 直接查询由Go客户端计算好的P99分位数。
    注意： Summary是后天计算（分位数在客户端计算好），查询简单，但无法在查询时聚合，且分位数计算在客户端有开销。

三、 Histogram 与 Summary 的核心区别与选择

特性	Histogram（直方图）	Summary（摘要）
分位数计算	在服务端（PromQL）灵活计算，可聚合	在客户端预先计算，不可聚合
配置灵活性	服务端可灵活调整分位数	分位数目标在客户端预定义，无法更改
精度	受预定义的桶（bucket）边界影响	客户端计算，精度较高
性能开销	客户端开销低	客户端有计算分位数的开销
适用场景	绝大多数情况推荐使用，尤其是在需要聚合多个实例数据时（如计算整个服务的P99延迟）	需要高精度分位数，且不需要聚合的场景

结论： 在大多数情况下，特别是需要监控分布式系统时，推荐使用Histogram，因为它提供了更大的灵活性。

四、 总结

• Counter： 看速率，用 rate() 或 increase()。
• Gauge： 看当前值，可做聚合、排序。
• Histogram/Summary： 看分布和分位数，Histogram更灵活，适用性更广。

熟练掌握这四种指标类型及其对应的PromQL查询模式，是构建有效监控和告警的基石。希望本文的实例能帮助您更好地理解和运用它们。