多集群可观测性联邦与聚合：联邦查询、数据分片与全局视图

困境一：N 个集群 N 套 Prometheus → 查询要切 N 次界面
困境二：告警规则复制 N 份 → 改一次要改 N 处，必然漂移
困境三：跨集群调用链断裂 → trace 在集群边界处"断头"
困境四：没有全局视图 → 无法回答"全球用户此刻体验如何"
困境五：成本失控 → 每集群长期存储，重复冗余

1. 全局可见：一条查询覆盖所有集群，统一 Dashboard 与 SLO
2. 故障隔离：单集群采集故障不影响其他集群与全局查询
3. 成本可控：长期存储集中化，冷热分层，降采样

选型原则：需要"下钻到单实例"就必须用远程写入方案，联邦只给聚合值

# 全局 Prometheus 的抓取配置
scrape_configs:
- job_name: federate
  honor_labels: true
  metrics_path: /federate
  params:
    match[]:
    - '{__name__=~"job:.*"}'                 # 预聚合的 recording rules
    - 'up{job="kubernetes-service-endpoints"}'
  static_configs:
  - targets:
    - prometheus-cluster-a:9090
    - prometheus-cluster-b:9090

原理：全局 Prometheus 通过 /federate 接口，从各集群拉取指定指标的"当前值"
要点：
  - match[] 决定拉什么，通常只拉 recording rules 的聚合结果
  - honor_labels: true 保留原始 label（否则冲突时会被覆盖）
  - 抓取间隔通常较长（1m），因为联邦是"二次采样"

局限一：只拉当前值，丢失历史精度（二次采样 → 精度下降）
局限二：不解决长期存储（全局 Prometheus 依然是本地磁盘）
局限三：拉取是集中式 → 全局实例成为瓶颈与单点
局限四：不适合明细指标 → 拉全量指标会打爆全局实例

适合：
  - 只需要全局聚合视图（如全局 RPS、全局错误率）
  - 集群数量少（< 10），指标量不大
  - 已有完善的 recording rules 预聚合
不适合：
  - 需要下钻到单 Pod 的历史数据
  - 需要长期存储与跨集群 trace 关联
结论：联邦是"轻量方案"，规模化生产应转向 Thanos/Mimir

Sidecar 模式：
  每个集群的 Prometheus 挂一个 thanos-sidecar
  → 上传 TSDB 块到对象存储（S3/MinIO）
  → 暴露 StoreAPI 供查询

核心组件：
  Sidecar     旁挂 Prometheus，上传块 + 提供 StoreAPI
  Store Gateway  读取对象存储中的历史块
  Querier     聚合查询多个 StoreAPI（含 Sidecar 与 Store Gateway）
  Compactor   降采样 + 压缩 + 保留策略
  Receiver    可选，支持远程写入（替代 Sidecar）

查询路径：
  Grafana → Thanos Querier
    → 各集群 Sidecar（近期数据）
    → Store Gateway（历史数据，对象存储）
  去重后返回统一结果

Mimir = 原生多租户、水平扩展的长期存储
  写入：Prometheus remote_write → Distributor → Ingester → 对象存储
  查询：Querier → Store Gateway（对象存储）+ Ingester（近期数据）

与 Thanos 的差异：
  - Mimir 是"重写版 Cortex"，微服务架构，天然水平扩展
  - Thanos 更"插件式"，可渐进式改造现有 Prometheus
  - Mimir 多租户隔离更强（tenant_id 贯穿）

全局查询：Querier 合并多个数据源，Grafana 只连一个地址
去重（Dedup）：HA 双写场景下，同一序列多副本只保留一份
部分响应：某集群不可达时，返回其余集群结果 + 警告，而非整体失败
跨集群聚合：sum by (service) 自然跨所有集群求和

场景：Prometheus HA 部署（两个副本同时抓取同一目标）
问题：不处理会导致所有指标翻倍

Thanos 方案：
  Querier 开启 --query.replica-label=replica
  同 series 同时间戳的多个副本 → 只保留一个
Mimir 方案：
  写入时按 tenant 去重，或依赖 HA tracker（接受一个副本）

前提：副本必须打上可区分的 label，如 replica="a" / replica="b"

按集群分片：每个集群一个 Prometheus / tenant
按租户分片：多业务共用平台，用 tenant_id 隔离
按时间分片：对象存储中按 2h 块组织（Thanos 默认）
按指标分片：超大规模下，同一集群内按 hash 分片抓取

