Metric 收集：Prometheus + Grafana

Prometheus 是 pull-based 的 metric 收集系統——它主動去 scrape 各服務的 metric endpoint，不需要服務往外推資料。這個架構天然適合斷網：所有流量都在內網、不需要出站連線。

離線安裝

Prometheus 和 Grafana 都是單一二進位或容器映像，離線安裝跟映像搬運相同的流程：

1# 外部：下載 release binary
2wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
3wget https://dl.grafana.com/oss/release/grafana-11.1.0.linux-amd64.tar.gz
4
5# 搬運後解壓、設定 systemd service
6tar xzf prometheus-2.53.0.linux-amd64.tar.gz
7sudo mv prometheus-2.53.0.linux-amd64 /opt/prometheus

如果用容器部署，先把映像搬進內部 registry 再 pull：

1# 內部：從內部 registry 啟動
2docker run -d -p 9090:9090 \
3  -v /etc/prometheus:/etc/prometheus \
4  -v /data/prometheus:/prometheus \
5  registry.internal:5000/prometheus:v2.53.0

Scrape 設定

Prometheus 的 prometheus.yml 定義要 scrape 的目標。斷網環境通常用 static config（手動列出目標）而非 service discovery（需要雲端 API）：

 1scrape_configs:
 2  - job_name: 'node-exporter'
 3    static_configs:
 4      - targets:
 5          - 'server-01:9100'
 6          - 'server-02:9100'
 7          - 'db-01:9100'
 8
 9  - job_name: 'app'
10    static_configs:
11      - targets:
12          - 'app-01:8080'
13          - 'app-02:8080'
14    metrics_path: '/metrics'

新增機器時手動把它加進 targets 清單。如果用 Consul（內網 service discovery），Prometheus 支援 Consul SD、可以自動發現新服務。

Node Exporter

每台需要監控的 Linux 機器裝一個 node_exporter（單一二進位、無依賴），暴露 CPU、記憶體、磁碟、網路等系統 metric。離線安裝同理——下載 binary、搬運、解壓、設成 service。

1# 搬運後安裝
2tar xzf node_exporter-1.8.1.linux-amd64.tar.gz
3sudo cp node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/
4sudo useradd --no-create-home --shell /bin/false node_exporter
5# 建立 systemd service（略）

Log 收集：Loki 或 ELK

Grafana Loki（輕量）

Loki 是 Grafana 生態的 log 彙整系統，架構類似 Prometheus（pull/push 都支援），但儲存的是 log stream 而非 metric。它不索引 log 內容（只索引 label），所以儲存成本遠低於 Elasticsearch。

 1# loki-config.yaml 基本設定
 2auth_enabled: false
 3server:
 4  http_listen_port: 3100
 5storage_config:
 6  filesystem:
 7    directory: /data/loki/chunks
 8schema_config:
 9  configs:
10    - from: 2024-01-01
11      store: tsdb
12      object_store: filesystem
13      schema: v13
14      index:
15        prefix: index_
16        period: 24h

搭配 Promtail（log 收集 agent）在每台機器上收集 log 並推送到 Loki：

 1# promtail-config.yaml
 2clients:
 3  - url: http://loki.internal:3100/loki/api/v1/push
 4scrape_configs:
 5  - job_name: system
 6    static_configs:
 7      - targets: [localhost]
 8        labels:
 9          job: syslog
