【问题标题】：Prometheus range query rounding off time when used with resolution stepPrometheus 范围查询与解析步骤一起使用时的舍入时间
【发布时间】：2022-08-14 20:11:45
【问题描述】：
我有一个名为 http_requests_total 的普罗米修斯指标，它每 30 秒被刮一次。我创建了一个记录规则，以每小时间隔为我的 UI 仪表板聚合它。让我们将此新指标称为 increase_http_requests_total_60m。
我想使用这个聚合指标来进一步聚合并创建 increase_http_requests_total_1d。我的想法是这样做 - sum_over_time(increase_http_requests_total_60m[1d:60m])。
但是，我意识到与增加（http_requests_total[1d]）相比，该值将有所不同。在深入研究后，我意识到 increase_http_requests_total_60m[1d:60m] 给我的数据点正好是在下午 6 点、晚上 7 点、晚上 8 点等时间。我怎样才能使数据点实际上是 - 现在，现在 - 1 小时，现在 - 2 小时，等等？
对其他想法持开放态度，以实现我的最终目标。
标签：
prometheus
victoriametrics
【解决方案1】：
Prometheus 以特定方式计算increase()（见下文），因此increase(m[1d]) 无法匹配sum_over_time(increase(m[1h])[1d:1h])。
Prometheus 在计算increase(m[d]) 时间戳t 时存在以下问题：
- 它忽略时间戳
t-d 之前的最后一个原始样本与时间范围(t-d ... t] 上的第一个原始样本之间m 的增加。请注意，t-d 时间戳不包含在时间范围内。
- 它将外推法应用于计算出的
increase() 结果，因此它可能会从仅包含整数样本的时间序列中返回意外的分数。见this issue。
这些问题阻止了在记录规则中聚合 imcrease() 结果。
Prometheus 开发人员将解决这些问题 - 请参阅 this design doc。
附：有一个替代的类似 Prometheus 的解决方案，它以预期的方式处理这两个问题，即increase(m[X*d]) = sum_over_time(increase(m[d])[X*d:d]) 适用于任何X 和d。该系统名为 VictoriaMetrics。有关详细信息，请参阅these docs。
附言我是 VictoriaMetrics 的作者。