prometheus 多集群全局查询需统一 external_labels（如 cluster、replica）、sidecar 启用 grpc store api、query 配置去重与自动降采样、store gateway 对接对象存储。
要让 Prometheus 在云原生多集群场景下，通过 Thanos 实现高可用、无缝、无损的全局查询，核心不在 Prometheus 本身改配置，而在于统一数据标识 + 组件协同 + 查询层去重。关键不是“让 Prometheus 支持 Thanos”，而是让每个 Prometheus 实例在接入 Thanos 时，具备可识别、可聚合、可去重的语义能力。
确保每个 Prometheus 实例带唯一且一致的 external_labels
这是全局查询正确性的基石。不同集群、不同副本的 Prometheus 必须通过标签区分来源，又不能因标签冲突导致数据无法合并。
- 为每个集群分配唯一 cluster 标签（如
cluster: "prod-us-east"），不可重复 - 同一集群内多副本 Prometheus，必须使用相同
cluster，但需添加 replica 标签（如replica: "0"和replica: "1"）以支持自动去重 - 避免使用动态值（如 hostname、pod name）作为 external_labels，防止重启后标签漂移
- Sidecar 启动时会自动注入这些标签到 Prometheus 的元数据中，但前提是配置已写入
prometheus.yml的global.external_labels段
Sidecar 必须启用 gRPC 并暴露 Store API
Thanos Query 不直接连 Prometheus HTTP 接口，而是通过 gRPC 协议与 Sidecar 通信。未启用 Store API 将导致实时数据不可见。
- 启动 Prometheus 时，务必添加参数：
--web.enable-admin-api --web.enable-lifecycle（用于 Sidecar 管理 reload） - Sidecar 容器需监听
--grpc-address=:10901（默认端口），并挂载 Prometheus 数据目录和配置卷 - 验证方式：访问
http://<sidecar-ip>:10901/metrics</sidecar-ip>应返回指标；调用grpcurl -plaintext <sidecar-ip>:10901 list</sidecar-ip>应可见thanos.store.v1.Store服务 - 若跨集群通信，确保网络策略允许
10901端口的 gRPC 流量（非 HTTP）
Thanos Query 需启用去重与自动降采样
多副本采集带来的数据重复、时间偏移、小范围断连等问题，全靠 Query 层智能处理才能实现“无损”体验。
- 启动 Query 时必须指定
--query.replica-label=replica（匹配 Prometheus 的 replica 标签），否则无法去重 - 加上
--query.auto-downsampling，让 Query 在查大时间范围时自动切换到对象存储中的下采样数据，避免实时节点压力过大 - 多个集群的数据源，推荐用 DNS SRV 发现（如
--store=dns+dnssrv+_grpc._tcp.thanos-store.prod.svc.cluster.local），而非硬编码 IP，提升弹性 - 若存在部分集群临时离线，Query 默认会静默跳过——这本身就是“无缝”的体现；无需额外配置熔断或 fallback
Store Gateway 与对象存储联动保障长期一致性
仅靠 Sidecar 提供的实时数据（通常保留 2–6 小时）无法支撑“全局”和“无损”。历史数据必须由 Store Gateway 从对象存储（S3/MinIO/OSS）加载，并与实时数据自然拼接。
- 所有 Sidecar 必须配置相同的对象存储 endpoint 和 credentials，并启用
--objstore.config-file - Compactor 需定期运行，对上传的 block 做压缩、合并、下采样；否则 Store Gateway 查询性能会随时间劣化
- Store Gateway 启动后会自动发现所有已上传的 block，无需手动注册；它对外也提供标准 Store API，和 Sidecar 对等加入 Query 的 store 列表
- Query 对用户透明：查最近 1 小时走 Sidecar，查过去 30 天走 Store Gateway，中间无感知切换
