3、PromQL 核心回顾：Range Vector、Instant Vector、Offset、Rate、Increase 等关键函数
在长周期容量规划建模中，PromQL 是连接原始指标与容量洞察的桥梁。本章聚焦于构建升级容量模型最常用的 PromQL 数据类型与函数，理解它们的差异与适用场景，是避免建模错误的第一步。
3.1 两种核心数据类型：Instant Vector 与 Range Vector
PromQL 的查询结果分为两种基本类型，它们在容量规划中扮演不同角色：
| 类型 | 定义 | 容量规划典型用途 | 示例 |
|---|---|---|---|
| Instant Vector | 某一时刻所有时间序列的最新样本值 | 当前集群节点内存使用率、实时 CPU 饱和度 | node_memory_MemTotal_bytes |
| Range Vector | 一段时间窗口内每个时间序列的样本集合 | 过去 7 天的 CPU 使用率趋势、内存增长速率 | node_memory_MemTotal_bytes[7d] |
建模要点： 容量规划几乎总是基于 Range Vector 进行聚合计算。仅靠 Instant Vector 的快照值无法反映集群负载的波动性与增长趋势，容易导致升级窗口评估过于乐观或悲观。
下图展示了 Instant Vector 与 Range Vector 在时间轴上的数据采集差异：
3.2 Offset 修饰符：时间偏移与同比/环比分析
offset 允许查询向前或向后偏移指定时间，在容量规划中主要用于同比（年/周同比）和环比（日/周环比）对比：
- 同比对比：
node_cpu_seconds_total[7d] offset 7d— 对比上周同期的 CPU 使用模式。 - 环比对比：
node_memory_MemFree_bytes offset 1d— 对比昨天同一时刻的空闲内存。 - 升级前后对比： 在升级窗口前后使用
offset对齐时间基线，评估升级对资源使用率的影响。
常见陷阱：
offset 仅改变查询的时间起点，不会改变 Range Vector 的窗口长度。例如 rate(node_cpu_seconds_total[5m] offset 1h) 计算的是 1 小时前那个 5 分钟窗口内的速率，而非当前窗口。
3.3 关键聚合函数：Rate、Increase、IRate
这三个函数是容量规划中最频繁使用的 PromQL 工具，它们将原始 Counter 指标转换为可解读的速率或增量：
| 函数 | 输入类型 | 输出含义 | 容量规划典型场景 |
|---|---|---|---|
rate() |
Range Vector (Counter) | 窗口内每秒平均增长率 | CPU 使用率、网络流量、请求速率 |
increase() |
Range Vector (Counter) | 窗口内总增量 | 磁盘空间消耗量、内存分配总量 |
irate() |
Range Vector (Counter) | 窗口内最后两个样本的瞬时速率 | 突发流量检测、短时间窗口的峰值识别 |
容量规划最佳实践：
- 使用
rate()评估长期资源消耗趋势（窗口 ≥ 5m），避免短时毛刺干扰。 - 使用
increase()计算升级周期内的资源消耗总量，用于容量预算。 - 仅在需要捕捉突发峰值时使用
irate()，但注意其对采样间隔敏感，不适合长周期建模。
下图展示了 Rate 与 Increase 在相同窗口下的计算逻辑差异：
3.4 实战：构建升级容量评估查询
结合上述知识，一个典型的集群升级容量评估查询模板如下：
# 评估升级前 7 天 CPU 平均使用率趋势
avg by (instance) (
rate(node_cpu_seconds_total{mode!="idle"}[5m] offset 7d)
)
# 计算升级窗口期间内存消耗总量
sum by (instance) (
increase(node_memory_MemTotal_bytes[24h])
)
# 同比对比：本周 vs 上周同一时段网络入流量
rate(node_network_receive_bytes_total[5m] offset 7d)
/
rate(node_network_receive_bytes_total[5m])
建模建议： 在长周期容量规划中，优先使用
rate() 配合 offset 进行同比/环比趋势对比。避免在 Gauge 类型指标上直接使用 rate() 或 increase()，它们专为 Counter 设计，对 Gauge 使用会导致无意义的结果。