Prometheus 如何统计一段时间内的总请求数
increase(http_requests_total[1h]) 根据采样 Counter 估算一小时请求增量，并对可观测重置作调整。结果可能为小数，不适合精确计费；本文给出聚合与排错方法。
一句话回答：用 PromQL 的 increase() 函数：increase(http_requests_total[1h]) 返回过去一小时基于采样和外推估算的请求增量，[5m]、[1d] 同理换成 5 分钟、一天。increase 专门处理 Counter 类型指标，会调整采样中可见的计数下降，但无法恢复漏采期间不可观测的重置或请求，比直接取差值可靠。
基本用法
假设有 Counter 指标 http_requests_total（应用启动以来累计请求数）：
increase(http_requests_total[5m]) # 最近 5 分钟请求增量估计
increase(http_requests_total[1h]) # 最近 1 小时
increase(http_requests_total[1d]) # 最近 1 天
increase 与 rate 的区别
| 函数 | 返回 | 适用 |
|---|---|---|
increase(m[1h]) |
这段时间的估算增量（次数） | "过去一小时共多少请求" |
rate(m[5m]) |
每秒平均增量（次/秒） | "QPS 是多少"画趋势图 |
两者的关系：increase(m[1h]) = rate(m[1h]) * 3600。要总量用 increase，要速率曲线用 rate。
多实例与多标签聚合
指标通常带 instance、job、status 等标签，直接 increase 会按标签组合返回多条序列。常用聚合：
# 全部实例合计
sum(increase(http_requests_total[1h]))
# 按状态码分组看
sum by (status) (increase(http_requests_total[1h]))
# 只看 5xx
sum(increase(http_requests_total{status=~"5.."}[1h]))
为什么不能用 last - first
直接拿区间首尾相减（m - m offset 1h）看起来也能算增量，但有两个致命问题：
- Counter 重置：进程重启后计数器归零，首尾相减会得到负数或严重偏小的值；increase 会根据观测到的下降调整重置，不能保证检测两次抓取之间发生的全部重置
- 外推修正：采样点很少恰好落在区间边界上，increase 会按窗口内实际增长率做外推，结果是窗口总增量的估计，不能据此保证比所有其他方法更接近真实请求总数
注意事项
- 区间别太短：
[1m]内可能只有 2 个采样点，外推误差大；经验法则是区间 ≥ 4 倍采集间隔 - 结果是浮点数：increase 的外推机制会让"整数请求数"变成小数（如 1023.6），属正常现象
- 只适用于 Counter：Gauge（瞬时值）可以比较差值，但没有 Counter 的重置语义，不应对 Gauge 用 increase；按需求使用 delta 等函数
请求增量来自采样与外推，精确计费或审计应使用持久化业务事件或交易记录。
常见问题（FAQ）
Q：increase 算出来的数比实际少/多？
A：先检查区间与采集间隔的比例（太短不准）；再确认指标真是 Counter 且没有多 job 重复采集；多实例场景忘了 sum 会以为"数不对"，其实是按标签拆成了多条。
Q：想统计"今天 0 点到现在"的请求数，increase 能做到吗？
A：increase 相对查询的求值时刻回看。Grafana 可把时区和范围设为当天零点到现在，在结束时刻执行 Instant 查询 sum(increase(m[$__range]))；Range 查询会在每个步长重复计算回看窗口。不要直接用日初 Counter 作差，重置会破坏结果；自然日结果仍是估计。
Q：Counter 重置后 increase 会算错吗？
A：仍可能有误差。观测到数值下降时按 Counter 重置调整，但两次抓取之间发生重置后又增长到高于前值、漏采或序列新出现时，无法完整恢复真实增量。应先对每条序列 increase 再 sum，避免聚合掩盖重置。
核查依据
本文依据官方文档核对，示例未在实际业务环境运行；上线前请按部署版本、权限与数据范围验证。
