業務背景

一家處理線上支付的金融科技公司，每日交易量約 200 萬筆，涵蓋信用卡收單、轉帳與退款。每季有外部稽核查核交易處理的完整性與存取控制，事故發生時法務需要在 48 小時內提供特定交易的完整處理鏈證據。

初期系統把所有 log 寫到同一個 log group — application debug、request trace、交易狀態變更與使用者存取紀錄全混在一起。稽核人員要從數 TB 的 log 中撈出特定交易的完整軌跡，每次查詢耗時數小時。

技術挑戰

Operational log 與 audit log 混合

Application log 記錄 debug 資訊（SQL timing、cache hit/miss、retry），audit log 記錄業務事件（交易建立、狀態變更、存取紀錄）。兩者混在同一個 pipeline 時，retention 策略互相衝突 — debug log 留 14 天夠用，但 audit log 法規要求保留 5 年。統一設成 5 年讓儲存成本暴增，統一設成 14 天則遺失合規證據。

PII 暴露在 log 中

早期 log 直接印出 request body，信用卡號跟身分證字號散落在各種 log entry。稽核指出 PII 在 log 系統中的暴露面超過業務需要，但 log 已經寫入後無法回溯修改。

Event correlation 斷裂

交易從建立到完成經過多個服務（checkout-api → payment-gateway → settlement → notification），但各服務的 log 使用不同的 correlation key。Checkout 用 order_id，payment-gateway 用 payment_ref，settlement 用自己的 batch_id。稽核要求「給我交易 X 的完整處理鏈」時，工程師需要手動在三個系統各自查詢再人工拼接。

解法

Audit log 分離

把 audit event 獨立到專屬 pipeline：交易狀態變更、使用者存取、權限變動、退款操作各自產生結構化 audit event，寫入 immutable storage（append-only、禁止刪除與修改）。Operational log 維持 14 天 retention，audit log 走 5 年 retention + cold archive。

分離的判準是「這筆紀錄是否可能被稽核或法務要求提供」。是 → audit pipeline；否 → operational pipeline。灰色地帶（例如認證失敗 log）歸入 audit pipeline — 寧可多留不可少留。

PII redaction pipeline

在 log ingestion 階段加入 redaction processor：信用卡號遮罩為末四碼、身分證字號完全移除、email 保留 domain 遮罩使用者名稱。Redaction 發生在寫入儲存之前，原始資料不落地。

需要完整 PII 的場景（如詐欺調查）走另一條授權存取管道，跟觀測 pipeline 分離。

統一 correlation key

所有服務在交易入口處產生 trace_id 和 transaction_id，兩個 key 同時寫入每一筆 audit event 和 operational log。稽核查詢用 transaction_id 就能撈出跨服務的完整處理鏈，不需要手動拼接。

取捨

分離 pipeline 的最大成本在 routing 規則的維護 — 新服務上線時要確認 audit event 走對 pipeline。解法是在 SDK 層提供 emit_audit_event() 函式，讓 routing 在 producer 端決定，不依賴下游 pipeline 的內容判斷。

回寫教材的連結

• 4.12 Audit Log Governance：audit log 分離的設計原則與 PII 治理。
• 4.20 Observability Evidence Package：把 audit trail 包成可交接的 evidence package。
• 4.18 Observability Operating Model：audit pipeline 的 ownership 歸 platform team 還是 compliance team。
• 4.3 Tracing Context：跨服務 correlation key 的 propagation 設計。

判讀徵兆

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

• 稽核或法務要求提供某筆交易的完整處理鏈，工程師需要超過 1 小時才能拼出來
• Log retention 設定跟法規要求不一致，但沒人確切知道差多少
• PII 出現在 log search 結果中，但沒有系統性的遮罩機制
• Application log 跟 audit log 用同一套 retention policy，儲存成本持續上升但沒人敢縮短
• 事故後法務要證據，發現關鍵時段的 log 已經因為 retention 過期而被刪除

業務背景

一個線上多人遊戲平台，日活躍使用者約 50 萬人。每逢賽季開跑或限時活動，同時在線人數在 30 分鐘內從平日基線暴增 8-10 倍，matchmaking 服務的 request rate 從 5k/s 衝到 50k/s，遊戲伺服器同時運行的 match instance 從數千增到數萬。

