第4章 PromQL入门

第4章：PromQL入门：即时向量与范围向量、选择器、基础查询与Grafana Explore调试

好，咱们进入PromQL的世界了。

说实话，很多运维同学一看到PromQL就头大，觉得像天书。其实没那么复杂。我刚开始接触时也懵，但后来发现，只要搞懂两个核心概念——即时向量和范围向量，后面就顺了。

4.1 即时向量 vs 范围向量：两个核心概念

先问个问题：你查CPU使用率，是想看“当前这一刻的值”，还是想看“过去5分钟的变化趋势”？

这两个需求，对应了PromQL里最基础的两个数据类型。

4.1.1 即时向量（Instant Vector）

即时向量，说白了就是“某个时间点上的快照”。它返回一组时间序列，每个序列只有一个最新样本值。

举个例子：

node_cpu_seconds_total

这条查询返回的是当前时刻所有CPU核的累计运行时间。每个CPU核对应一条时间序列，每条序列只有一个值。

我在项目中经常用它做“实时监控面板”——比如想看现在哪台机器的内存快满了，直接查node_memory_MemAvailable_bytes，一目了然。

  关键点：即时向量不带时间范围，只返回最新数据点。查询时如果不指定时间，默认就是“当前时间”。

4.1.2 范围向量（Range Vector）

范围向量就不一样了。它返回的是一段时间内的多个样本点，形成一个数据序列。

写法上，就是在指标名后面加个中括号，里面写时间范围：

node_cpu_seconds_total[5m]

这条查询返回的是过去5分钟内，每个CPU核的所有采样值。注意，不是平均值，是每个时间戳对应的原始值。

为什么要用范围向量？因为很多计算需要历史数据。比如算CPU使用率，你得知道“过去1分钟里，CPU忙了多久”，这就要用到范围向量。

我的习惯：做告警规则时，我几乎只用范围向量。因为单点抖动太常见了，只看即时值容易误报。比如内存突然飙高1秒又回落，用即时向量就会触发告警，但用范围向量算5分钟平均值，就稳得多。

4.2 选择器：精准定位你的数据

有了指标名，你只能拿到一堆数据。但实际场景中，我们往往需要筛选——比如只看某个机器的CPU、只看某个容器的内存。

这时候就要用标签选择器了。PromQL支持四种选择器，我一个个说。

4.2.1 精确匹配：= 和 !=

= 表示“等于”，!= 表示“不等于”。

举个例子：

node_cpu_seconds_total{cpu="0"}

这条只返回CPU编号为0的数据。如果你想排除某个CPU：

node_cpu_seconds_total{cpu!="0"}

嗯，这里要注意：!= 不是“不等于某个值”，而是“排除某个值”。它会把所有不匹配的序列都返回。

4.2.2 正则匹配：=~ 和 !~

当标签值很多，你又想批量匹配时，正则就派上用场了。

=~ 表示“匹配正则表达式”，!~ 表示“不匹配正则表达式”。

比如，我想看所有CPU核（cpu0到cpu3）的数据：

node_cpu_seconds_total{cpu=~"cpu[0-3]"}

或者排除某些磁盘：

node_disk_io_time_seconds_total{device!~"loop.*"}

我曾经踩过的坑：正则表达式写错了，导致查询结果为空。比如 cpu=~"cpu[0-3]" 和 cpu=~"cpu[0-3]" 看起来一样，但如果你写成 cpu=~"cpu[0-3]" 而实际标签是 cpu="0"（没有“cpu”前缀），那就匹配不上了。所以，先查一下标签的真实格式，再写正则。

4.3 基础查询示例：从简单到实战

光说不练假把式。咱们直接上手几个例子。

4.3.1 查看当前内存使用量

node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

这条查询用了算术运算，把两个即时向量相减，得到当前已使用的内存字节数。

4.3.2 计算CPU使用率（经典公式）

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

这个公式我几乎每天用。解释一下：

rate(node_cpu_seconds_total{mode="idle"}[5m])：计算过去5分钟内，CPU空闲时间的每秒变化率
avg by (instance)：按机器实例求平均（因为一台机器可能有多个CPU核）
100 - ... * 100：把空闲率转换成使用率

  注意：这里用了 rate() 函数，它只能用在范围向量上。如果你传即时向量给它，会报错。我刚开始就犯过这个错。

4.3.3 查看最近1小时的网络流量

rate(node_network_receive_bytes_total[1h])

返回的是每秒接收字节数，单位是bytes/s。如果想看MB/s，可以再除以1024^2。

4.4 Grafana Explore调试：你的PromQL实验室

写PromQL最怕什么？写完了不知道对不对。我以前都是直接贴到面板上，刷新看效果，效率极低。

后来我发现Grafana的Explore功能，简直是调试神器。

4.4.1 打开Explore

在Grafana左侧菜单栏，找到那个指南针图标，点进去就是Explore。它就像一个交互式查询终端。

4.4.2 实时调试技巧

分步验证：先查一个简单指标，比如 node_cpu_seconds_total，看看返回的数据结构。确认标签名、标签值都对了，再逐步加筛选、加函数。
切换视图：Explore支持表格和图表两种视图。表格适合看原始数据，图表适合看趋势。我一般先用表格确认数据点，再用图表看曲线是否合理。
调整时间范围：右上角可以选时间。比如你想查过去1小时的数据，就选“Last 1 hour”。这个很关键，因为范围向量的查询结果跟时间范围直接相关。

我的调试流程：

先查 node_cpu_seconds_total，看有哪些标签
加筛选，比如 {mode="idle"}，确认数据量
加范围，比如 [5m]，看原始数据点
加函数，比如 rate()，看计算结果
最后加聚合，比如 avg by (instance)

每一步都确认结果符合预期，再往下走。这样基本不会出错。

4.4.3 常见调试问题

问题	可能原因	解决方法
查询返回空	指标名写错、标签不匹配、时间范围不对	先用 `node_cpu_seconds_total` 确认指标存在，再逐步加条件
数据点太多	没有加聚合，返回了所有时间序列	用 `sum`、`avg` 等聚合函数，或者用 `by` 分组
图表曲线断断续续	采样间隔不匹配，或者数据有缺失	检查Prometheus的scrape_interval，调整查询的时间范围

嗯，说到这，我想起一个真实案例。有一次我写了个告警规则，查过去5分钟的磁盘IO使用率，结果一直不触发。后来用Explore一查，发现我的正则写错了，把要监控的磁盘给排除了。要是没有Explore，我可能得排查半天。

所以，Explore就是你的调试利器。写PromQL之前，先在里面跑一遍，确认结果对了，再往面板或告警里放。这个习惯，能帮你省下大量排错时间。

  总结一下：
  即时向量看“当前”，范围向量看“一段历史”
选择器帮你精准定位数据，正则匹配很强大但要注意格式
基础查询从简单指标开始，逐步加函数和聚合
Explore是调试PromQL的最佳场所，分步验证最稳妥

下一章，咱们会深入PromQL的函数和操作符，到时候你会发现，原来复杂的监控指标，拆解开来也就那么回事。

📚 课程目录