如何限制Prometheus数据聚合时间范围并调整百分位数查询间隔

限制Prometheus数据聚合的时间范围，主要分两种常见场景，对应不同实现方式：

• 指定聚合的时间窗口：如果想针对固定长度的时间窗口做聚合（比如最近1小时、过去3天），直接在PromQL的range vector中定义窗口长度即可。举几个例子：

  • 计算最近1小时内指标的总和：sum_over_time(your_metric[1h])
  • 计算过去3天内计数器指标的平均速率：avg_over_time(rate(your_counter_metric[1m])[3d])

• 限制查询的整体时间范围：如果只想获取某个特定时间段（比如昨天全天）的聚合结果，可以结合time()函数做时间戳过滤，或者用offset偏移量：

  • 用时间戳过滤昨天的聚合数据：

    sum_over_time(your_metric[1h] and on() (
      time() >= timestamp("2024-05-20 00:00:00") 
      and time() <= timestamp("2024-05-20 23:59:59")
    ))
    

  • 用offset获取昨天同一时间段的聚合：sum_over_time(your_metric[1d] offset 1d)

另外，在Grafana这类可视化工具里，直接设置面板的时间范围（比如选择“昨天”），也会自动限制Prometheus返回的数据范围，不用手动在PromQL里加过滤条件。

你遇到的核心问题是Prometheus默认的查询步长（step）和你期望的时间窗口不匹配，导致生成了大量5分钟间隔的滑动窗口结果。以下是具体修复方案：

1. 理解原查询的问题 #

你的原查询quantile_over_time(0.75, sum(metric_group{ metric="metric_name"})[3d:])逻辑是：先对每个时刻的metric_group按标签求和，再取过去3天的求和结果组成range vector，最后计算分位数。但Prometheus默认会以5分钟为步长（取决于你的配置），每5分钟就重新计算一次过去3天的分位数，所以得到的是连续的滑动窗口数据，而非你想要的3天固定窗口结果。

2. 调整PromQL查询逻辑 #

如果你的TPS指标是计数器（counter）类型，首先需要计算速率（因为TPS是每秒处理量），再对速率做分位数聚合；如果是 gauge 类型，可以直接使用。示例如下：

• 计数器类型TPS：

  quantile_over_time(0.75, rate(metric_group{metric="metric_name"}[1m])[3d])
  

• Gauge类型TPS：

  quantile_over_time(0.75, metric_group{metric="metric_name"}[3d])
  

注：如果需要按标签分组求和，把sum by (label_name)放到rate之后、quantile_over_time的range vector之前即可，比如quantile_over_time(0.75, sum by (instance) (rate(metric_group{metric="metric_name"}[1m]))[3d])

3. 设置查询步长为3天 #

这是实现3天间隔数据点的关键：

• 在Grafana中：编辑面板的Prometheus查询，找到“Step”选项（通常在查询编辑器的高级设置里），将其设置为3d。
• 直接调用Prometheus API：在请求URL中添加&step=3d参数，比如http://your-prometheus/api/v1/query_range?query=quantile_over_time(0.75, rate(metric_group{metric="metric_name"}[1m])[3d])&start=xxx&end=xxx&step=3d

这样设置后，Prometheus会把整个时间范围分成一个个3天的固定窗口，每个窗口计算一次75分位数，输出的点间隔就和Zabbix的效果一致了。

内容的提问来源于stack exchange，提问作者truncatenull