觀測系統在平日運作良好 — Prometheus 單機 scrape 500 萬 active series、Grafana dashboard 查詢秒級回應、告警在 1 分鐘內觸發。但每次活動開跑時，觀測系統本身開始劣化：dashboard 查詢從秒級變成分鐘級、告警延遲 5 分鐘以上才送到、部分 metric 直接消失。值班工程師在最需要觀測的時刻失去了可信訊號。

技術挑戰

Cardinality 爆炸

平日的 metric label 設計包含 match_id、player_id 跟 server_instance。平日 active series 約 500 萬，活動開跑後 match 跟 player 數量暴增，active series 在 30 分鐘內衝到 2000 萬。Prometheus 的 head block 記憶體從 20 GB 暴增到 80 GB，超過機器 64 GB 上限，觸發 OOM kill。

OOM 後 Prometheus 重啟需要 replay WAL，這段時間（5-15 分鐘）完全沒有 metric。活動最需要觀測的前 30 分鐘，觀測系統反而停擺。

Scrape freshness 延遲

即使 Prometheus 沒 OOM，大量 target 的 scrape 時間也會拉長。平日每輪 scrape 15 秒完成，活動期間拉長到 60-90 秒。Scrape interval 設定 30 秒時，下一輪 scrape 在上一輪還沒結束時就啟動，造成 sample 丟失跟時間錯位。Dashboard 上看到的數字可能延遲 2-3 分鐘，值班人員基於過期數據做判斷。

Alert 閾值失真

告警規則基於平日 baseline 設定 — 例如 error_rate > 1% 觸發。活動期間的 error rate 波動更大（matchmaking 短暫排隊造成的 timeout 增加是預期行為），平日閾值在活動期間持續觸發 false positive。值班人員開始 ignore alert，真正的問題（伺服器記憶體洩漏）被淹沒在噪音中。

解法

Cardinality guardrail

把高 cardinality label 從 real-time metric 移除。match_id 和 player_id 不再作為 Prometheus label，改為 log 和 trace 的欄位。Real-time metric 只保留 region、server_pool、game_mode 等低 cardinality 維度。

需要 per-match 或 per-player 分析時，走 log analytics pipeline（非 real-time，延遲 5-10 分鐘可接受）。這讓 Prometheus 的 active series 在活動期間從 2000 萬降到 800 萬，留在單機可承受範圍。

Pre-aggregation recording rules

為活動期間最常查的 pattern（per-region error rate、matchmaking queue depth、server utilization）建立 recording rules。Recording rules 在 Prometheus server 端預先計算，dashboard 查詢直接讀預計算結果，避免 heavy aggregation query 在活動期間拖慢 Prometheus。

1# recording rule 示例
2groups:
3  - name: peak_precompute
4    interval: 15s
5    rules:
6      - record: region:matchmaking_errors:rate5m
7        expr: sum(rate(matchmaking_errors_total[5m])) by (region)

Signal tiering

把觀測訊號分成兩層：

Tier 1 支撐告警跟即時 dashboard，保證活動期間不劣化。Tier 2 支撐事後分析跟 root cause investigation，接受延遲。

Dynamic alert threshold

活動期間啟用「高峰模式」alert profile — 調高 error rate 閾值（1% → 5%）、加長 for: duration（1m → 5m）、停用已知在活動期間會 false positive 的告警。高峰模式由活動排程系統自動觸發，活動結束後自動切回平日 profile。

取捨

分層治理的核心取捨是犧牲 per-match real-time debug 能力，換取觀測系統在高峰期間的穩定。這個取捨在活動場景成立 — 活動期間最需要的是「整體是否健康」的判斷，per-match debug 在事後分析夠用。

回寫教材的連結

• 4.7 Cardinality Cost Governance：cardinality guardrail 的設計原則與偵測機制。
• 4.17 Telemetry Data Quality：scrape freshness、sampling bias 與 signal tiering。
• 4.11 Telemetry Pipeline：real-time vs batch analytics pipeline 的分層設計。
• 4.4 Dashboard Alert：dynamic alert threshold 與高峰模式切換。

判讀徵兆

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

