rate(http_requests_total[$__rate_interval]) wget -qO- 'http://prom:9090/api/v1/query?query=sum(rate(http_requests_total[1m]))' | jq '.data.result[0].value'
压测时网关日志统计出 3000 QPS，Grafana 面板上只有 1200。把时间范围从 6 小时缩到 30 分钟，同一个面板立刻变成 3100。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，面板的 step 由时间范围除以最大点数算出来，6 小时下每个点跨 60 秒。rate 是按点内的样本算的，点变少后瞬时峰值被平均掉。采集间隔 15 秒，step 却设成 1m，等于四个样本合成一个平均值。
这次卡住的地方就在「Grafana step 聚合」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
处理上按这个顺序：把 step 固定成和抓取间隔一致 别让它自动算；rate 窗口写成 $__rate_interval 让它跟着 step 走；最大数据点数调到 1000 以上 保持短窗口分辨率；用同一时间段的日志统计做对照 确认两边口径一致。
改完只确认一件事：面板数值和日志统计的 3000 QPS 相差在 5% 以内，切换时间范围数值不再跳变。