Thanos Sidecar 必须与 Prometheus 共享同一 Pod 及挂载路径（如 /prometheus/data），通过本地文件系统读取 TSDB block；上传由 Prometheus block 关闭事件触发，非定时轮询；对象存储配置须通过 --objstore.config-file 指定 YAML 文件，不可硬编码；Compactor 仅压缩已上传至对象存储的 block，不替代 Sidecar 上传功能。
Thanos Sidecar 必须与 Prometheus 共享同一 Pod 或主机
Sidecar 无法远程读取 Prometheus 的 TSDB 数据，它依赖本地文件系统访问 /prometheus/data 目录下的 block 文件。如果部署在不同节点、或挂载路径不一致，上传会静默失败，thanos sidecar 日志里会出现 failed to read block meta.json 或 no blocks found。
常见错误现象：
- Prometheus 正常运行，但对象存储中始终无新 block 目录
-
thanos sidecar --tsdb.path指向错误路径（如漏掉/data后缀） - Prometheus 启动时未加
--web.enable-lifecycle，导致 Sidecar 无法触发 reload 获取最新 block
实操建议：
- 确认 Prometheus 容器挂载了
/prometheus/data卷，且 Sidecar 容器以相同路径挂载该卷 - Sidecar 启动命令必须显式指定
--tsdb.path /prometheus/data和--prometheus.url http://localhost:9090 - 确保 Prometheus 配置含
retention: 2d（或其他短期值），否则 Sidecar 不会上传已过期 block
对象存储配置必须用 YAML 文件传入，不能硬编码在命令行
thanos sidecar 不支持直接在命令行写 S3 凭据或 endpoint，所有对象存储参数必须通过 --objstore.config-file 指向一个 YAML 文件。硬编码会导致启动失败或凭据泄露风险。
正确配置示例（bucket_config.yaml）：
type: S3 config: bucket: "thanos-prod" endpoint: "s3.cn-north-1.amazonaws.com.cn" insecure: false signature_version2: false region: "cn-north-1" access_key: "AKIA..." secret_key: "..." # 国内云厂商注意：OSS/COS/MinIO 的 endpoint 格式差异大，务必匹配文档
关键点：
-
insecure: true仅限 MinIO 本地测试；生产环境必须为false，否则连接被拒绝 - 阿里云 OSS 要设
endpoint: oss-cn-hangzhou.aliyuncs.com，不能用https://oss-cn-hangzhou.aliyuncs.com - 腾讯云 COS 的
region必须小写（如ap-beijing），大写会导致认证失败
上传时机由 Prometheus block 切换触发，不是定时轮询
Sidecar 不会每 X 分钟扫描一次磁盘。它监听 Prometheus 的 TSDB block 关闭事件——即当 Prometheus 将当前 2 小时的内存数据 flush 成一个只读 block 并创建 meta.json 时，Sidecar 才开始上传。因此上传延迟取决于 Prometheus 的 min-block-duration（默认 2h）和实际 scrape 压力。
这意味着：
- 刚部署 Sidecar 后，不会立即上传历史数据；需等待下一个 block 生成（最长等 2 小时）
- 若 Prometheus
scrape_interval过长或 target 极少，block 生成变慢，上传延迟拉长 - 手动触发
curl -X POST http://localhost:9090/-/reload可强制 Prometheus 切换 block，加速首次上传验证
验证是否上传成功：
- 查 S3 桶，看是否有类似
01JXXXXXXX/的十六进制命名目录 - 查 Sidecar 日志关键词：
uploaded block、successfully synced - 不要依赖
thanos sidecar --log.level=debug，debug 日志量极大，容易掩盖关键错误
Compactor 是启用自动压缩和清理的前提，但不能替代 Sidecar 上传
很多人误以为配了 Compactor 就能“自动把老数据扔进 S3”，其实 Compactor 只处理**已经存在于对象存储中的 block**。它不做上传，只做三件事：合并小块、降采样（如 1m → 5m）、按 --retention.resolution-raw 删除过期数据。
所以如果你只部署了 Compactor，没配 Sidecar，对象存储永远是空的——Compactor 会报错 no blocks found in bucket。
必须顺序执行：
- 先确保 Sidecar 稳定上传（观察连续 3 个 block 出现在 S3）
- 再部署 Compactor，并严格对齐
--objstore.config-file路径和内容 - Compactor 启动后首次运行耗时较长（尤其首次全量扫描），期间不要重启
最容易被忽略的一点：Compactor 默认每 12 小时运行一次，但首次运行前不会自动创建任何降采样块。你得等至少 48 小时后，才能在 S3 中看到带 downsample_ 前缀的 block 目录。