• 流量高峰期間 Prometheus 記憶體使用異常增長或觸發 OOM
• Dashboard 在尖峰時段查詢變慢或 timeout，正好是最需要看的時候
• Alert 在活動期間大量觸發但多數是 false positive，值班人員開始 ignore
• prometheus_tsdb_head_series 在特定時段突然暴增，結束後回落
• Metric label 中包含高 cardinality identifier（user_id、session_id、request_id）

業務背景

一個遠距醫療平台，服務多家醫療機構（multi-tenant），處理病歷查閱、處方開立、檢驗報告與預約排程。平台受 HIPAA 跟當地個資法規範，稽核單位要求能回答「哪個使用者在什麼時間查看了哪個病患的哪份紀錄」。

初期系統的存取紀錄散落在各服務的 application log 中 — 病歷服務記了一筆 GET /patient/123/records，處方服務記了一筆 POST /prescription，但兩者沒有共同的 correlation key。稽核問「護理師 A 在 3 月 15 日存取了哪些病歷」時，工程師需要在四個服務各自 grep，再用 timestamp 近似對齊，整個流程耗時半天且結果不可靠。

技術挑戰

存取 log 與 application log 混合

存取紀錄（誰看了什麼）跟 operational log（request timing、error、retry）寫在同一個 pipeline。Application log 的 retention 設定 30 天（除錯夠用），但法規要求存取紀錄保留 6 年。等到稽核來查詢時，超過 30 天的存取紀錄已經被刪。

跨服務存取鏈斷裂

一次病歷查閱可能經過 API gateway → auth service → patient service → record service → audit service 五個服務。每個服務各自記 log，但沒有統一的 access event correlation。Auth service 知道「誰」，patient service 知道「看了哪個病患」，record service 知道「看了哪份紀錄」— 三段資訊散落在三個服務的 log 中，無法自動關聯。

Multi-tenant retention 差異

不同醫療機構受不同法規管轄 — 機構 A 在美國需要 HIPAA 6 年 retention，機構 B 在歐盟需要 GDPR 的「目的限縮」原則（保留期限隨用途而定），機構 C 在台灣需要醫療法規定的 7 年。統一 retention policy 要嘛過度保留（增加成本與 PII 暴露面），要嘛保留不足（法規風險）。

解法

Data access audit log 獨立 pipeline

把存取事件從 application log 分離出來。每當使用者查閱、修改或匯出 PHI（Protected Health Information）時，產生結構化 access event：

 1{
 2  "event_type": "phi_access",
 3  "actor": "nurse-a@hospital-x.com",
 4  "patient_id": "P-2048",
 5  "resource": "medical_record/lab_result/2026-03-15",
 6  "action": "view",
 7  "trace_id": "abc123",
 8  "access_id": "acc-789",
 9  "tenant": "hospital-x",
10  "timestamp": "2026-03-15T14:22:05Z"
11}

Access event 寫入獨立的 immutable storage（append-only log），跟 application log 分開的 pipeline 與 retention。

Cross-service access chain

在 API gateway 入口產生 access_id，跟 trace_id 一起透過 context propagation 傳遞到所有下游服務。每個服務在產生 access event 時帶上這兩個 key。查詢時用 access_id 就能撈出一次存取操作在所有服務的完整軌跡，不需要手動拼接。

trace_id 用於關聯 operational 訊號（latency、error），access_id 用於關聯合規稽核。兩者可以相同也可以不同 — 關鍵是 access event 要同時帶兩個 key。

分層 retention 與 tenant-level policy

每個 tenant 在平台建立時設定法規要求的 retention 期限。Pipeline 根據 tenant tag 自動把 access event 路由到對應的 retention tier。Tenant A 的紀錄到第 6 年自動歸檔到 cold，tenant B 在 GDPR 目的屆滿時觸發刪除審核。

存取 log 中的 PII 處理

Access event 本身包含 patient_id 跟 actor，這些在存取紀錄中是必要資訊（「誰看了什麼」需要這兩個欄位）。處理方式是存取控制而非遮罩 — access event storage 的讀取權限限縮到 compliance team 跟 audit 角色，engineering team 的一般查詢權限無法看到這些欄位。

取捨

