跳至主要内容

7 · 跨 IDC / 多雲 — 中央 Mimir 控制平面

邊緣叢集 remote_write → 一個中央 Mimir · 以 GCP 為例

寫入路徑寫入 · 寫出讀取路徑查詢 · 取得背景 · 儲存壓實 · rules · buckets虛線 = 流量 · 會流動 地端資料中心IDC · 邊緣叢集目標 pods / services抓取 /metricsGrafana Alloy HAagent mode · WAL · ≥2 副本Interconnect / VPNAWS · EKS 叢集×N 個邊緣叢集目標 pods / services抓取 /metricsGrafana Alloy HA每叢集 ×2 · WAL 在 EBS出口:Transit Gateway → VPN / InterconnectAZURE · AKS 叢集×N 個邊緣叢集目標 pods / services抓取 /metricsGrafana Alloy HA每叢集 ×2 · WAL 在 managed disk出口:ExpressRoute / VPNInterconnect / VPNremote_write · JWT/mTLS

邊緣站點​

地端資料中心​

IDC 內的邊緣/本地叢集。Alloy 在本地抓取目標 pods/services,經私有連線 remote_write 到中央 Mimir — 站內除了 WAL 緩衝外不存任何遙測。

  • Alloy HA:≥2 副本(agent mode,WAL 在持久儲存)
  • external_labels:cluster、site、region → 在查詢中識別來源
  • 連線:Dedicated Interconnect 或 IPsec VPN 到 GCP VPC
protocolremote_write HTTPS + JWT/mTLS → central distributor
tenancy每個站點或團隊一個 X-Scope-OrgID

AWS 邊緣叢集​

EKS 叢集跑同一套 Alloy HA 模式;每個叢集推送到中央控制平面,而不是各自跑 Mimir。

  • 每叢集 Alloy ≥2 副本 · WAL 在 EBS
  • HA 配對在中央 distributor 去重(HA tracker 依 cluster/replica labels)
  • 出口經 Transit Gateway → VPN/Interconnect 到 GCP
protocolremote_write HTTPS + JWT/mTLS
tenancy每個帳號/環境一個 tenant

Azure 邊緣叢集​

AKS 叢集 — 相同模式。單一中央查詢面意味著 Grafana 用一句 PromQL 就能看到地端、AWS 與 Azure 的 metrics。

  • 每叢集 Alloy ≥2 副本 · WAL 在 managed disk
  • ExpressRoute / VPN 到 GCP VPC
protocolremote_write HTTPS + JWT/mTLS

Alloy HA 模式​

每個邊緣站點至少跑兩個 Alloy 副本抓同一批目標,節點遺失也不會掉 metrics。

  • 兩個副本都送全部資料;中央 HA tracker 只留一份
  • Labels:cluster=<name>、replica=<a|b> 驅動去重
  • WAL 撐過連線中斷 — 重連後重放(數小時緩衝)
protocolprometheus.remote_write with queue + retry

目標 pods / services​

各站點被監控的工作負載。它們暴露 /metrics(或推 OTLP),從不直接跟中央 Mimir 對話 — 只有本地 Alloy 會。

  • Prometheus exporters、應用程式 /metrics 端點、kube-state-metrics
  • 由 Alloy 經 k8s API / 靜態設定探索
  • 工作負載不需出口 — Alloy 是唯一走 WAN 的
protocolscraped over HTTP inside the cluster

跨站點連線​

所有邊緣→中央的流量都是經私有連線、已驗證且加密的 remote_write。

  • HTTPS + JWT bearer token(每 tenant)或 mTLS 用戶端憑證
  • Interconnect / ExpressRoute / VPN — 不公開暴露 bucket 或 ingester
  • 帶寬 ≈ 活躍 series × 壓縮後 1–2 B/s — 相較原始 logs 很小
protocolremote_write /api/v1/push over Interconnect/VPN
GCP · 專用 VPC · GKE — 主要 MIMIR 控制平面WRITE PATH外部 HTTPS LBCloud Armor保護內部 Envoy proxyJWT 驗證tenant 斷言Distributor無狀態HA tracker 去重Kafka / Strimzi緩衝區域 NVMe SSDIngester有狀態 · WAL區域 PD寫入 → 驗證 · tenancy · 分片 → 依自身速度消費 → 每 2h 切 block → 上傳READ PATH內部 ingress僅 VPC 內Query frontend結果快取查詢切分查詢佇列 · scheduler每 tenant公平佇列Querier ×N拉取工作合併近期 + 歷史Store gateway歷史資料本機暫時 SSD讀取 · Grafana → 活躍資料 <12h (Ingester)歷史資料 · 本機暫時 SSD (Store gateway) ← 下載 blocksGoogle Cloud Storage — 唯一真實來源TSDB blocks · Standard → Nearline → ColdlineCompactorGCS 合併 · 去重 · 保留期

GCP 控制平面​

外部 HTTPS LB + Envoy​

