Prometheus查询返回的是带标签的时间序列数据，而非单个数值：即时向量表示某时刻各目标最新状态，区间向量表示一段时间内样本轨迹，标量为纯浮点数；三者分别支撑绘图、函数计算和数值运算。
Prometheus 查询不是“查一条数”，而是对时间序列做函数式变换和向量级运算。它不返回单个值，而是一组带标签、有时间上下文的数据点——要么是某个时刻的快照（即时向量），要么是一段时间内的轨迹（区间向量）。掌握这个前提，才能避开“为什么结果为空”“为什么画不出图”这类常见卡点。
理解三类基础数据类型的实际含义
PromQL 所有表达式最终都归为四种类型，但真正参与计算和绘图的主要是前三种：
-
即时向量：比如
up或node_load1，代表“此刻各目标的最新状态”。图形面板、告警规则、仪表盘指标卡片基本都依赖它； -
区间向量：如
http_requests_total[5m]，不是单个数字，而是过去 5 分钟里每 15 秒采集一次的一串样本。它本身不能直接画图，但它是rate()、sum_over_time()等函数的唯一合法输入； -
标量：纯数字，比如
count(up == 1)返回一个整数。它能参与四则运算，但无法绘图、不能接聚合操作符（如by）、也不能用于告警条件中的比较（除非转成向量）。
用对函数，才能算出真实业务指标
很多初学者直接写 http_requests_total 就想看 QPS，结果发现数值越来越大——因为它是 Counter 类型，必须用速率函数“解开”：
-
rate(http_requests_total[5m])：过去 5 分钟平均每秒请求数（自动处理重启重置）； -
irate(http_requests_total[5m])：用最近两个点估算瞬时速率，适合排查突发抖动； -
increase(http_requests_total[1h])：算出这 1 小时内总请求数，适合日报统计； -
delta(cpu_temp_celsius[2h])：直接得出两小时温差，比手动减更可靠（自动对齐时间窗口）。
注意：rate() 和 irate() 只接受区间向量，且时间范围不宜过短（低于 4 倍抓取间隔易失真）。
向量匹配与聚合：让多维数据可读可控
原始指标常带几十个标签（pod、container、namespace、job…），不聚合就无法看清趋势。关键在于分清“怎么分组”和“怎么对齐”：
-
sum by (job, instance)(rate(http_requests_total[5m]))：按 job+instance 分组求和，保留这两个维度； -
avg_over_time(node_load1[30m])：对单个节点过去半小时负载取平均，结果是标量； - 遇到“向量只能与同标签向量运算”报错？试试
on()或ignoring()显式指定匹配维度，例如：rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m])会失败，需改为：rate(http_requests_total{code=~"5.."}[5m]) / ignoring(code) rate(http_requests_total[5m])； -
topk(3, sum by (pod_name)(rate(container_cpu_usage_seconds_total[5m])))：找出 CPU 消耗最高的 3 个 Pod，无需先排序再截取。
偏移与对比：做环比、同比、健康基线
监控不只是看当前值，更要判断“是否异常”。偏移修饰器 offset 是实现横向对比的核心工具：
-
rate(http_requests_total[5m]) / rate(http_requests_total[5m] offset 1d)：今日每秒请求数 vs 昨日同期，结果 >1.2 可触发增长告警； -
(sum(up{job="apiserver"}) by (job)) / count(up{job="apiserver"})：当前健康实例占比；再叠加offset 1w就能算出“上周此时的健康率”，做稳定性趋势分析； -
absent(up{job="legacy-service"})：当某服务完全消失（无任何样本）时返回 1，适合检测意外下线。
