2. PromQL 性能瓶颈分析：识别慢查询的常见原因

在告警规则与采集作业平台中，PromQL 查询的性能直接决定了告警延迟、仪表盘加载速度以及 Prometheus 自身的资源消耗。本章将系统性地分析导致 PromQL 查询缓慢的四大核心瓶颈：高基数、大范围、复杂聚合 与 未使用合适的函数，并介绍如何通过 HTTP API 的 stats 字段精准定位慢查询。

2.1 四大性能瓶颈深度解析

2.1.1 高基数：最致命的性能杀手

高基数是指某个标签（如 instance、pod、user_id）拥有大量不同的取值。Prometheus 的 TSDB 为每个唯一的标签组合创建一个时间序列。当标签组合数量达到百万级时，查询引擎需要遍历海量序列，导致内存与 CPU 耗尽。

高基数识别方法：

• 使用 count by (label_name) (metric_name) 统计标签取值数量。
• 监控 Prometheus 的 prometheus_tsdb_series_count 指标，观察序列总数增长趋势。
• 检查 /api/v1/status/tsdb 接口返回的 labelValueCountByLabelName 字段。

2.1.2 大范围：时间窗口失控

PromQL 中的范围向量选择器（如 [5m]、[1h]）决定了需要加载的原始样本数量。时间窗口越大，需要从磁盘读取的数据块越多，I/O 等待时间越长。

典型场景对比：

2.1.3 复杂聚合：CPU 的噩梦

多层嵌套的 sum()、avg()、topk() 以及大量 by() 子句会导致查询引擎在内存中构建巨大的中间结果集。特别是 topk() 和 quantile() 这类需要全局排序或分位数计算的函数，CPU 开销极高。

低效示例：

# 多层嵌套，无预聚合
sum by (job) (
  rate(
    sum by (instance, job) (
      http_requests_total{status="5xx"}
    )[5m]
  )
)

优化建议：

• 使用 Recording Rules 预聚合高频查询。
• 减少 by() 子句中的标签数量，只保留必要的维度。
• 避免在 rate() 或 increase() 内部嵌套聚合函数。

2.1.4 未使用合适的函数：精度与性能的失衡

PromQL 提供了多种功能相似但性能差异巨大的函数。选择不当会导致不必要的计算开销。

2.2 通过 HTTP API 的 stats 字段定位慢查询

Prometheus 的 HTTP API 提供了 stats 字段，可以返回查询执行的详细耗时分解。这是定位慢查询瓶颈的最直接手段。

2.2.1 启用 stats 字段

在调用 /api/v1/query 或 /api/v1/query_range 时，添加参数 stats=all：

curl 'http://localhost:9090/api/v1/query?query=rate(http_requests_total[5m])&stats=all'

2.2.2 stats 字段结构解析

返回的 JSON 中包含 stats 对象，其核心字段如下：

2.2.3 实战：通过 stats 字段诊断慢查询

假设我们执行一个慢查询并获取 stats 输出：

{
  "status": "success",
  "data": {
    "resultType": "vector",
    "result": [...]
  },
  "stats": {
    "timings": {
      "evalTotalTime": 12.345,
      "resultSortTime": 0.002,
      "execQueueTime": 0.001,
      "innerEvalTime": 12.340
    },
    "samples": {
      "totalQueryableSamples": 85000000,
      "peakSamples": 42000000
    }
  }
}

诊断分析：

• 总耗时 12.3s：远超正常范围，属于严重慢查询。
• innerEvalTime 占 99.9%：瓶颈在 PromQL 表达式执行阶段，而非排队或排序。
• totalQueryableSamples 8500 万：扫描样本数极高，指向高基数或大范围问题。
• peakSamples 4200 万：内存压力巨大，可能导致 OOM。

优化方向：

1. 检查查询中涉及的指标标签基数，使用 count by (label) (metric) 定位高基数标签。
2. 缩小时间窗口，或使用 Recording Rules 预聚合。
3. 考虑增加 match[] 参数缩小查询范围。

2.3 性能瓶颈分析流程图

下图展示了从发现慢查询到定位根因的完整分析流程：

2.4 常见慢查询模式速查表

以下表格总结了生产环境中最常见的慢查询模式及其对应的 stats 特征：