Thanos中正常运行的Prometheus查询在Grafana大时间范围下超时问题排查

一、为什么Grafana超时但Thanos正常？ #

两者的查询执行逻辑存在差异，导致大时间范围下表现不同：

• 步长（Step）差异：Grafana会根据面板时间范围自动计算$__interval作为查询步长，120天的范围可能被拆分出极多采样点，大幅增加计算和数据传输量；而Thanos UI/CLI默认使用更宽松的步长，计算量更小。
• 请求链路差异：Grafana的查询会经过数据源配置、面板前置处理等额外环节，若同一面板存在多个并发查询，会进一步挤占资源；Thanos单独执行单查询时资源更集中。
• 超时链路覆盖不全：即使调大了Grafana全局超时，若中间存在反向代理（如Nginx）或Thanos Query层的超时限制，仍会导致请求中断。

二、可调整的配置项 #

Grafana侧 #

• 调整Thanos数据源的Query timeout（需单独设置数据源级别的超时，而非仅Grafana全局超时），同时检查反向代理的超时参数（如Nginx的proxy_read_timeout），确保覆盖大查询的耗时。
• 在面板的「查询选项」中手动设置Min interval，针对120天范围可设为1h或更大值，强制减少采样点数量。
• 避免同一面板内同时运行多个大时间范围查询，降低并发压力。

Thanos侧 #

• 调整thanos-storegateway的--query.max-concurrent参数，增大并发处理能力，避免Grafana请求被限流。
• 若使用了thanos-query-frontend，开启查询缓存（通过--query-frontend.cache-config配置），让重复查询直接复用缓存结果，减少实时计算量。
• 检查thanos-storegateway的--block-size参数，更大的块大小能减少大时间范围下需要加载的块数量，降低对象存储IO压力。

三、查询语句简化优化 #

原查询存在重复聚合计算，可通过以下方式优化：

1. 简化实时查询逻辑 #

将重复的sum by(container)合并，改用avg_over_time直接计算可用性，减少一次聚合操作：

avg(
  100 * avg_over_time(
    (sum by(container)(kube_pod_container_status_running{namespace=~"keycloak|dev", container=~"keycloak|test-server|test-web"}) >= bool 1)[$__range:$__interval]
  )
)

2. 用Recording Rule预计算聚合指标 #

通过Thanos的规则记录功能，提前将sum by(container)的结果保存为新指标，彻底减少实时计算量：
首先定义Recording Rule：

groups:
- name: container_running_rules
  rules:
  - record: kube_pod_container_running_count
    expr: sum by(container, namespace)(kube_pod_container_status_running{namespace=~"keycloak|dev", container=~"keycloak|test-server|test-web"})

然后使用预计算指标查询：

avg(
  100 * avg_over_time(
    (kube_pod_container_running_count >= bool 1)[$__range:$__interval]
  )
)

四、额外排查点 #

• 查看Grafana日志（/var/log/grafana/grafana.log），确认超时发生在查询执行阶段还是数据渲染阶段。
• 在Thanos UI中执行查询时，记录返回的Step参数，在Grafana中手动设置相同步长，对比是否仍超时。
• 监控Thanos Store Gateway的指标（如thanos_storegateway_query_duration_seconds、thanos_storegateway_bucket_ops_total），定位大查询的耗时瓶颈（如对象存储IO、内存计算）。

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