分層架構的最大風險是跨層查詢的延遲 — 稽核要求「給我 3 年前的存取紀錄」時，cold tier 的解凍時間可能是小時級。解法是在稽核週期前預先解凍相關 tenant 的 cold archive 到 warm tier。

回寫教材的連結

• 4.12 Audit Log Governance：audit log 分離與 PII 治理。
• 4.18 Observability Operating Model：access log pipeline 的 ownership 與 review cadence。
• 4.17 Telemetry Data Quality：timestamp integrity 跟跨服務時序校正。
• 4.3 Tracing Context：access_id 跟 trace_id 的 propagation 設計。

判讀徵兆

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

• 稽核問「使用者 X 在某段時間存取了什麼」，回答需要超過數小時的手動拼接
• 存取紀錄的 retention 跟法規要求不一致，但沒人確切量化差距
• Multi-tenant 環境中所有 tenant 共用同一個 retention policy，無法按法規區分
• 跨服務的存取事件無法自動關聯，需要靠 timestamp 近似比對
• PHI 相關的 log 跟一般 application log 存在同一個 storage，存取控制無法區隔

觀察

AWS 已明確提出 X-Ray SDK/Daemon 的維護時程，並提供遷移到 OpenTelemetry 的路徑。

判讀

當 observability agent 與 SDK 受限於單一供應商，轉向 OTel 可以降低未來轉移成本，但需要治理採集、匯出與語意對齊。

策略

1. 先盤點現有 instrumentation 與依賴 SDK。
2. 先換 collector/agent，再逐步改應用端 instrumentation。
3. 把 trace/metric 的等價驗證納入 release gate。

下一步路由

回 4.11 telemetry pipeline 與 4.17 telemetry data quality。

引用源

• X-Ray to OpenTelemetry migration guide

觀察

Google Cloud 在 Cloud Trace 提供 OTLP 支援，降低應用程式對特定傳輸介面的綁定。

判讀

當團隊要跨多環境與多工具，標準化傳輸協定能減少重複 instrumentation 與遷移摩擦。

策略

1. 將 collector 與 in-process exporter 對齊 OTLP。
2. 把 trace schema 與 sampling 規則集中治理。
3. 在遷移期保留舊通道與新通道比對。

下一步路由

回 4.11 telemetry pipeline 與 4.18 observability operating model。

引用源

• OTLP in Google Cloud Observability

觀察

AWS ADOT on EKS 的實務把 metrics、traces 採集策略整合到可管理的 collector pipeline。

判讀

多代理混用雖然能運作，但在規模化時會放大配置漂移與維運成本。

策略

1. 先統一 collector 部署模式。
2. 將 exporter 與 sampling 規則集中管理。
3. 以資料品質指標驗證遷移成效。

下一步路由

回 4.11 telemetry pipeline 與 4.18 observability operating model。

引用源

• AWS Distro for OpenTelemetry on EKS

觀察

Datadog 與 OTel 生態整合的做法，顯示團隊可在不一次重寫下逐步切換採集管線。

判讀

觀測遷移的主要風險是資料語意漂移與管線雙軌期成本，而非單一 agent 安裝。

策略

1. 先建立雙軌採集的對照驗證。
2. 把 schema 與 sampling 政策版本化。
3. 用品質指標決定何時關閉舊管線。

下一步路由

回 4.11 與 4.17。

引用源

• Datadog and OpenTelemetry

觀察

Airbnb 在 Kubernetes 規模化過程強調動態擴縮，代表觀測系統需要追上容量與拓撲變化。

判讀

若訊號模型無法反映動態叢集，告警與容量判讀容易失真。

策略

1. 將叢集層指標與服務層指標分開治理。
2. 在擴縮流程中保留關鍵健康訊號。
3. 用回溯報表驗證擴縮與事故關聯。

下一步路由

回 4.13 與 4.18。

引用源

• Dynamic Kubernetes Cluster Scaling at Airbnb

事故長相

OTel 切換後，儀表板看起來都有資料，但 on-call 開始收到不同告警，SLO burn rate 與舊系統長期對不上。同一個事故在新舊管線裡被歸到不同 service、不同 label 或不同 latency bucket。

為什麼會擴大

觀測資料是事故判讀的入口。若 metric 名稱、label、sampling、aggregation 不一致，團隊會對同一個現象做出不同判斷，甚至在錯誤訊號上回退服務。

