You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Thanos Compactor崩溃:块下载超时引发块重叠问题求助

Thanos Compactor崩溃后Azure Blob块重叠问题处理方案

问题概况

  • 环境版本:Thanos v0.27.0、Prometheus 2.25.2、Golang go1.15.10
  • 核心故障:Compactor运行一段时间因块下载上下文超时崩溃,重启后Azure Blob Storage出现块重叠,导致压缩进程停滞;手动删除重叠块后问题反复出现
  • 已排查点:移除Sidecar的--shipper.upload-compacted参数后仍有块重叠,排除该参数影响
  • 日志细节:冲突块中Compactor生成的块上传时间早于Sidecar上传的块

排查与解决步骤

1. 先解决下载超时的根源问题

下载超时是触发后续块重叠的起点,先调整相关配置:

  • 调大Compactor的--store.download.timeout参数,默认5分钟,可根据Azure网络延迟情况改为10分钟或更久
  • 检查Azure Blob Storage的网络链路,确认是否存在间歇性丢包、带宽不足,必要时升级存储账户的网络性能等级

2. 阻断块重叠的生成路径

块重叠是因为Compactor崩溃后,Sidecar仍在上传同时间范围的块,和Compactor之前生成的块冲突:

  • 给Compactor加上--wait参数,确保进程关闭时能完成当前压缩任务,避免残留半处理的块
  • 配置Sidecar的--shipper.ignore-blocks-with-time-range参数,根据Compactor的压缩周期,过滤掉已经被Compactor处理过的时间范围块,防止重复上传
  • 调整Prometheus的storage.tsdb.retention.time,避免过久的原始块未被Compactor处理,减少Sidecar上传与Compactor块的时间范围重叠概率

3. 自动化清理重叠块

手动清理太麻烦,写个脚本自动化处理:

  • 遍历Azure Blob中的所有块,对比块的时间范围和生成来源,业务上优先保留Compactor生成的压缩块(效率更高),删除重复的Sidecar原始块
  • 把清理脚本做成定时任务,定期执行,避免重叠块堆积卡死Compactor

内容的提问来源于stack exchange,提问作者crock

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.25 07:06:33