Prometheus中last_over_time()与瞬时向量的区别及使用场景

二者返回结果是否完全相等 #

不相等，仅在特定条件下结果会一致。
核心差异来自二者查找最新样本的时间范围规则完全不同：

• 直接查询瞬时向量metric{}时，Prometheus默认只会从查询时间点往前回溯5分钟找最新样本（这个回溯时长由启动参数--query.lookback-delta控制，绝大多数集群不会修改默认值），如果这个时间窗口内找不到对应序列的样本，这条时间序列就不会出现在返回结果中。
• last_over_time(metric{}[1h])是手动明确指定回溯窗口为1小时，无论全局配置的回溯时长是多少，都会在查询时间点往前1小时的范围内查找，只要区间内存在样本，就返回离查询时间最近的那个值。

只有当所有待查询时间序列的最新样本，都落在全局配置的回溯窗口内时，二者返回结果才会完全一致。举个最常见的不一致场景：某条时间序列10分钟前上报了一个值之后就没有新数据了，这时候直接查metric{}会因为10分钟超过默认5分钟的回溯范围返回空，而last_over_time(metric{}[1h])可以正常返回10分钟前的样本值。

二者的适用场景 #

直接使用瞬时向量metric{}的场景 #

• 查询采集频率稳定的常规实时指标，比如15s/30s/1min采集一次的服务器CPU、内存、接口QPS等基础监控数据，这类指标的最新样本基本都在默认回溯窗口内，直接查询写法简洁，计算开销更低。
• 配置实时告警规则时使用，这类场景本身对数据时效性要求高，只关心判定时间点附近的指标状态，不需要回溯太久之前的旧样本。

使用last_over_time()函数的场景 #

• 查询上报间隔较长的指标，比如小时级/天级上报的批处理任务结果、离线业务统计指标，这类指标两次上报的间隔往往超过默认5分钟的回溯窗口，直接查瞬时向量很容易出现无返回值的情况，需要根据实际上报间隔指定对应长度的时间窗口，比如1小时上报一次就用last_over_time(metric{}[1h])，保证能稳定拿到最近一次上报的值。
• 绘制长时间范围的趋势看板时，如果查询步长（即趋势曲线上两个数据点的间隔）设置得较大，直接用瞬时向量容易在部分步长点因为回溯窗口不足出现曲线断点，用和步长、上报间隔匹配的last_over_time可以补全断点，让趋势展示更连续。
• 需要固定查询逻辑、不受Prometheus全局配置改动影响的场景，比如明确要取过去2小时内的最新上报值，写死last_over_time(metric{}[2h])就可以保证查询逻辑始终符合预期，不会因为集群运维调整全局回溯参数导致结果异常。

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