如何编写PromQL查询计算线性执行器指定时间范围的移动距离？

我在Prometheus中存储了名为position的时间序列（gauge类型），用于表示线性执行器的位置。想要计算该执行器在指定时间范围内的总移动距离——逻辑和手动计算一致：取时间序列中每个相邻样本间的绝对差值，从所选范围起始处累加求和。

但我没能写出正确的PromQL查询，尝试过的语句如下：

sum_over_time(abs(delta(position[$__range])))

（我使用Grafana执行查询，可使用$__range、$__interval等模板变量）

这个查询报错：

1:15: parse error: expected type range vector in call to function "sum_over_time", got instant vector

也试过子查询，但结果会随分辨率大幅变化，准确性不足。另外参考过针对counter指标的方案，但我的输入是gauge指标，不适用。请问应该用什么查询实现需求？

解决方案：正确的PromQL查询 #

要实现总移动距离的计算，需要通过子查询将瞬时向量转换为范围向量，再进行求和。正确的查询语句如下：

sum_over_time(abs(delta(position[$__interval]))[$__range:$__interval])

逻辑拆解： #

1. delta(position[$__interval])：计算每个$__interval时间窗口内position的变化量，返回瞬时向量（每个时间点对应一个相邻样本的差值）。
2. abs(...)：对变化量取绝对值，消除方向影响，得到单次移动的实际距离。
3. [$__range:$__interval]：将瞬时向量转换为范围向量，覆盖整个查询的时间范围$__range，同时保持每个数据点的间隔为$__interval——这一步是解决类型不匹配的关键。
4. sum_over_time(...)：对范围向量内的所有绝对值差值求和，最终得到整个时间范围内的总移动距离。

错误原因说明： #

delta()函数返回的是瞬时向量，而sum_over_time()要求输入必须是范围向量，直接嵌套会触发类型不匹配的报错——这就是你之前查询失败的原因。通过子查询的范围向量转换，就能解决这个问题。

分辨率优化建议： #

• 确保$__interval与position指标的采集间隔一致（或接近），这样能保证每个样本的变化都被捕获，避免因间隔过大丢失数据导致结果不准。
• 在Grafana中，$__interval会根据面板的时间范围和宽度自动调整，你也可以手动指定固定间隔（比如10s）来匹配你的实际采集频率。

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