指标系统在监控领域是最核心的系统之一，我们主要以 prometheus+thanos 构建指标平台。
- 其中 thanos 是一个用于 prometheus 生态系统的分布式系统，它扩展了 prometheus 平台的能力以支持长期存储和查询大规模时间序列数据。
- 在指标体系中发挥作用：长期存储、数据复制和高可用性、跨集群查询、查询优化和性能增强、监控和告警的作用。
- 一般的数据查询链路：thanos-frontend → thanos-query → (prometheus+thanos-store) 。 这次我们遇到查询时间粒度为天的数据时，存在8h偏移。
问题现象
问题: 按天聚合，预期每天对应一个数据点。但是我们发现每个数据的的计算范围并不是 1整天的00:00点到00:00，而是向后偏移了8h。 直观的看，下图是酷家乐监控系统的查询页面，红框中数据点的时刻是7-19 8:00， 聚合范围为 7-18 8:00 ～ 7-19 8:00
而我们预期的是聚合范围为 7-18 0:00 ～ 7-19 0:00 ，这里明显向后偏移了8h。猜测是 prometheus 中使用时间粒度配合 start、end 时间使用UTC时间对齐了边界。 
问题排查
github 上找到了类似的issue：github.com/prometheus/...
这里提问者是希望对齐，但是官方表示不会自动使用时间粒度/step 对齐。 
为啥 Grafana 能展示正确？
然而发现 grafana 上好像能正确处理，对齐到整点了。这就让我很迷，难道grafana有什么魔法？ 
查一下整点区间的数据，基本也能对上，是符合的： 
于是我下载了grafana 源码，仔仔细细地看了最后发起对 datasource 的参数，并追溯了这些参数在途中有无重写和变更。最后发现grafana 仅仅对start、和 end 做了 对齐。理论上这不会改变查询的返回结果中每个点偏移8小时。
问题定位
怀疑 thanos-frontend 有什么特殊之处
偶然想到我们的查询第一层走的 thanos-frontend，而 grafana 使用的 thanos-query。难道这两个组件不能保持查询结果的一致性？
于是下载了 thanos-frontend 源码，在仔细翻阅后发现，frontend 会先对start、end 做对齐，然后为了拆成小查询缓存，会将查询按天拆分一次的。
查询时间按 step 对齐(下面如 2023-07-17 13:53:04 的时间均为 Asia/shanghai 时区 )：
比如原始 start 、end 分别为 1689573184（2023-07-17 13:53:04） 和 (1689918784) 2023-07-21 13:53:04
会对齐为：1689552000 （2023-07-17 08:00:00 ） 和 1689897600 （2023-07-21 08:00:00）
拆分查询时明确说了 "First we're going to build new requests, one for each day, taking care to line up the boundaries with step."
因此这里多个按天的请求均和前面的对齐有关，比如多个小请求的第一个 ，其 end = 1689552000 （2023-07-17 08:00:00 ）, 于是 promethus 对这个点的聚合范围就是 2023-07-17 08:00:00 倒推一天的区间，因此这个数据点的时间戳也就会打成 1689552000 （2023-07-17 08:00:00 ）。 
解决方案
问题已经明确了，怎么解决这个问题呢？
（时间粒度是每个点的数据聚合范围，step是间隔多长时间计算一个数据点。请注意，本篇文章将时间粒度和step概念混淆了，是因为 在统一查询层中我们一般会将 step设置为时间粒度大小。这样 range query 时展示的每个点的聚合范围都是当前点个上一个点之间的时间范围。比如展示按时间粒度区间增长量的趋势图，如果对图做积分，得到的就是增长总量。）
如果按天的倍数聚合，就主动按所在时区主动偏移。测试后满足我们的需求： 
解决后效果：完美匹配
注意： prometheus 机制：展示的每个点实际聚合范围是这个点倒推一个时间粒度。比如 7-23 00:00 这个点实际计算的 7-22 00:00 到 7-23 00:00 之间。
问题查明后向 thanos 社区反馈。