回退判讀

觀測遷移的回退不一定是回到舊 agent。更重要的是保留新舊訊號對照，先停止讓新管線主導告警與 SLO 判定，再修正語意對齊。若直接關掉新管線，反而會失去分析漂移原因的證據。

觀測專屬告警條件

• 新舊管線對同一服務的 error rate 長期偏離
• missing span 或 missing metric 比例持續上升
• alert 噪音增加，但事故量沒有對應增加

下一步路由

回 4.17 與 4.11。

小型團隊常見判讀

小型團隊最怕雙軌過久。若同時維護兩套儀表，通常會先耗盡人力。小團隊更需要短期對照、快速收斂，而不是一次拉滿所有治理流程。

中型團隊常見判讀

中型團隊會碰到 schema 漂移與標籤膨脹。這個階段的失敗常見於「看得到數據，但看不懂是否同一語意」，導致告警與容量判讀彼此矛盾。

大型團隊常見判讀

大型團隊的觀測遷移會牽涉成本分攤、採樣策略、collector 拓撲。若只追求功能對齊，往往在遷移後才出現成本暴增與告警漂移。

這個情境的專屬告警條件

• 新舊管線 error rate 或 burn rate 偏差長期超標
• missing signal 比例持續上升
• 同一事件在兩套儀表板得到相反結論

觸發條件時應停止切換，先修資料語意與採樣策略，再決定是否繼續遷移。

判讀訊號

判讀重點是「兩套觀測是否仍在描述同一個系統狀態」。當 error rate、burn rate、trace coverage 三者任一長期偏離，就代表遷移證據不可信，應先停切換再修資料品質。

邊界判讀

這篇對照只處理觀測遷移的判讀邊界，不處理各 vendor 的實作細節。主要風險是把資料語意不一致當成短暫噪音，導致團隊在錯誤證據上推進切換。

下一步路由

先回到 4.17 Telemetry Data Quality 修正語意與採樣，再到 4.11 Telemetry Pipeline 校正雙軌管線。若已影響事故判讀，交接到 8.18 Incident Intake。

業務背景

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

業務背景

Cloudflare 的服務涵蓋 CDN、DNS、DDoS 防護、Workers 邊緣運算與 Zero Trust 安全。每秒處理數十億 HTTP request，分布在全球 300+ 資料中心。觀測資料量極大 — 僅 HTTP request log 每秒就產生數百 GB 未壓縮的結構化日誌。

早期觀測用單一 pipeline 處理所有資料，隨著資料量成長，pipeline 面臨三個壓力：monitoring 需要秒級即時性但不需要全量資料；analytics 需要完整資料但可以延遲分鐘級；forensics（鑑識）需要保留原始事件但查詢頻率極低。

技術挑戰

資料量與成本

每秒數十億 request 的全量日誌，即使壓縮後仍是 PB 級月儲存量。把全量資料送到集中式 log backend（無論是自建 Elasticsearch 或 SaaS Datadog）的 ingestion 成本本身就是天文數字。

Cloudflare 公開表示過去曾用過 Kafka + Elasticsearch + Grafana 的組合，但隨著 edge 節點增加，centralized ingestion 的頻寬跟儲存成本持續超線性成長。

Edge 到 Core 的延遲

觀測資料從 300+ edge 節點匯聚到中心叢集，網路延遲跟 bandwidth 是物理限制。monitoring 需要秒級判斷（alert 要快觸發），但全量日誌的傳輸延遲可能是分鐘級。

查詢模式衝突

on-call 值班需要的是 dashboard 上的 aggregated metrics（error rate、latency percentile、traffic volume），查詢要快、資料要即時。analytics 團隊需要的是全量日誌做 ad-hoc 查詢（某個 IP 在過去 24 小時的 request pattern），查詢可以慢、但資料要完整。forensics 需要的是單一事件的原始內容（某筆 request 的完整 header 跟 body），查詢極少但需要保留數月。

三種查詢模式在 resolution、freshness 跟 retention 上的需求完全不同，用同一套 backend 處理會讓所有人的體驗都變差。

解法：三層觀測能力

Monitoring：pre-aggregated metrics + alerting