單一強化的入口。Cloud Armor 在邊界過濾;Envoy 終止驗證,把寫入導到 distributors、讀取導到查詢路徑。

  • Cloud Armor:WAF + 站點出口 IP 白名單
  • Envoy 驗證 JWT/mTLS,注入/斷言 X-Scope-OrgID
  • 讀取走內部 ingress → query-frontend(僅 Grafana)
protocolin :443 · out distributor :8080 / query-frontend :8080

內部 Envoy proxy​

位於外部 LB 之後的寫入路徑:終止驗證,並在流量碰到 Mimir 之前把邊緣身分轉成 tenant 身分。

  • 逐站點驗證 JWT bearer token 或 mTLS 用戶端憑證
  • 斷言/注入 X-Scope-OrgID — 邊緣無法冒充其他 tenant
  • 在門口對行為不良的站點限速
protocolin ← HTTPS LB · out → distributor :8080

distributor(中央)​

接收所有站點 remote_write 的無狀態池。HA tracker 在任何資料落地前先對每個叢集的 Alloy HA 配對去重。

  • 全域規模的多租戶 ID 檢查 + 每 tenant 限制
  • HA tracker:每個 cluster label 選出一個副本,丟掉另一個
  • 隨所有站點的總寫入量自動擴展
protocolin /api/v1/push · out → Kafka / ingesters
tenancy每站點/團隊的 tenants 在此強制

Kafka / Strimzi 緩衝​

distributors 與 ingesters 之間可選的高吞吐緩衝:吸收多站點寫入尖峰,並把 ingester 重啟與寫入可用性解耦(Mimir 基於 Kafka 的寫入架構)。

  • Strimzi 營運的 Kafka 在 GKE · 區域 NVMe SSD
  • Ingesters 依自身速度消費 — 背壓而不丟資料
  • 重放視窗涵蓋 ingester 滾動/故障
protocolproduce ← distributor · consume → ingester

ingester(中央)​

GKE 上的有狀態池:區域持久磁碟放 WAL、zone-aware 複製,切出 TSDB blocks 並上傳到 GCS。

  • 區域 PD = 磁碟撐過 zone 故障
  • 向 queriers 提供「活躍資料」;每 2h 切 blocks → GCS
protocolgRPC in · blocks → GCS

compactor(中央)​

把所有 ingesters 的 2h blocks 合併成 GCS 中大型已去重的 blocks,並套用保留期。

  • 跑在 GKE,除暫存磁碟外無狀態
  • 全域去重 RF 複本 + HA 殘留
protocolreads/writes GCS

內部 ingress(讀取)​

讀取路徑只在 VPC 內:Grafana 經內部 ingress 到 query-frontend,永不經公網。

  • Grafana 資料來源 → 內部 ingress → query-frontend
  • 概念上對應原圖中的 HA tracker 註記
  • 公開 LB 只承載寫入
protocolinternal L7 → query-frontend :8080

query-frontend(中央)​

全公司唯一的查詢面:Grafana 問這個端點,就拿到所有 IDC 與雲端合併後的 metrics。

  • 快取 + 查詢切分 + 每 tenant 佇列
  • 僅內部 ingress — 不公開暴露
protocolPromQL /prometheus/api/v1/*

查詢佇列 / scheduler​

frontend 與 queriers 之間的概念性佇列(Mimir 中的 query-scheduler):queriers 拉工作,帶來每 tenant 公平性與無痛的 querier 自動擴展。

  • 每 tenant 公平排隊 — 一個團隊的重儀表板不會餓死其他人
  • 佇列深度是 queriers 的自動擴展訊號
protocolgRPC · queriers pull jobs

querier(中央)​

扇出到 ingesters(近期,所有站點在寫入時已合併)與 store-gateways(GCS 中的歷史 blocks)。

  • 跨站點查詢就是普通的 PromQL — 資料已同地存放
  • 儀表板密集的組織可擴展
protocolgRPC → ingesters + store-gateways

Ingester(讀取側)​

同一個有狀態 ingester 池,由 queriers 取用尚未壓實進 GCS blocks 的活躍資料(約最近 12h)。

  • 近期樣本從記憶體 TSDB head 回答
  • 更舊的區間改由 store-gateways 提供
protocolgRPC ← querier

store-gateway(中央)​

從 GCS 提供歷史 blocks;本機暫時 SSD 快取 index headers 與熱 chunks。

  • Block 下載快取在本機 SSD → 重複查詢更快
  • zone-aware block 分片
protocolreads GCS bucket

GCS — 唯一真實來源​

唯一的持久儲存。所有站點的 metrics 最終都以 TSDB blocks 形式落在這裡;其他一切都可重建。

  • 生命週期政策:blocks 隨年齡 Standard → Nearline → Coldline
  • 可選跨區域 bucket 作 DR
  • 同樣設計適用 S3(EKS 中央)或 Azure Blob(AKS 中央)
protocolGCS API (S3-compatible pattern)