Thanos查询数据缺失与Prometheus结果差异问题咨询

匹配你测试场景的实际触发诱因 #

• Querier后端请求超时的隐性截断
  这是最常见的匹配你观测现象的原因：Thanos Querier默认给后端数据源（包括Sidecar对接的Prometheus）设置的请求超时阈值为10s。6h范围的90s分辨率查询，Prometheus的计算耗时通常在5s以内，完全在阈值内，能返回全量结果；当查询范围拉长到12h时，计算量线性翻倍，Prometheus的处理耗时会超过10s，Querier会主动断开后端连接，只接收到Prometheus已经返回的前半段计算结果，后半段未传输完成的数据会直接被丢弃，最终图表表现为后半段的数据点缺失。
• Prometheus单查询采样数上限截断
  多数生产环境的Prometheus实例会配置--query.max-samples参数，限制单请求可返回的最大样本数，避免大查询拖垮实例。90s分辨率下，12h查询的单序列样本数约为480个，如果你的监控序列基数较大，总样本数很容易超过该配置上限，Prometheus会直接截断返回结果。这种截断在Prometheus自身的Web端展示时，因为前端默认做了插值补点，不会明显感知到缺失，但Thanos会严格按照拿到的原始样本数渲染图表，就会出现明显的点缺失。
• 跨存储块的边界样本过滤
  Querier发起长范围查询时，会默认把总时间窗口拆成多个连续子块并行请求Sidecar。当12h的查询窗口刚好跨越Sidecar本地存储的时间块边界时，部分边界位置的样本会因为Sidecar的时间对齐逻辑被过滤。6h的查询因为全程处于同一个本地存储块内，不会触发跨块对齐，数据完全完整；12h的查询因为跨块，就会出现固定位置的数据缺失。

快速排查验证步骤 #

• 调大Querier的请求超时配置，将--query.timeout从默认值修改为60s，重新发起同条件的12h查询，观察缺失现象是否消失
• 直接通过Sidecar的暴露接口发起和Querier参数完全一致的12h查询，对比返回的样本总数，确认截断是发生在后端Prometheus层、Sidecar层还是Querier的传输层
• 检查Prometheus实例的--query.max-samples配置值，计算当前查询的总样本规模，确认是否触发了采样数上限

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