edge 節點在本地做 pre-aggregation — 把每秒的 request count、error count、latency histogram 聚合成每 10 秒的 metric batch，push 到中心的 metrics backend。資料量從 PB/月壓縮到 TB/月。

Alerting 跟 dashboard 只看聚合後的 metrics，查詢延遲在毫秒級。metrics backend 用 Prometheus-compatible 儲存，Grafana 作為查詢入口。

Analytics：sampled + full-fidelity log pipeline

analytics 層接收全量日誌但做分層處理：高流量 endpoint 的日誌做 adaptive sampling（保留 1%-10%），低流量跟異常 request 保留全量。日誌送到自建的 columnar store（Cloudflare 用 ClickHouse 類的 OLAP 引擎），支援 ad-hoc 查詢。

Retention 30-90 天，查詢延遲在秒到分鐘級。成本比 monitoring 層高但仍可控 — sampling 是關鍵的成本旋鈕。

Forensics：原始事件歸檔

需要完整保留的事件（安全事件、DDoS 攻擊、客戶投訴關聯的 request）寫入冷儲存（object storage）。查詢走 batch 模式（scan-based），延遲在分鐘到小時級。

Retention 按合規需求保留 6 個月到數年。成本主要是儲存（object storage 便宜），ingestion 跟 query 成本極低。

取捨

三層拆分的最大風險是 debugging 路徑變長 — on-call 先看 dashboard 發現異常，再到 analytics 查 sampled log 找 pattern，最後到 forensics 查原始事件確認細節。如果三層之間的 correlation ID（trace ID、request ID）沒有對齊，跨層查詢會斷掉。

回寫教材的連結

• 4.1 Log Schema：三層共用的欄位設計（correlation ID、timestamp、service tag）是 log schema 的規模化實例。
• 4.3 Tracing Context：跨層 correlation 依賴 trace context propagation，edge → core 的 context 傳遞是挑戰。
• 4.11 Telemetry Pipeline：三層拆分就是 pipeline 的 routing 跟 processing 層設計。
• 4.15 Cost Attribution：三層各自的成本旋鈕（sampling rate、retention、storage tier）是成本歸因的實作入口。

判讀徵兆

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

• 觀測平台帳單主要被全量日誌 ingestion 佔據，但 90% 的日誌沒人查過
• Dashboard 查詢越來越慢，因為查詢打的是存了全量資料的同一個 backend
• on-call 跟 analytics 團隊對觀測 backend 的需求衝突（一個要快、一個要全）
• edge / CDN / 多 region 架構下，central pipeline 的 ingestion bandwidth 成為瓶頸
• 安全團隊要求保留原始事件 6 個月以上，但 hot tier 儲存成本撐不住

引用源

• Our Vision for Observability at Cloudflare
• Building Cloudflare on Cloudflare

業務背景

Discord 處理 trillions of messages。訊息是核心 user journey — 文字、圖片、附件、thread、搜尋全部依賴訊息儲存層。從 2015 年到 2023 年，Discord 的訊息儲存經歷三代架構。

每一代遷移都由 production 問題觸發 — 追查後發現儲存層已經撐不住，才啟動下一代架構。追查過程中反覆出現的盲區是：觀測訊號不夠早、不夠細或不夠可信。

技術挑戰

MongoDB 階段：latency tail 不可見

早期用 MongoDB 儲存訊息。隨著使用者成長，部分大型 server（Discord 的群組概念）的訊息量遠超平均值。這些 server 的查詢 latency 偶爾飆升到秒級，但 aggregated latency metric（p50、p95）看起來正常 — 因為大型 server 的 request 數量在整體中佔比極低。

缺少的訊號：per-server latency breakdown。aggregated metric 遮蔽了局部惡化。

Cassandra 階段：hot partition 沒有早期訊號

遷移到 Cassandra 後，partition key 設計（channel ID）讓某些高流量 channel 成為 hot partition。Cassandra 的 compaction 在 hot partition 上延遲，讀取 latency 上升。

問題由使用者回報「訊息載入很慢」才被發現，alert 沒有提前攔截。事後回看，Cassandra 的 read latency per partition 跟 compaction pending bytes per table 這兩個 metric 都有異常，但沒有人在 dashboard 上設 alert — 因為這兩個 metric 在 Cassandra 的預設 monitoring 裡不是 first-class 告警對象。