10          __path__: /var/log/*.log

ELK Stack（功能豐富）

Elasticsearch + Logstash + Kibana 是功能最完整的 log 平台，但資源消耗大（Elasticsearch 建議至少 4GB RAM 起跳）。適合需要全文搜索 log 內容的場景。

離線安裝：Elastic 提供離線安裝包（.deb / .rpm），或用 Docker 映像。三個組件都要搬運。

選型判準：5 台以下的小環境用 Loki（輕量、跟 Prometheus + Grafana 同一套 dashboard）。需要全文搜索、已有 ELK 經驗的團隊用 ELK。

告警：沒有外部 webhook 怎麼通知

連網環境的告警通常發到 Slack webhook、PagerDuty API、或 email relay service。斷網環境這些路徑都不通。

內部 SMTP

如果隔離網路內有 email server（很多企業內網有 Exchange 或 Postfix），Prometheus Alertmanager 可以發 email 告警：

 1# alertmanager.yml
 2route:
 3  receiver: 'email-team'
 4receivers:
 5  - name: 'email-team'
 6    email_configs:
 7      - to: 'oncall@internal.corp'
 8        from: 'alertmanager@internal.corp'
 9        smarthost: 'smtp.internal.corp:25'
10        require_tls: false

內部即時通訊

如果內網有 Mattermost（Slack 的 self-hosted 替代）或 Rocket.Chat，Alertmanager 可以用 webhook 發送到這些工具的 incoming webhook endpoint。

實體告警

極端情境（沒有 email、沒有 chat）：Alertmanager 把告警寫到檔案或資料庫、搭配值班制度定期查看。或用 Grafana 的 dashboard + 控制室大螢幕，值班人員直接看板。

告警的設計原則跟連網環境相同——symptom-based（錯誤率、延遲）優先於 cause-based（CPU、記憶體），閾值設計避免告警疲勞。差別在通知的到達速度可能慢一些（email 比 Slack push 慢），所以閾值要稍微保守（提早告警）。

Metric 與 Log 的儲存規劃

SaaS 監控的儲存是雲端自動擴展的。Self-hosted 的儲存要自己規劃——磁碟滿了 Prometheus 就停止收集、Loki 就停止寫入。

容量估算

Prometheus 的儲存量取決於 series 數量 × scrape 間隔 × 保留天數。粗估公式：

1每日儲存 ≈ active_series × sample_size(2B) × (86400 / scrape_interval) × compression_ratio(~0.1)

1 萬個 active series、15 秒 scrape interval、保留 30 天 ≈ 約 5GB。保留 90 天 ≈ 約 15GB。

Loki 的儲存量取決於 log 流量。粗估：每天 10GB 的 raw log 在 Loki 壓縮後約 1-2GB，保留 30 天 ≈ 30-60GB。

Retention 設定

1# prometheus.yml
2global:
3  scrape_interval: 15s
4storage:
5  tsdb:
6    retention.time: 30d
7    retention.size: 10GB  # 以先到的為準

超過容量時 Prometheus 自動刪除最舊的資料。設定 retention 前先確認磁碟空間足夠——斷網環境擴容磁碟的流程（採購 + 安裝）可能需要週到月級的時間。

NTP 時間同步

斷網環境容易被忽略的一個問題是時間同步。沒有 NTP server（pool.ntp.org）可連的機器，時鐘會漂移——幾天後各台機器的時間差可能達到秒級。當 Prometheus 收到的 metric timestamp 跟 Loki 收到的 log timestamp 有幾秒落差，事故排查時 metric 跟 log 對不上。

解法是在隔離網路內架一台 NTP server，所有機器從它同步：

1# 內部 NTP server（chrony）
2# /etc/chrony/chrony.conf
3local stratum 10         # 沒有外部來源時、自己當 stratum 10
4allow 10.0.0.0/16        # 允許內部網段同步
5
6# 其他機器指向內部 NTP
7server ntp.internal iburst

如果隔離網路的閘道可以開 NTP（UDP 123），讓閘道從外部 NTP 同步、內部機器從閘道同步，時間精度可以維持在毫秒級。

時程參考：Prometheus + Grafana + Alertmanager 的初次建置約需 1-2 天。Loki + Promtail 約需半天到一天。NTP server 約需 2 小時。後續維護主要是 Prometheus/Loki 版本更新的搬運（每次 1-2 小時）和儲存容量監控。

跨分類引用

• → 斷網環境的通用原則：監控工具的離線安裝走 content ferry 模式
• → 斷網環境的容器管理：Prometheus/Grafana/Loki 的容器映像搬運
• → 模組六：可觀測性與 log：連網環境的可觀測性 IaC
• → 無 SSH 環境的監控與告警：另一個極端——完全外部監控
• → Monitoring 04：Collector 架構與部署：SDK 和 Collector 的應用層監控，斷網環境需要把 Collector endpoint 指向 self-hosted backend
• → Monitoring 06：Self-hosted vs Commercial：斷網環境只能走 self-hosted 路線

本文是 Prometheus 的 vendor deep article，深化 overview「Cardinality 管理」跟「Memory pressure」段。初次接觸 Prometheus 的讀者建議先讀 Prometheus 服務頁。

定位

Prometheus 的容量模型跟傳統資料庫不同 — 它的容量邊界主要受 active series 數量（cardinality）跟 retention 期決定，而非資料筆數或 disk size。理解 Prometheus 的資源消耗模型，才能判斷什麼時候單機夠用、什麼時候需要 remote write 卸載或遷移到 Mimir / Thanos。

資源消耗模型

Memory：由 active series 決定

Prometheus 把近期的 time series 保存在記憶體（head block）。每個 active series 大約消耗 3-4 KB 記憶體（含 index、chunks、postings；Prometheus TSDB 的業界經驗值，實際依 label 長度與 chunk encoding 而定）。

這是 head block 的記憶體，不含 query execution 跟 WAL replay 的暫時開銷。Heavy PromQL query（大範圍 aggregation、多 series join）會額外消耗數 GB 的暫時記憶體。

判讀指標：prometheus_tsdb_head_series 代表當前 active series 數量，process_resident_memory_bytes 代表實際記憶體使用。兩者的比值偏離預期時（例如 50 萬 series 但記憶體用了 10 GB），可能是 query 記憶體壓力或 WAL corruption。

Disk：由 retention 期與 ingestion rate 決定

Prometheus 的 disk 消耗 = ingestion rate × retention 期 × 壓縮後每 sample 大小（約 1-2 bytes，Gorilla 壓縮算法下的業界經驗值）。

Disk I/O 的瓶頸通常在 compaction — Prometheus 定期把 head block 壓縮成 persistent block。Compaction 期間的 disk write 跟 CPU 使用會短暫上升。SSD 環境下 compaction 通常不是問題；HDD 環境下可能造成 scrape timeout。

CPU：由 scrape 數量與 query 負載決定

Scrape 本身的 CPU 消耗不高（HTTP GET + parse），但 scrape 數量 × scrape 間隔決定了基本的 CPU 基線。1000 個 target × 15 秒間隔 = 每秒 ~67 次 scrape，單核可以處理。

Query 是 CPU 的主要消耗者。Recording rule evaluation、alert rule evaluation、dashboard panel 查詢各自佔 CPU。Recording rule 數量增長到數百條時，evaluation 的 CPU 消耗可能成為瓶頸。

判讀指標：prometheus_rule_evaluation_duration_seconds 的 p99 超過 evaluation interval 時，rule 跑不完、alert 會延遲。

Cardinality 失控的判讀

Cardinality 是 Prometheus 最常見的容量問題。一個意外的高 cardinality label（user_id、request_id、完整 URL）可以在分鐘內把 series 數從 10 萬推到 100 萬、消耗數 GB 記憶體。

判讀訊號

• prometheus_tsdb_head_series 持續成長、斜率陡峭
• prometheus_tsdb_head_active_appenders 成長（新 series 的寫入速率）
• Prometheus 的 memory 持續上升、最終 OOM kill
• Query 延遲增加（更多 series 要掃描）
• Compaction 時間變長

定位方式

1# 找出哪個 metric name 的 series 最多
2topk(10, count by (__name__)({__name__=~".+"}))
3
4# 找出哪個 job（scrape target）的 series 最多
5topk(10, count by (job)({__name__=~".+"}))
6
7# 找出某個 metric 的哪個 label 組合在爆
8count by (method, status) (http_requests_total)

修復方向

• Label 白名單：在 scrape config 或 relabeling rule 中 drop 高 cardinality label
• Metric relabeling：metric_relabel_configs 在 scrape 後、寫入前移除特定 label
• Recording rule 替代：把高 cardinality metric 聚合成低 cardinality 的 recording rule，下游只讀 recording rule
• 移到 traces：user_id / request_id 這類維度放在 trace 的 span attribute 而非 metric label

常見故障模式

OOM Kill

觸發條件：active series 超過記憶體容量、或 heavy query 消耗大量暫時記憶體。

表現：Prometheus process 被 kernel OOM killer 終止。重啟後 WAL replay 可能需要分鐘到十分鐘（取決於 WAL 大小），期間 scrape 跟 query 都不可用。

預防：設定 memory limit alert（process_resident_memory_bytes / machine memory > 70%）、tracking cardinality growth slope、query timeout 限制。

Scrape timeout 連鎖

觸發條件：target 的 metrics endpoint 回應慢（> scrape_timeout）、或 target 數量超過 Prometheus 的並行 scrape 能力。

表現：up metric 為 0、scrape_duration_seconds 升高、dashboard 出現資料斷層（missing data points）。大量 target 同時 timeout 時，Prometheus 的 scrape goroutine pool 被佔滿，影響其他健康 target 的 scrape。

修復：調整 scrape_timeout（預設 10s，太短會造成 false timeout）、把慢 target 移到獨立的 scrape pool、或把 metrics endpoint 的回應最佳化（減少 expose 的 metric 數量）。

WAL corruption

觸發條件：Prometheus process 非正常終止（OOM kill、機器斷電）時，WAL 可能損壞。

表現：重啟後 WAL replay 失敗、Prometheus 無法啟動。Error log 顯示 WAL corrupted 或 invalid segment。

修復：刪除損壞的 WAL segment（丟失對應時間段的資料），重啟 Prometheus。嚴重時刪除整個 data 目錄重新開始（丟失所有歷史資料）。WAL 的持久性保證不如資料庫 — Prometheus 設計上允許短暫資料丟失，長期儲存靠 remote write 到 Mimir / Thanos。

Recording rule evaluation lag

觸發條件：recording rule 數量多且表達式複雜、evaluation 時間超過 evaluation interval。

表現：prometheus_rule_group_last_duration_seconds 超過 prometheus_rule_group_interval_seconds。Dashboard 讀 recording rule 的 panel 看到的資料落後當前時間。Alert rule 也在同一個 evaluation pipeline 裡，evaluation lag 會讓 alert 延遲觸發。

修復：把重的 recording rule 拆到獨立的 rule group（各自 evaluation interval）、最佳化 PromQL expression（減少 aggregation 層數、縮小 time range）、或把 recording rule 卸載到 Mimir（ruler component 獨立擴展）。

何時該從單機 Prometheus 遷出

遷出的第一步通常是加 remote write — Prometheus 繼續本地 scrape 跟短期查詢，長期資料寫到遠端。這是最低風險的演進路徑，不需要改 scrape config 或 PromQL。

下一步路由

• Prometheus 服務頁：overview 跟日常操作
• 4.7 cardinality：cardinality 治理的完整策略
• 4.2 metrics basics：recording rule 跟 rollup 的查詢面設計
• Grafana Stack：Mimir 作為 Prometheus 的長期儲存後端
• 4.23 觀測查詢設計：recording rule 在查詢設計中的定位

業務背景

Uber 的服務觀測涵蓋行程追蹤、即時定價、ETA 計算、司機定位、支付結算與推播通知。每個微服務都暴露 Prometheus-compatible metrics，隨著服務數量成長到數千個，寫入速率達到每秒數十億 data points。

早期每個團隊各自部署 Prometheus，各管自己的 retention、scrape config 與 alerting rules。規模小時這個模式運作良好 — 每個 Prometheus 實例只需要處理自己團隊的幾萬到幾十萬 series。但當組織成長到數百個團隊、數千個服務時，散落的 Prometheus 實例帶來三個問題。

技術挑戰

單機記憶體天花板

Prometheus 的 TSDB 把 active series 放在記憶體的 head block，每個 series 消耗約 3-4 KB（詳見 Prometheus 容量規劃）。當單一 Prometheus 實例需要 scrape 的 series 超過 1000 萬時，head block 就需要 40+ GB 記憶體。加上 query execution 跟 WAL replay 的暫時開銷，單機很容易 OOM。

團隊的第一反應是按服務拆分多個 Prometheus 實例，但這讓跨服務查詢變得困難 — 要看一條 request 從 gateway 到 payment 的 latency 分布，需要分別查三個 Prometheus 再手動關聯。

Retention 與長期趨勢

Prometheus 預設 retention 15 天。容量規劃與季度趨勢分析需要 90 天甚至 1 年的歷史資料。把 Prometheus retention 拉長到 90 天，disk 跟 memory 需求同步上升，而且 compaction 效率在資料量大時會下降。

團隊需要的是分層 retention — 近期資料保留全精度、歷史資料做 downsampling 後保留更久。Prometheus 原生不支援 downsampling。

高可用與跨叢集查詢

Prometheus 沒有原生 HA — 標準做法是跑兩個 instance scrape 同一批 target，靠下游去重。但兩個 instance 各自獨立儲存，查詢只打一個；instance 故障切換時會有短暫資料缺口。

跨叢集查詢更困難。Prometheus federation 可以做簡單的 metric 聚合，但 federation 本身是 pull-based scrape — federation target 太多或 series 太大時，federation Prometheus 自己也會 OOM。

解法：M3 平台

Uber 開發了 M3 — 一個 Prometheus-compatible 的分散式 metrics 平台，由三個核心元件組成。

M3DB：分散式 time series storage

M3DB 是分散式 TSDB，資料按 namespace 和 shard 分布在多個節點。每個 namespace 可以有不同的 retention 和 resolution — 例如 realtime namespace 保留 2 天全精度，aggregated_1m namespace 保留 90 天 1 分鐘精度。這解決了 retention tiering 的問題。

M3DB 的記憶體模型跟 Prometheus 不同 — 近期資料在記憶體，冷資料在 disk，不像 Prometheus 把所有 active series 都放 head block。這讓它能處理遠超單機 Prometheus 的 series 數量。

M3 Coordinator：統一查詢入口

M3 Coordinator 接收 PromQL 查詢，轉譯後分發到 M3DB 節點，聚合結果後返回。對 Grafana 和 alerting rules 來說，M3 Coordinator 的 API 跟 Prometheus 完全相容 — 不需要改 dashboard 或 alert config。

M3 Aggregator：寫入路徑聚合

高 cardinality 的原始 series 在寫入 M3DB 前先經過 M3 Aggregator 做 pre-aggregation — 例如把每秒的 request count 聚合成每分鐘，再寫入長期 namespace。這控制了長期儲存的資料量跟成本。

取捨

M3 的最大風險是社群活躍度 — Uber 自 2023 年後縮減了 M3 的開發投入，Grafana Mimir 成為更活躍的替代。新專案選型時，Mimir 跟 Thanos 的社群支援度跟 Grafana 生態整合度都優於 M3。M3 的價值在於它驗證了「分散式 TSDB + 寫入路徑聚合 + retention tiering」這組設計模式，這組模式在 Mimir 跟 Thanos 裡以不同形式被採用。

回寫教材的連結

• 4.2 Metrics Basics：active series、cardinality 與 recording rules 的基礎模型，M3 的 pre-aggregation 對應 recording rules 的平台化版本。
• 4.11 Telemetry Pipeline：M3 的 Aggregator 是 pipeline 中 processing 層的實例。
• Prometheus Remote Write 與長期儲存：M3 是 remote write 目標之一，跟 Mimir / Thanos / Cortex 的比較在該文。
• 4.7 Cardinality 治理：M3 的 per-namespace cardinality limit 是治理機制的生產實例。

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• 單一 Prometheus 實例 memory 接近機器上限，開始 OOM restart
• 多個 Prometheus 實例各自 scrape，跨服務查詢需要手動關聯
• Retention 15 天不夠做季度趨勢分析，但拉長 retention 資源撐不住
• 團隊開始問「我們的 metrics 總共有多少 series、誰佔最多」但沒有統一的 cardinality 觀測
• Grafana federation dashboard 查詢越來越慢或經常 timeout

引用源

• M3: Uber’s Open Source, Large-scale Metrics Platform for Prometheus

本文是 Prometheus 的 vendor deep article，深化 overview「PromQL 查詢」跟「Recording rules / Alerting rules」段。初次接觸 Prometheus 的讀者建議先讀 Prometheus 服務頁。

問題情境

Recording rules 把昂貴的即時聚合預先計算成低延遲 series，降低 dashboard 查詢成本並穩定 alerting 表達式。三個觸發點會讓團隊需要認真處理 PromQL 與 recording rules：

Grafana dashboard 的某些 panel 載入超過 10 秒。原因通常是 panel 直接查詢高 cardinality 的原始 metric，每次載入都做一次完整的 range query aggregation。Recording rules 預先計算聚合結果，dashboard 只讀計算好的 series，查詢時間從秒級降到毫秒級。

Alert 表達式想表達「最近 5 分鐘的 error rate 超過 1% 且持續 2 分鐘」，但寫出來的 PromQL 要麼漏抓（counter reset 時 rate 歸零）、要麼誤報（absent series 觸發 NaN 比較）。這類問題的根源是對 counter vs gauge 的語意差異理解不夠精確。

Recording rules 堆了上百條但沒有命名慣例，新加的 rule 不確定是否跟既有 rule 重疊、也不確定 evaluation 順序是否正確。缺乏結構化的 rule 管理會讓 rule group 的 evaluation 時間逐漸超過 interval。

核心概念

Counter 與 gauge 的查詢差異

Counter 是單調遞增的累計值（total requests、total bytes sent），只在 process 重啟時 reset。Gauge 是瞬時值（temperature、goroutine count、queue depth），隨時上下波動。

查詢 counter 必須用 rate() 或 increase() — 直接讀 counter 的原始值沒有業務意義（「從啟動到現在共 5 百萬個 request」不是有用訊號）。rate() 回傳每秒平均增量，increase() 回傳區間內的總增量。兩者都自動處理 counter reset — 當值突然下降時（process restart），rate 不會回傳負值。

查詢 gauge 直接讀原始值即可，用 avg_over_time()、max_over_time() 等做區間統計。

常見錯誤是對 gauge 用 rate（結果無意義 — 溫度的「每秒變化率」不是有用訊號）、或對 counter 直接取 max_over_time（只拿到 counter 的最大累計值、不是最大 QPS）。

rate 與 increase 的差異

rate(http_requests_total[5m]) 回傳 5 分鐘內的平均每秒 request 數。increase(http_requests_total[5m]) 回傳 5 分鐘內的總增量，等於 rate() * 300。

選擇取決於讀者的心智模型：SLI dashboard 用 rate（「每秒多少」直觀）；報表用 increase（「過去一小時多少筆」直觀）。

Range 的選擇有一個實務邊界：range 至少要涵蓋 2 個 scrape interval。15 秒 scrape interval 搭配 rate(...[30s]) 是最小可用 range；rate(...[15s]) 可能只抓到一個 sample，回傳 NaN。production 常用 [5m] 作為預設 range — 足夠平滑短暫抖動、又不會過度延遲異常偵測。

histogram_quantile 的 bucket 設計

Prometheus histogram 使用預定義 bucket 邊界收集觀測值分布。histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) 計算 p95 延遲。

Bucket 邊界的設計直接影響精確度。預設 bucket（0.005, 0.01, 0.025, … 10）適合 HTTP request 延遲場景。如果服務的 p50 在 200ms 而 bucket 只有 0.1 跟 0.25 兩個相鄰邊界，p50 的計算會在 100ms-250ms 之間做線性內插，精確度受限。

設計 bucket 的判準：p50 和 p99 附近各要有 2-3 個相鄰 bucket，讓內插結果接近真實值。SLO 的 latency threshold 也應該落在某個 bucket 邊界上 — 例如 SLO 是 p95 < 500ms，那 500ms 應該是一個 bucket 邊界。

每個 bucket 是一個 time series。10 個 bucket 的 histogram + 4 個 label 組合 = 40 個 series。Bucket 數量增加到 30 個時，同一個 metric 的 series 數量膨脹 3 倍。Bucket 設計要在精確度與 cardinality 之間取捨。

Label matching 規則

PromQL 的 binary operation（/、+、comparison）預設要求兩邊的 label set 完全一致才做 matching。這會在 error rate 計算時造成問題：rate(http_requests_total{status=~"5.."}[5m]) 的 label set 含 status、但 rate(http_requests_total[5m]) 的 total 不含 status。

解法是在分子做 aggregation 時 drop 掉 status label：

1sum by (job, method) (rate(http_requests_total{status=~"5.."}[5m]))
2/
3sum by (job, method) (rate(http_requests_total[5m]))

on() 和 ignoring() 修飾符可以在不做 aggregation 的前提下控制 matching，但可讀性較差。production 推薦的做法是先用 sum by() 控制輸出的 label set，讓兩邊的 label 對齊。

配置：常見 SLI Pattern

Error rate

 1# recording rule: 每 5 分鐘計算一次 error rate
 2groups:
 3  - name: sli_error_rate
 4    interval: 30s
 5    rules:
 6      - record: job:http_request_error_rate:ratio_rate5m
 7        expr: |
 8          sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
 9          /
10          sum by (job) (rate(http_requests_total[5m]))

命名慣例 level:metric:operations 來自 Prometheus 官方建議：job 是聚合的 level、http_request_error_rate 是語意、ratio_rate5m 是操作。遵循慣例讓團隊成員看到 rule 名稱就知道它的聚合粒度與計算方式。

Latency percentile

1      - record: job:http_request_duration_seconds:p95_rate5m
2        expr: |
3          histogram_quantile(0.95,
4            sum by (job, le) (rate(http_request_duration_seconds_bucket[5m]))
5          )

le label 是 histogram bucket 邊界，sum by (job, le) 把 instance 維度聚合掉、保留 bucket 結構。如果漏掉 le，histogram_quantile 會回傳錯誤結果。

Throughput

1      - record: job:http_requests:rate5m
2        expr: sum by (job) (rate(http_requests_total[5m]))

三個 SLI — error rate、latency、throughput — 組成服務的 RED metrics（Rate、Errors、Duration）。Recording rules 預先計算後，dashboard 只需讀三個 series。

Alerting rule 搭配 recording rule

1  - name: sli_alerts
2    rules:
3      - alert: HighErrorRate
4        expr: job:http_request_error_rate:ratio_rate5m > 0.01
5        for: 5m
6        labels:
7          severity: page
8        annotations:
9          summary: "{{ $labels.job }} error rate above 1% for 5 minutes"

Alert 表達式讀 recording rule 而非原始 metric。好處有二：alert evaluation 更快（讀預先計算的 series）、alert 表達式與 dashboard panel 使用同一組 recording rule（確保看到的數字一致）。

故障與邊界

Series churn 導致 absent() 判斷失準

absent(up{job="myapp"}) 用來偵測 target 完全消失（沒在 scrape）。但在 K8s 環境，pod 頻繁 rolling update 會造成 series churn — 舊 pod 的 series 消失、新 pod 的 series 出現。短暫的時間窗內 absent() 可能誤觸。

修法：用 absent_over_time(up{job="myapp"}[5m]) 替代，要求整個 5 分鐘區間都沒有 series 才觸發。或用 count(up{job="myapp"}) == 0 明確檢查 series 數量。

Recording rules circular dependency

Rule group A 的 rule 讀 rule group B 的 recording rule、group B 又讀 group A 的結果。Prometheus 按 group name 字母序 evaluate，circular dependency 會讓一方讀到上一輪的 stale 結果。

預防方式：recording rules 形成 DAG（有向無環圖）。Prometheus 文件建議把 rule 分成 aggregation 層級 — 底層 group 算 raw metric 的 aggregation、上層 group 算 recording rule 的 aggregation。同一個 group 內的 rule 按宣告順序同步 evaluate。

大 range query OOM

Dashboard panel 用 rate(metric[30d]) 查詢 30 天 range — Prometheus 要載入 30 天的 samples 到記憶體做計算。100 萬 series × 30 天 × 15 秒 interval ≈ 1.7 億 samples per series 是不可能完成的查詢。

修法：長時間 range 必須用 recording rules 做 step-down aggregation。先用 rate(...[5m]) recording rule 每 30 秒算一次、再用 avg_over_time(recording_rule[30d]) 查詢。Recording rule 的 series 數量通常比原始 metric 少一到兩個數量級。

Prometheus 2.x 支援 --query.max-samples flag 限制單一 query 能處理的 sample 數量（預設 5000 萬），超過就回傳 error。這是 OOM 的最後防線、不是常態。

Counter reset 導致 rate 異常

Process 重啟時 counter 歸零。rate() 和 increase() 自動偵測 counter reset 並補償，但有邊界條件：如果 scrape interval 內發生多次 restart（例如 crash loop），rate() 可能低估真實值（只能偵測到一次 reset）。

這種情境下的判讀：如果 rate() 的結果明顯低於預期、且同時段有 pod restart 紀錄，rate 低估是正常的。修法是解決 crash loop 本身、而非調整 PromQL。

容量與 Cost

Recording rules 的 CPU 成本 = rule 數量 × 每條 rule 的 evaluation 時間 × (1 / evaluation interval)。

表中的 evaluation 時間是 10 萬到 50 萬 active series 規模下的經驗值。Series 數量影響 evaluation 時間 — 100 萬 series 的 complex aggregation 可能 500ms+，跟表中假設偏差很大。用 prometheus_rule_group_last_duration_seconds 量測自己環境的實際值。

500 條 complex rule 搭配 15 秒 interval 會消耗超過 3 個 CPU core 在 rule evaluation 上。這時候的修法方向有三：

• 把 evaluation interval 放寬到 30s 或 60s（犧牲即時性）
• 把 rule 表達式最佳化（減少 aggregation 層數）
• 把 rule evaluation 卸載到 Mimir ruler（水平擴展）

Recording rules 產生的新 series 也會增加 cardinality。200 條 recording rule × 平均 5 個 label 組合 = 1000 個新 series，通常可接受。但如果 recording rule 沒做 aggregation 而是直接 alias（record: new_name expr: old_metric），cardinality 不會減少，只增加了寫入成本。

判讀指標：prometheus_rule_group_last_duration_seconds 跟 prometheus_rule_group_interval_seconds 的比值。前者超過後者時，evaluation 跑不完、dashboard 跟 alert 都會延遲。見 容量規劃與故障模式 的 Recording rule evaluation lag 段。

Recording rules 作為成本控制工具

觀測成本治理案例提出一個被低估的用法：recording rules 不只是加速查詢、也是控制 remote write 成本的手段。

模式是這樣的：application 暴露 200 個 label 組合的原始 metric（per-endpoint × per-status × per-region），recording rule 聚合成 5 個 label 組合（per-service × per-region）。如果 remote write 設定了 write_relabel_configs drop 掉原始 series、只 forward recording rule 產生的 aggregated series，remote write bandwidth 跟長期儲存的 cardinality 都大幅降低。

 1# Step 1: recording rule 做 aggregation
 2groups:
 3  - name: cost_optimized
 4    rules:
 5      - record: service_region:http_requests:rate5m
 6        expr: sum by (service, region) (rate(http_requests_total[5m]))
 7
 8# Step 2: remote write 只送 aggregated series
 9remote_write:
10  - url: "http://mimir:9009/api/v1/push"
11    write_relabel_configs:
12      - source_labels: [__name__]
13        regex: "service_region:.*"
14        action: keep

這個模式的取捨：長期儲存只有 aggregated 資料、無法回溯到原始 per-endpoint 維度。如果事故時需要 per-endpoint 的歷史資料，要麼保留原始 series 在本地 Prometheus（短期 retention）、要麼接受長期儲存只有 aggregated 粒度。

適用場景判斷：如果 dashboard 跟 alert 都只看 service-level 聚合、per-endpoint 維度只在即時除錯時才需要（Prometheus 本地 15 天 retention 夠用），這個模式的成本節省值得。如果有合規需求要 per-endpoint 歷史資料（例如 FinTech 案例 的 evidence chain），就不能 drop 原始 series。

Evaluation interval 對 CPU 的影響

Rule group 的 interval 決定 evaluation 頻率。同一組 rules 從 30s interval 改成 15s interval，CPU 消耗翻倍。從 30s 改成 60s，CPU 減半但 alert 跟 dashboard 的即時性下降。

經驗值：

15 秒 interval 的 rule group 要特別注意 evaluation 時間 — 如果 evaluation 本身花 12 秒，只剩 3 秒 buffer。prometheus_rule_group_last_duration_seconds 持續接近 prometheus_rule_group_interval_seconds 時，要麼拆 rule group 到不同 Prometheus instance、要麼放寬 interval。

整合與下一步

Alertmanager

Alert rule 寫在 Prometheus 的 rule_files 內、觸發後送到 Alertmanager。Alertmanager 負責去重、分組、抑制與路由（route to PagerDuty / Slack / email）。Alert rule 的表達式跟 recording rule 共用同一組語意 — 讀 recording rule 而非原始 metric。

Grafana dashboard

Grafana 的 Prometheus datasource 直接查 PromQL。Dashboard panel 推薦讀 recording rule series 而非寫 raw PromQL — 減少 dashboard 載入時間、確保 dashboard 跟 alert 看到的數字一致。

對齊 SLI/SLO

Recording rules 產生的 SLI metrics 是 4.6 SLI/SLO 訊號設計 的資料來源。SLO burn rate alert 也讀同一組 recording rule。確保 SLI recording rule 的 time window 跟 SLO window 對齊（例如 SLO 用 30 天 rolling window，recording rule 至少提供 5m 和 1h 兩個 aggregation 粒度給 burn rate 計算）。

交接路由

• Prometheus 服務頁：overview 跟日常操作入口
• 容量規劃與故障模式：recording rules 成長後的資源衝擊
• Remote Write 與長期儲存整合：recording rule 在 remote write 架構下的部署選擇
• 4.6 SLI/SLO 訊號設計：recording rules 如何餵給 SLO burn rate
• 4.7 Cardinality 治理：recording rules 作為 cardinality 減量手段
• 4.23 觀測查詢設計：recording rules 在 pre-aggregation 與 query tiering 中的定位

本文是跨 vendor migration playbook、cross-link Prometheus 跟 Grafana Stack（Grafana Cloud Metrics、Mimir-backed）。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High → Type C operational redesign hybrid。

Feature / ops / cost 三維對照

跑 6 維 diff dimension audit：

Operational = High → Type C standard。

為什麼遷：retention / ops / vendor consolidation 三條 driver

Operational redesign

Migration 4-phase

Phase 0：Audit

• 列所有 Prometheus job / scrape config
• 統計 active series 數（Mimir tier 計費基準）
• 估 retention 需求

Phase 1：Grafana Cloud setup

• Account + organization 設定
• API key for remote_write
• Grafana Cloud Mimir endpoint 啟用

Phase 2：Dual-write

 1# prometheus.yml
 2remote_write:
 3  - url: https://prometheus-prod-XX-prod-us-central-0.grafana.net/api/prom/push
 4    basic_auth:
 5      username: <INSTANCE_ID>
 6      password: <API_KEY>
 7    write_relabel_configs:
 8      # Optional: drop high-cardinality before sending
 9      - source_labels: [__name__]
10        regex: 'high_card_metric_.*'
11        action: drop

跑 4-8 週、確認 query 結果一致 + cost 在預期。

Phase 3：Cutover

• Dashboard / alert 切到 Grafana Cloud endpoint
• 應用層 / Grafana 自管 instance 關閉 query 對 self-managed Prometheus

Phase 4：Cleanup

• Self-managed Prometheus stop scrape
• 留 1-2 月歷史查詢能力（用 archive snapshot）
• Decommission

Production 故障演練

Case 1：Cardinality 爆、cost 暴漲

徵兆：dual-write 第 2 週 Grafana Cloud series 從預估 100K 漲到 800K、cost 翻 8 倍。

根因：application-level high-cardinality label（user_id / request_id）沒被 drop、scraped 進來。

修法：

1. write_relabel_configs drop unbounded label
2. Application metric 設計改 fixed-bucket histogram、不用 unbounded label
3. Mimir cardinality limit 設保護 + alert

Case 2：Recording rule 對應失效

徵兆：cutover 後 Grafana dashboard 某些 panel 顯示空；發現用了 Prometheus 端 recording rule (job:request_count:rate5m)、Grafana Cloud 端沒對應 rule。

根因：Prometheus 端 recording rule 是 server-side、不會跟著 remote_write 帶過去；Grafana Cloud 需要自己 setup recording rule。

修法：

1. Export 所有 recording rule、import 到 Grafana Cloud Mimir
2. 或改用 raw query + Grafana query template、不依賴 recording rule

Case 3：PromQL 微差行為

徵兆：某些 query 在 self-managed Prometheus 跑得好好的、切 Grafana Cloud Mimir 後 returns slightly different results。

根因：Mimir 對某些 edge case（empty result handling / staleness marker timing）行為跟 Prometheus 略不同；多數 query 一致、< 1% query 受影響。

修法：

1. Pre-cutover dual-query 驗證、用 critical dashboard 比對
2. Affected query 重寫、用更 robust PromQL pattern
3. 文件 known incompatibility list

Case 4：Alert routing 改變

徵兆：Cutover 後 PagerDuty / Slack 收不到 alert；發現 Alertmanager 端 webhook 沒切。

根因：alert 邏輯從 self-managed Alertmanager 搬到 Grafana Cloud Alerting、routing / contact 配置完全重做。

修法：

1. Pre-cutover 在 Grafana Cloud 端 rebuild alert + routing
2. 雙 alert pipeline 跑 1-2 週、確認 Grafana Cloud 收到
3. Cutover 切 routing、SOC drill 一次

Case 5：歷史資料查不到

徵兆：Cutover 後 SOC 想 query 6 個月前事件、Grafana Cloud 只有 2 個月（dual-write 後的）資料。

根因：Grafana Cloud 從 dual-write 開始才有資料、之前的 self-managed Prometheus historical data 沒 backfill。

修法：

1. Phase 2 期間用 promtool tsdb dump + mimirtool 把 self-managed historical 灌進 Mimir
2. 或保留 self-managed Prometheus read-only 6 個月（給 historical query）
3. Long-term：retention 從 cutover 開始算、historical 是 one-time backfill

Capacity / cost

整合 / 下一步

跟 Datadog → Grafana Stack migration 對位

兩條 Grafana Stack 路線：

• Self-host (Mimir + Loki + Tempo) on K8s：開源、自管
• Grafana Cloud：SaaS、operational simplification

本篇是「self-managed Prometheus → Grafana Cloud」、互補；如果跑兩階段（self-host → Cloud）跟「Datadog → Grafana Cloud」差不多。

跟 OpenTelemetry 整合

OTel Collector 可同時 ship 到 Mimir (metric) + Loki (log) + Tempo (trace)；Migration 順便升 OTel 化避免下次 vendor 切換重複。

相關連結

• Source vendor：Prometheus
• Target vendor：Grafana Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / Kafka → MSK / ELK → Elastic Cloud
• 平行 D-type 對位：Datadog → Grafana Stack
• Methodology：Migration playbook methodology

本文是 Prometheus 的 vendor deep article，深化 overview「Remote write / read」段。初次接觸 Prometheus 的讀者建議先讀 Prometheus 服務頁。

問題情境

Remote write 把 Prometheus 的 metrics 即時推送到外部長期儲存，解決單機 retention 上限與跨實例統一查詢的限制。三個觸發點會讓團隊需要 remote write 與長期儲存：

Prometheus 預設 retention 是 15 天。業務需要回顧 90 天的趨勢（容量規劃、季度 SLO 報告、成本歸因），本地 disk 不夠放。加大 disk 可以延長 retention，但 Prometheus 的查詢效能會隨資料量下降 — 本地 TSDB 不做 downsampling，查 90 天 range 的 query 要掃描全量 sample。

多個 Prometheus 實例分散在不同叢集（prod-us、prod-eu、staging），團隊需要一個統一查詢入口看跨叢集 metrics。每個 Prometheus 各自保存自己的資料，沒有跨實例查詢能力。手動切換 Grafana datasource 容易遺漏某個叢集的異常。

單機 Prometheus 是 SPOF — process crash 或 VM 故障時 metrics 完全不可用。跑兩個 Prometheus 各自 scrape 同一組 target 可以達到 HA，但兩份資料有微小差異（scrape 時間偏移），下游查詢需要 dedup。

Remote write 解決這三個問題：Prometheus 保持短期本地儲存（scrape + 即時查詢），同時把 metrics 串流到長期儲存後端。長期後端負責壓縮、downsampling、跨實例查詢與 HA dedup。

核心概念

Remote write protocol

Prometheus 透過 HTTP POST 把 time series 送到 remote write endpoint。每次 POST 包含一批 samples（protobuf 編碼、snappy 壓縮），由 Prometheus 的 WAL（write-ahead log）驅動 — WAL 記錄所有 scrape 到的 samples，remote write 從 WAL 讀取並串流到遠端。

這個設計意味著 remote write 是 best-effort 但有 buffer：如果遠端暫時不可達，samples 會堆在 WAL 裡等重試。WAL 的大小有上限（--storage.tsdb.wal-segment-size，預設 128 MB per segment），堆積太多會導致 WAL 佔用大量 disk。

Exemplar forwarding

Prometheus 2.26 開始支援 exemplar — 在 histogram 或 counter sample 上附加 trace_id / span_id。Remote write 也能把 exemplar 送到支援的後端（Mimir、Grafana Cloud、Tempo）。Exemplar 讓讀者從 metric anomaly 一鍵跳到對應的 trace，是 metrics-to-traces 橋接的關鍵能力。

啟用方式：scrape config 加 enable_features: [exemplar-storage]，remote write endpoint 支援 exemplar 即可自動 forward。

Dedup 策略

跑兩個 Prometheus HA pair 時，兩個實例都 scrape 同一組 target、都 remote write 到同一個後端。後端會收到兩份幾乎相同但不完全一致的 samples（scrape 時間差 ±1-2 秒）。

Thanos 和 Mimir 都有 dedup 機制：Thanos 在 query 層根據 external_labels（replica label）做 dedup，每個 time window 只取一個 replica 的值。Mimir 在 ingester 層做 dedup，同一個 series 的重複 sample 在寫入時合併。

Dedup 的前提是兩個 Prometheus 實例設定不同的 external_labels（例如 replica: a / replica: b），讓後端能辨別哪些 series 是同一組的不同副本。

配置

Remote write 基本設定

 1# prometheus.yml
 2remote_write:
 3  - url: "http://mimir-distributor:9009/api/v1/push"
 4    queue_config:
 5      capacity: 10000
 6      max_shards: 30
 7      max_samples_per_send: 5000
 8      batch_send_deadline: 5s
 9    write_relabel_configs:
10      - source_labels: [__name__]
11        regex: "go_.*"
12        action: drop

queue_config 控制 remote write 的並行度與批次大小：

• capacity：內存中暫存的 sample 數量。太小會頻繁 flush、太大會佔記憶體
• max_shards：並行的 write goroutine 數量。Shard 太少會造成 backlog、太多會壓垮遠端
• max_samples_per_send：每次 POST 的 sample 數量。5000 是常用值
• batch_send_deadline：即使 batch 沒滿也在這個時間內 flush，避免低流量時 sample 延遲太久

write_relabel_configs 在 remote write 前過濾 series — 不需要長期保存的 internal metrics（go runtime、scrape metadata）可以在這裡 drop，減少長期儲存的 cardinality 與成本。

External labels（HA 與多叢集）

1global:
2  external_labels:
3    cluster: prod-us
4    replica: a

cluster label 區分來源叢集，replica label 讓長期儲存做 dedup。每個 Prometheus 實例的 external_labels 必須唯一。

三家長期儲存比較

選擇判準依三個維度排序：

已經在用 Grafana 生態（Grafana dashboard、Loki、Tempo）：Mimir 是最自然的選擇，跟 Grafana Stack 的整合最深，Grafana Cloud 可以免管 Mimir。

需要最小化對 Prometheus 的改動：Thanos sidecar 模式不改 Prometheus 配置（sidecar 讀本地 TSDB block），適合「先加長期儲存、Prometheus 維持現狀」的漸進路徑。但 sidecar 綁 Prometheus pod，K8s 環境外的部署更複雜。

多租戶需求：Mimir 原生支援多租戶隔離（每個 tenant 獨立 TSDB、query isolation），Thanos 的多租戶靠 label 或獨立部署。

Cortex 是 Mimir 的前身，新部署不推薦。既有 Cortex 部署可參考 Grafana Labs 的 Mimir migration guide。

Uber M3 的第四條路

Uber M3 案例選擇了自建 M3DB 而非 Mimir / Thanos / Cortex — 原因是 M3DB 在 2018 年啟動時、Mimir 尚未存在、Cortex 還在早期階段、Thanos 也剛開源。M3DB 的設計核心是 namespace-level retention（不同 namespace 不同 retention 跟 resolution）、跟 Uber 的 etcd service discovery 深度整合。

M3 的經驗對後來的三家有直接影響：Mimir 的 per-tenant retention、Thanos 的 downsampling compactor、都能追溯到 M3 先踩過的問題。今天做新部署不需要重走 M3 的路 — Mimir 跟 Thanos 已經成熟。但 M3 案例揭露的設計判準仍然有效：

• 跨 cluster 查詢需要 fan-out + dedup：三家都實作了這個能力，但部署配置跟 dedup 策略各有差異
• Downsampling 是長期成本控制的必要手段：不做 downsampling、90 天 range query 的效能跟成本都不可接受
• 多租戶隔離不只是 query 層面：ingestion rate limit 跟 storage quota per tenant 才能防止「一個團隊的 cardinality 爆炸拖垮整個平台」

故障與邊界

Remote write backlog 佔滿 WAL

觸發條件：遠端不可達（network 問題、後端過載）持續超過數分鐘，WAL segment 堆積。

表現：prometheus_remote_storage_bytes_total 停止增長（寫不出去）、prometheus_wal_storage_size_bytes 持續增長、disk 使用率上升。嚴重時 WAL 佔滿 disk，Prometheus 無法寫入新 sample、連 local scrape 也受影響。

修復：先恢復遠端連線。WAL backlog 會在連線恢復後自動 catch up — Prometheus 按 WAL 順序重送積壓的 samples。如果 catch up 時間太長（例如堆了數小時），remote write 的 max_shards 可以暫時調高加速回補，但要注意不要壓垮剛恢復的遠端。

預防：監控 prometheus_remote_storage_queue_highest_sent_timestamp_seconds 跟 current time 的差距 — 差距代表 remote write 延遲。差距超過 5 分鐘時告警。設定 WAL 的 disk 空間上限（--storage.tsdb.max-block-duration 搭配 retention 控制 total disk）。

Target 不可達時的 retry storm

觸發條件：remote write endpoint 回傳 5xx 或 429（rate limit），Prometheus 進入指數退避重試。大量 shard 同時 retry，CPU 跟 network 消耗上升。

表現：prometheus_remote_storage_retried_samples_total 增長、CPU 使用上升、remote write 延遲拉大。如果後端本來就過載，retry storm 會讓情況惡化。

修復：remote write 配置中的 min_backoff / max_backoff 控制 retry 間隔（預設 30ms / 5s）。可以調高 min_backoff 減緩 retry 頻率。長期修法是讓後端回傳 429 搭配 Retry-After header，Prometheus 會遵守。

Metrics 語意 drift

觸發條件：多個 Prometheus 實例的 write_relabel_configs 不一致、或 external_labels 設定有誤。

表現：同一個 metric 在長期儲存中出現語意不同的 series — 有些 instance 保留了某個 label、有些 drop 掉了。Dashboard 查詢結果不一致（取決於查到哪個實例的 series）。

修復：remote write 的 write_relabel_configs 集中管理（配置模板或 Prometheus Operator 的 PrometheusSpec.remoteWrite）。每次修改 relabel 規則後，驗證所有實例的 series label set 一致。Mimir 的 active_series API 可以列出目前所有 active series 的 label set。

Remote write protocol 版本不匹配

觸發條件：Prometheus 版本跟長期儲存後端期望的 remote write protocol 版本不一致。Prometheus 2.x 使用 remote write v1（protobuf + snappy），部分較新後端開始支援 v2（native histogram 支援、metadata 改進）。

表現：後端回傳 400 Bad Request。Prometheus 對 4xx 的預設行為是不 retry（視為 client error、retry 無意義），samples 被 drop。prometheus_remote_storage_samples_failed_total 增長但不像 5xx 那樣有明顯的 retry storm — 靜默丟失更難察覺。

修復：確認 Prometheus 版本跟後端的 protocol 相容性。Mimir / Thanos 的文件通常標明支援的 remote write protocol 版本。版本不匹配時升級 Prometheus 或降級後端配置。

何時單機 Prometheus 不夠

三個訊號同時出現時，remote write + 長期儲存從「可選」變成「必要」：

Active series 超過 500 萬。單機 Prometheus 在 500 萬 series 左右開始出現記憶體壓力（head block ~20 GB）、WAL replay 時間拉長（重啟要數分鐘）、compaction 佔用 CPU。Uber 在 M3 專案遇到的正是這個天花板 — 數十個叢集各自 scrape 的 metrics 匯總後 series 數遠超單機能力，但「用更大的 VM 跑 Prometheus」不是解法，因為 Prometheus 的 TSDB 是單線程 compaction、垂直擴展的效益有上限。

Retention 需求超過 30 天。本地 TSDB 的 retention 拉長時，range query 的效能線性退化 — 查 90 天 range 要掃描的 block 數量是 15 天的 6 倍。Downsampling 是長期儲存後端的標準能力（Mimir / Thanos compactor 把 5 分鐘 resolution 降到 1 小時），但 Prometheus 本地 TSDB 不做 downsampling。Uber 的 M3DB 設計了 namespace-level retention（short-term 48h full resolution、long-term 1y downsampled），讓查詢成本不隨 retention 線性成長。

跨叢集統一查詢。多個 Prometheus 各自 scrape 不同 cluster 時，工程師需要一個入口看「所有 cluster 的 checkout error rate」。手動切 Grafana datasource 容易遺漏。Remote write 把所有 Prometheus 的 metrics 匯入同一個長期儲存、用單一查詢入口（Mimir querier / Thanos Query）做 fan-out。

這三個需求在中型公司（50-200 服務、3+ K8s cluster）通常在 1-2 年內同時浮現。規劃 remote write 時不用等三個都出現 — 任一個出現就是啟動的合理時機。

容量與 Cost

Remote write bandwidth

Remote write 的 bandwidth ≈ ingestion rate × 每 sample 壓縮後大小（約 1-2 bytes with snappy）。

每個 active series 在 15 秒 scrape interval 下每秒產生 ~0.067 個 sample。100 萬 active series 的 ingestion rate ≈ 6.7 萬 samples/sec，對應 ~70-140 KB/s remote write bandwidth。這個數字在內網環境下通常不是瓶頸。

真正的瓶頸在兩個地方：roundtrip latency 決定單 shard 吞吐上限（每次 POST 等回應才發下一批）、後端 ingestion capacity 決定能消化多少 samples/sec。Mimir 的 distributor 跟 ingester 可以水平擴展，但每加一個 ingester 增加 compute 成本。bandwidth 只是 capacity planning 的第一步，實際規模要用 Mimir 的 cortex_distributor_received_samples_total 跟 cortex_ingester_memory_series 做持續觀測。

長期儲存的 compaction 與 downsampling cost

Mimir 和 Thanos 的 compactor 定期合併 block 並做 downsampling（5m → 1h 粒度）。Compaction 消耗 CPU 和 disk I/O，但跑在長期儲存自己的 compute 上，不影響 Prometheus。

成本結構：

• Compute：distributor + ingester + querier + compactor 的 CPU / memory。Mimir 官方建議 ingester 是最吃資源的元件（記憶體中保存 active series）
• Object storage：S3 / GCS 的儲存量 ≈ ingestion rate × retention × 壓縮率。Compaction 跟 downsampling 會降低儲存量（通常 2-5x 壓縮）
• Query cost：長 range query 需要讀大量 block — 在 cloud object storage 上是 GET request 成本。Mimir 用 index cache（memcached）降低重複查詢的 GET request

跟 Prometheus 本地 TSDB 比，長期儲存把 disk cost 換成 object storage cost（通常更便宜），但增加了 compute cost（長期儲存的 ingester / querier / compactor）。判斷轉折點的方式是比較本地 SSD cost × retention 跟 object storage cost + compute cost。retention 超過 30 天時，object storage 的成本優勢通常明顯。

整合與下一步

接 Grafana Stack LGTM

Mimir 是 Grafana Stack LGTM（Loki + Grafana + Tempo + Mimir）的 metrics 後端。Prometheus remote write 到 Mimir 後，Grafana 用 Mimir 作為 Prometheus-compatible datasource，查詢語言仍是 PromQL。Exemplar forwarding 讓 Mimir metrics 可以連結到 Tempo traces。

接 Telemetry Pipeline

Remote write 在 4.11 telemetry pipeline 中扮演 metrics ingestion 段。如果同時使用 OpenTelemetry Collector，Collector 可以作為 remote write 的中繼（接收 Prometheus scrape → OTLP export → Mimir OTLP endpoint），但多一層中繼增加了 failure point。直接 Prometheus → Mimir remote write 是最簡路徑。

接 Cost Attribution

長期儲存的多租戶能力讓 4.15 cost attribution 可以按 tenant / team / service 拆分 metrics 成本。Mimir 的 per-tenant active series quota 同時控制 cardinality 與成本。

交接路由

• Prometheus 服務頁：overview 跟日常操作入口
• PromQL 與 Recording Rules 實務：remote write 架構下 recording rules 的部署位置選擇
• 容量規劃與故障模式：remote write 作為容量超限時的卸載路徑
• Grafana Stack：Mimir 作為長期儲存的完整操作指南
• 4.11 Telemetry Pipeline：remote write 在 pipeline 架構中的定位
• 4.15 Cost Attribution：多租戶 metrics 的成本拆分