本篇是《Prometheus 从入门到生产实践》第 8 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
请求总数每天都在增，直接把 counter 画成一条折线，只能看到累计量。值班真正关心的是“最近每秒多少请求”“失败比例是否增加”。本篇把累计指标转成这些可解释的业务量。
1. Counter 是累计观察，不是当前负载
ops_demo_requests_total 随业务请求增加，进程重启后可以回到较小值；ops_demo_inflight_requests 表示当前在处理的请求数，可以自然升降。前者使用 rate，后者通常直接观察或做时间聚合。
不要因为某条 Gauge 恰好一直上涨，就把 rate 当作通用“趋势函数”。rate() 专门处理 counter 的单调增长及重置；需要 Gauge 的变化趋势，可以根据问题研究 delta、deriv 等函数。
2. 从一条序列的每秒速率开始
rate(ops_demo_requests_total{job="demo",route="/api",code="200"}[5m])
它为每一组原始标签返回五分钟窗口内平均每秒增加量，单位为 requests/second。结果仍可能包含 method、route、code、job、instance，尚未跨实例合并。
教学中若样本每 15 秒增加 30 次，稳定情况下速率约为 2 次/秒。rate 不只是两个端点相减再除以精确窗口秒数：它还会考虑窗口边缘、样本间隔与重置，因此少量丢抓也不一定导致完全相同的结果。
公式语义和外推行为见 rate 与 increase 官方说明。
3. 为什么必须先 rate 后 sum
服务有多个实例时，应先对每个实例识别重置，再汇总：
sum by (job, route) (
rate(ops_demo_requests_total{job="demo"}[5m])
)
假设一个实例从 1000 重置到 10，另一个同时增加 1200。先求和可能看起来总量仍在上涨，把前者的重置隐藏掉。再对这个聚合结果求 rate，就无法准确恢复各实例发生的事。
所以“总请求速率”是“每条 counter 的速率之和”，不是“先把原始 counter 混合，再希望计算器识别每条序列的重置”。这条规则对 histogram 的 bucket、count 等 counter 序列同样重要。
4. increase、rate、irate 各适合什么
| 函数 | 回答的问题 | 常见用途 |
|---|---|---|
| rate(counter[5m]) | 窗口内平均每秒增加多少 | QPS、告警和趋势 |
| increase(counter[1h]) | 窗口内估算累计增加多少 | 一小时请求量、报表概览 |
| irate(counter[5m]) | 最后两个有效点的快速变化率 | 探索短时波动 |
increase 与 rate 使用相同类型的重置修正和外推思想；它不是精确的交易审计计数，因此可能得到非整数。用于对账时应使用业务数据源，不能把监控估算当成账本。
irate 即使写 [5m]，也主要使用其中最后两个有效点，并不对整个五分钟平均。它容易随抓取抖动产生尖峰，告警通常更适合用能代表持续趋势的 rate。
5. 失败率的分子、分母必须覆盖同一总体
共享实验中 code 只有 200 与 500，下面按 job、route 计算 5xx 占全部请求的比例：
sum by (job, route) (
rate(ops_demo_requests_total{job="demo",code=~"5.."}[5m])
)
/
sum by (job, route) (
rate(ops_demo_requests_total{job="demo"}[5m])
)
分子和分母都先合并 method、code、instance，留下相同标签维度。结果 0.02 表示 2%，不要再把它当成百分数值 2 交给“0～1 百分比”图表单位。
如果分子只筛了某个 route，而分母却统计全部接口，结果回答的会是另一个问题。业务是否把 4xx、超时或取消请求算失败，也必须写进 SLI 约定，不能只凭状态码习惯决定。
6. 没有请求与没有数据
分母为 0 时，比例未必有定义；分子序列根本没暴露时，也可能没有匹配项。不要直接用 clamp_min(分母,1) 就宣称得到“真实错误率”，因为这改变了低流量时的数学含义。
可以给比率查询增加有流量的过滤条件，并把无流量、无采集数据作为另外的状态。下一篇向量匹配会解释如何按明确的标签基线补零，而不是把整幅图的缺失全部变成健康。
7. 检查重置与选窗口
resets(ops_demo_requests_total{job="demo"}[1h])
resets 返回观察到的 counter 重置次数，帮助解释进程重启或指标实现异常。它不是所有重启的完整清单；如果重启发生在两个抓取之间且新值已超过旧值，单靠采样数据未必观察得到。
窗口需要容纳足够抓取点。常见经验是先从数倍抓取间隔开始，但漏抓、低流量和希望响应多快也会影响选择。把窗口调得很短，可能只是把缺样和噪声画大，而不是让监控更准确。
8. 实验与结果解释
先让 /api 正常产生 200，再访问 /api?fail=1 产生 500。观察原始 counter 单调增长、rate 变为非零、错误率随后改变。请求是零散手动触发的，五分钟平均速率应较小，不应期待每点都显示整数 QPS。
只在专用实验中重启 demo，比较原始值下降与 rate 的处理，再查 resets。写下窗口、单位、聚合维度和失败定义，这四项是交付一条速率查询时应保留的说明。
上一篇：PromQL 基础与时间语义：选择器、窗口、offset 和过期 · 系列目录 · 下一篇：延迟与分布：经典/原生直方图、P95 和 Summary