缺少的訊號：hot partition 識別跟 compaction health 的主動告警。

ScyllaDB 遷移階段：dual-read 沒有比對 metric

從 Cassandra 遷移到 ScyllaDB 的過程中，Discord 做了 dual-read（同時讀舊資料庫跟新資料庫、比對結果）。dual-read 的正確性比對有做，但 latency 跟 error rate 的比對 metric 設計不完整 — 知道結果一致，但不知道 ScyllaDB 在特定 query pattern 下是否比 Cassandra 慢。

遷移後才發現某些 query pattern 在 ScyllaDB 上的 tail latency 比 Cassandra 高，需要額外的 schema 調整。如果 dual-read 階段就有 per-query-pattern latency comparison metric，這個問題可以在 cutover 前發現。

缺少的訊號：migration 期間的 per-pattern latency comparison。

教訓

三次遷移暴露的觀測缺口有共同結構：

共同模式：觀測訊號的粒度不夠、或告警只設在 aggregated 層 — 局部惡化被平均值淹沒，直到使用者感受到影響才被發現。

三個缺口的修正方向也一致：

1. 把 entity-level metric（per-server、per-partition、per-query-pattern）從 debug-only 提升為 first-class 觀測訊號
2. 在 aggregated alert 之外加 percentile 跟 tail latency alert（p99.9 而非只看 p95）
3. Migration 期間把 latency comparison 做成 per-pattern 的 real-time dashboard，不只看 overall match rate

回寫教材的連結

• 4.17 Telemetry Data Quality：aggregated metric 遮蔽局部惡化是 data quality 問題 — 訊號存在但粒度不足以判讀。
• 4.18 Observability Operating Model：觀測缺口反覆出現代表 operating model 缺少「新服務上線 / 遷移時強制檢查觀測覆蓋」的 gate。
• 4.19 Debuggability by Design：per-entity latency breakdown 跟 migration comparison metric 應該在系統設計時就規劃，不是事故後補。

判讀徵兆

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

• 使用者回報問題但 dashboard 看起來正常 — aggregated metric 可能遮蔽局部惡化
• 資料庫或儲存層偶爾變慢但找不到原因 — 可能缺少 per-entity 或 per-partition metric
• Migration 做了 dual-read 但只比對正確性、沒比對 latency — 遷移後才發現效能回歸
• 告警設計只有 error rate 跟 aggregated latency — 缺少 tail latency 跟 entity-level alert

引用源

• How Discord Stores Billions of Messages（MongoDB → Cassandra 階段）
• How Discord Stores Trillions of Messages（Cassandra → ScyllaDB 階段）

業務背景

這個案例綜合三個組織的經驗模式：

一家中型 SaaS 公司用 Datadog 做全端觀測（APM + logs + metrics + RUM）。月帳單從 $15K 成長到 $60K，兩年內四倍。CFO 問 CTO「這筆錢買到什麼」，CTO 轉問 platform team，platform team 說不出哪些團隊佔多少。

一家金融科技公司自建 Grafana Stack（Prometheus + Loki + Tempo + Mimir）。自建沒有 SaaS 帳單，但 Kubernetes 節點跟 storage 的成本持續增加。infra team 知道 Mimir 的 storage 在成長，但不知道是哪些 metric label 造成的 cardinality 爆炸。

一家遊戲公司用 CloudWatch 做 AWS 原生觀測。Logs 的 ingestion 費用佔帳單 70%，但追查後發現 90% 是 debug-level log，只在排錯時用到，平常沒人查。

技術挑戰

沒有 cost attribution

觀測帳單通常是 organization-level 的一筆支出。SaaS 帳單按 hosts、custom metrics、log volume、APM spans 計費；自建平台按 compute 跟 storage 計費。兩種模式都缺少「這些費用是哪個 team / service 造成的」的歸因。

沒有 attribution 的後果是所有優化都是全域操作 — 砍 retention 從 30 天到 7 天影響所有人，降 sampling 從 100% 到 10% 影響所有服務。需要觀測資料的團隊被平均到成本節省裡，不需要的團隊搭便車。

Cardinality 爆炸