目的：历史数据查询更快、存储更省
策略（Thanos 默认）：
  原始数据：保留 15 天（高精度）
  5 分钟降采样：保留 90 天
  1 小时降采样：保留 1 年以上

效果：查询一年前的趋势图，用 1h 粒度即可，无需扫描原始点
注意：降采样后无法再算精确的 P99 → 高精度聚合需在采集时用
      recording rules 预计算并长期保留

分层保留示例：
  热数据（本地 SSD）：15 天
  温数据（对象存储）：180 天
  冷数据（低频存储）：2 年

成本估算关注点：
  活跃序列数 × 采样点大小 × 保留时长
  降采样可把长期存储成本降低一个数量级

方案：各集群 Loki/ES 采集 → 中心查询层聚合
Loki 模式：
  各集群 Loki 独立存储，通过 Loki 的 "multi-cluster" 或
  Grafana 多数据源 + Correlations 联合查询
  或统一写入中心对象存储，Loki 查询层横向扩展

关键标签（跨集群必须一致）：
  cluster、region、env、service_name
否则无法跨集群聚合与下钻

挑战：trace 跨越多个集群时，span 分散在不同存储
方案一：统一 trace 后端（各集群 OTel Collector 统一导出到中心 Tempo）
方案二：按 trace_id 哈希分片到不同 Tempo 实例，查询层聚合
关键：trace_id 全局唯一，且采样决策一致（否则 trace 断头）

采样一致性坑：
  集群 A 采样、集群 B 未采样 → trace 在 B 处断裂
  对策：用统一的采样策略（如基于 trace_id 的一致性采样），
      由 Collector 的 tail_sampling 或统一的采样服务决策

跨集群聚合的前提是 label/属性命名一致：
  service.name、k8s.cluster.name、cloud.region
建议：把资源属性（resource attributes）在 Collector 层统一注入，
      不让应用各自命名，避免"cluster"与"cluster_name"并存

目标：全球用户视角的可用性，而非各集群分别达标
方法：先各集群算分子分母，再全局求和（不能先算比率再平均！）

错误做法：
  avg(cluster_a_availability, cluster_b_availability)  # 忽略流量权重

正确做法：
  sum(rate(http_requests_total{status!~"5.."}[5m]))
    / sum(rate(http_requests_total[5m]))

注意：跨集群聚合必须在"计数"层面做，比率类指标先还原成分子分母

层次一：集群内告警（本地自治，快速响应）
层次二：全局告警（全局 SLO 燃尽率、全局错误率）
层次三：联邦健康告警（某集群数据上报中断）

关键：告警规则集中定义（GitOps），但评估位置分散
     避免"全局评估单点"导致所有告警一起失效

多窗口多燃尽率（SRE 标准做法）：
  # 快速燃尽：1h 窗口消耗 2% 预算 → 紧急告警
  (
    sum(rate(errors_total[1h])) / sum(rate(requests_total[1h]))
  ) > (14.4 * (1 - 0.999))
  and
  (
    sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
  ) > (14.4 * (1 - 0.999))

好处：既快速发现严重故障，又不因短时抖动误报
跨集群版：把 sum 的范围扩展到所有集群的 remote 数据

问题：某集群上报中断，全局指标"看起来正常"（少了一个集群的坏数据）
对策：监控每个集群的上报心跳
  up{job="federate"} == 0
  count by (cluster) (up) < 期望集群数
告警：集群 X 数据上报中断，全局视图可能不完整

□ 明确目标：只需聚合视图用联邦，需下钻明细用远程写入方案
□ 联邦只拉预聚合的 recording rules，绝不拉原始指标
□ HA 部署必须配 replica label 并在查询层去重
□ 全局 SLO 在计数层聚合，绝不先算比率再平均
□ 用 recording rules 预计算关键聚合，长期保留高精度
□ 用降采样降低历史查询成本，与 recording rules 配合
□ 在 Collector 层统一注入 cluster/region/service 属性
□ 用全局一致性采样避免 trace 跨集群断头
□ 告警分层：集群内自治 + 全局 SLO + 联邦健康
□ 监控每个集群的上报心跳，检测数据缺口
□ 从单集群到多集群渐进演进，先聚合后明细

多集群可观测性 = 本地自治 + 全局查询层，
聚合在计数层、去重在查询层、降采样在存储层。