Metrics 成本的主要 driver 是 cardinality — unique label combination 的數量。常見的 cardinality 爆炸來源：

• 把 user ID 或 request ID 放進 metric label（每個 unique user 產生一組 series）
• 動態的 endpoint path（/api/users/123 每個 user ID 是一個 label value）
• 多租戶 label 過細（tenant × region × service × endpoint 的笛卡兒積）

一個失控的 label 可以讓 series 數量從 10 萬跳到 1000 萬。SaaS 的計費是 per custom metric，自建的代價是 Prometheus / Mimir 的 memory 跟 storage。

Log volume 失控

Debug-level log 在開發階段有用，但 production 環境裡通常只在排錯時被查。全量 debug log 送進 hot tier（Elasticsearch、Loki、CloudWatch Logs）的 ingestion 跟 storage 成本是最大的 log 成本來源。

問題是沒人敢降 debug log — 「萬一出事需要 debug log 怎麼辦」。恐懼驅動的 log level 設定讓 log volume 只升不降。

Trace sampling 恐懼

類似的恐懼存在於 trace sampling — 「如果剛好那筆有問題的 request 被 sample 掉怎麼辦」。100% tracing 的成本在中等規模（每秒數萬 request）就開始顯著。

解法

Cost attribution by team / service

第一步是讓成本可見，歸因先於優化。

SaaS 平台：用 Datadog 的 usage attribution 或 Grafana Cloud 的 usage reporting 把 ingestion 按 service tag / team tag 拆分。每個 team 看到自己的 metric series、log volume 跟 span 數量。

自建平台：在 Mimir / Loki 的 tenant 維度或 Prometheus 的 namespace 維度拆分 storage 跟 query cost。用 4.15 Cost Attribution 的框架把 infra cost 按 service ownership 分配。

Attribution 本身就能驅動行為改變 — 當團隊看到自己佔了 40% 的 log volume、而且 95% 是 debug level 時，他們會主動調 log level。

Cardinality budget per team

Attribution 之後，為每個 team / service 設定 cardinality budget（active series 上限）。超出 budget 的 series 進入 review 流程 — team 決定哪些 label 可以 aggregate 或移除，而非由 platform 單方面 drop。

Budget 的設定依據是 baseline measurement + growth rate，不是拍腦袋。先觀察 3 個月的 cardinality 趨勢，把 budget 設在 baseline 的 1.5 倍，每季 review。

Log tiering

把 log 從「全部進 hot tier」改成分層：

Debug log 仍然保留，但不進昂貴的 hot tier。需要排錯時從 cold archive 拉回 — 多等幾分鐘的代價遠低於全量 hot tier 的持續成本。

Adaptive sampling

Trace sampling 從 uniform 改成 adaptive：

• 錯誤 request 100% 保留
• 高 latency request（> p99）100% 保留
• 正常 request 依 traffic volume adaptive sampling（高流量 endpoint 低 sample rate、低流量 endpoint 高 sample rate）

Adaptive sampling 保留了排錯最需要的 trace（error 跟 outlier），砍的是正常 request 的重複 trace。

取捨

治理的最大風險是「砍過頭」— 在事故期間發現 debug log 被移到 cold archive 查不到、或 trace 被 sample 掉找不到問題 request。Adaptive sampling 跟 error retention 100% 是安全網，但安全網的設計本身需要定期 review（例如 error 的定義是否涵蓋了所有異常模式）。

回寫教材的連結

• 4.15 Cost Attribution：per-team cost visibility 是治理的起點。
• 4.7 Cardinality 治理：cardinality budget 跟 label review 的操作流程。
• 4.11 Telemetry Pipeline：log tiering 跟 adaptive sampling 是 pipeline 的 routing 跟 processing 層配置。

判讀徵兆

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

• 觀測帳單每季成長 > 20%，但服務的 request volume 成長遠小於此 — cardinality 或 log volume 可能在失控成長
• 管理層問「監控花多少錢、誰在用」但沒人能回答
• 曾經做過「全域降 retention」或「全域降 sampling」的成本優化，但幾個月後成本回升
• Platform team 花大量時間處理「Prometheus OOM」或「Elasticsearch disk full」而非改善觀測品質
• 團隊的 debug log level 在 production 預設開著，理由是「不知道什麼時候需要」