• structured log schema
• correlation id / request id fields
• index 與 retention
• query pattern

概念定位

log schema 是把事件紀錄從文字輸出變成可查詢資料的契約，責任是讓不同服務在事故時能用同一組欄位還原脈絡。

這一頁處理的是欄位與搜尋路徑。log 的價值在於事故時能用穩定欄位找到同一個 request、同一個 tenant、同一個 dependency call 與同一段錯誤鏈，寫得多本身沒有幫助。

核心判讀

判讀 log schema 時，先看 correlation fields 是否穩定，再看 search index 與 retention 是否對齊查詢需求。

重點訊號包括：

• request id、trace id、tenant boundary 與 service name 是否跨服務一致
• high-cardinality 欄位是否被放進可控索引，並受查詢價值與成本預算約束
• retention 是否依 operational debug、audit、compliance 分層
• query pattern 是否能支援 incident timeline 還原

判讀訊號

• log 欄位 schema 漂移、跨服務 correlation id 對不上
• 事故時靠 grep 拼湊事件、無結構化查詢入口
• log 索引爆量、查詢退化但無清理流程
• log 含大量 free-form text、無一致關鍵欄位
• retention 策略全平、舊事件查不到 / 不該留的還在留

查詢模式設計

Log 的寫入格式跟讀取需求是兩個不同的設計問題。寫入追求 schema 穩定與吞吐效率；讀取要在不同時間壓力下，用不同的查詢形狀取回不同精度的資料。同一份 structured log 至少被三種查詢模式讀取，每種模式對索引、延遲與結果形狀的要求不同。

即席診斷查詢

事故中的查詢要在秒級內定位問題。典型操作是拿到一個 request id 或 error code，加上 time window，撈出相關事件鏈。

即席查詢的索引策略是把高頻過濾欄位放進結構化索引：service name、log level、error code、request id、trace id、tenant boundary。這些欄位的共同特徵是有界或半有界（error code 有限、request id 雖然無界但查詢時一定帶精確值），查詢時用等值匹配或短範圍掃描。

即席查詢的反模式是對 free-text 欄位做全文搜尋當作主要診斷入口。全文搜尋適合探索性調查（「最近有沒有出現某個未預期的 exception message」），但事故中的時間壓力下，結構化欄位的精確查詢比全文搜尋快一到兩個數量級。

聚合趨勢查詢

Dashboard 跟告警的查詢是定期的聚合計算：過去 5 分鐘的 error count by service、過去 1 小時的 log volume by level、某個 tenant 的 warning 趨勢。這類查詢不需要看單筆 log 的內容，而是需要 count / rate / group by 的聚合結果。

聚合查詢的負載特性跟即席查詢不同。即席查詢讀少量資料、要求低延遲；聚合查詢掃大量資料、容忍較高延遲但執行頻率高（dashboard 每 30 秒刷新一次 = 每分鐘 2 次相同的重聚合）。當 log volume 成長，重複計算聚合的成本會推高 query engine 負擔。

應對策略有兩種。一是在 log pipeline 把常用聚合轉成 metrics — collector 端做 log-to-metric 轉換（例：把 level=error 的 log 計數轉成 error_log_total counter），dashboard 讀 metric 而非重掃 log。二是在查詢層設定 materialized view 或快取，讓重複查詢直接取用預計算結果。

鑑識回溯查詢

事後分析與合規稽核的查詢範圍大（跨天、跨週甚至跨月）、對完整性要求高、但延遲容忍也高（分鐘級回應可接受）。鑑識查詢常見的形狀是「某個 tenant 在過去 30 天內所有 authentication failure」或「某個 API 的 error 分布演變」。

鑑識查詢的儲存設計跟 storage tiering 直接相關。Hot tier 保留最近數天的 full-index log，warm tier 保留數週的部分索引或壓縮 log，cold tier 保留數月到數年的歸檔 log。鑑識查詢命中 cold tier 時，系統可能需要 rehydrate（把歸檔資料暫時載回可查詢狀態），這個操作本身需要時間和臨時儲存空間。

鑑識場景的關鍵設計決策是「哪些欄位在 cold tier 仍可查詢」。全部欄位都保留索引成本太高；只保留 timestamp + service name + tenant 的最小索引，能支援基本的範圍掃描，細節再用 rehydrate 後的全文搜尋補。

三種模式的資源隔離

三種查詢模式搶同一個 query engine 時，聚合查詢的持續負載會擠壓即席查詢的回應速度。事故中團隊最需要即席查詢的低延遲，但此時 dashboard 也在高頻刷新聚合查詢，兩者競爭 query 資源。

可操作的隔離方式是讓即席查詢跟聚合查詢走不同的 query priority 或 query queue。Elasticsearch 的 search thread pool、Loki 的 query-frontend queue、Datadog 的 query quota 都提供某種程度的查詢隔離。設計時要把即席查詢的延遲 SLA 當作硬性約束，聚合查詢的延遲可以被彈性排程。

交接路由

• 04.7 metric cardinality / cost：label 預算與保留階梯
• 04.8 訊號治理閉環：log-based alert 的生命週期
• 04.12 audit log：稽核訊號跟 operational log 的邊界
• 04.23 觀測查詢設計：跨訊號類型的讀取路徑系統設計

• metrics 基本型別
• latency histogram
• error rate / throughput
• SLI / SLO / error budget

概念定位

metrics 是把服務狀態壓縮成可聚合、可比較、可告警的時間序列，責任是讓團隊看見趨勢、容量與服務健康。

這一頁處理的是 metric 型別與計算語意。counter、gauge 與 histogram 各自回答不同問題；選錯型別會讓後面的 SLI、dashboard 與 alert 都建立在錯誤訊號上。

核心判讀

判讀 metrics 時，先看指標型別是否對應問題，再看分母、bucket 與 label 是否穩定。

重點訊號包括：

• latency 是否用 percentile / histogram 補足 average 的盲點
• error rate 的分母是否能代表真實請求量
• bucket 是否覆蓋實際尾端延遲
• label 是否能切出必要維度，同時不讓 metric cardinality 失控

判讀訊號

• 用 average 而非 percentile 追 latency、p99 失真
• counter / gauge 混用、計算公式錯
• histogram bucket 沒對齊實際分佈、tail latency 被截斷
• error rate 分母不穩（流量低時誤觸發、高時稀釋）
• 商業 SLI 跟 metric 對不上、靠人解釋

聚合查詢與 recording rule

Metrics 的讀取面跟寫入面是兩個不同的效能瓶頸。寫入面的壓力來自 series 數量（cardinality）；讀取面的壓力來自查詢時的聚合計算量。兩者可以獨立失控 — series 數量合理但每次 dashboard 刷新都重算複雜表達式，query engine 一樣會過載。

Query-time aggregation 的成本

Dashboard panel 或 alert rule 每次觸發時，TSDB 對 raw series 執行聚合表達式（rate、sum、histogram_quantile）。當 raw series 數量大、查詢時間範圍長、dashboard 刷新頻率高，同一個計算會被反覆執行。

一個典型的 SLO burn rate panel 可能涉及：先算 rate、再除以 total、再跟 threshold 比較、最後乘以 window。每次刷新把整條運算鏈走一遍。當這類 panel 有十幾個、每 30 秒刷新一次，query engine 的 CPU 會被 dashboard 佔滿，留給事故即席查詢的餘量不夠。

Recording rule 把計算推到寫入時

Recording rule 是 Prometheus 生態（包括 Thanos、Mimir、VictoriaMetrics）的標準應對方式：在 TSDB 內定期執行聚合表達式，把結果寫成新的 time series。Dashboard 跟 alert rule 讀 recording rule 的輸出而非重算 raw series。

Recording rule 的設計判準是查詢頻率跟計算成本的乘積。高頻讀取（dashboard auto-refresh、每分鐘 evaluate 的 alert rule）加上高計算成本（多維度 rate + ratio + quantile）的組合最值得做 recording rule。低頻即席查詢（事故時的 ad-hoc 切片）直接查 raw series，保留完整維度。

Recording rule 的命名慣例用 level:metric:operations 格式（如 job:http_requests_total:rate5m），讓讀者從名稱直接判斷來源粒度跟計算方式。沒有命名慣例時，recording rule 增長到數百條後會難以維護跟除錯。

Rollup 與 downsampling

Rollup 解決的是時間維度的讀取成本。原始資料以 15 秒間隔採集，查詢「過去 90 天的 error rate 趨勢」時需要掃描數百萬個資料點；rollup 把舊資料聚合成 5 分鐘或 1 小時粒度，查詢時只讀取聚合後的少量資料點。

Rollup 的聚合函數選擇影響查詢語意。Counter 用 sum 合理、gauge 用 average 合理、histogram 用 average 會失去分布資訊（p99 被壓平）。設計 rollup 時要按 metric type 指定對應的聚合函數，混用會讓長時間範圍的 dashboard 產生誤導性數值。

查詢路由的透明度也是設計重點。使用者把 dashboard 時間範圍從 1 小時拉到 7 天時，系統自動從 raw series 切到 rollup series，精度從 15 秒變成 5 分鐘。如果這個切換對使用者不透明，事故中觀察到的數值變化可能是精度切換的假象而非真實服務變化。

Metrics 讀取面的資源隔離

Metrics 的 query engine 跟 log 一樣面臨多種查詢模式競爭資源的問題。Dashboard 定期刷新是穩定的背景負載；alert rule evaluation 是系統關鍵的定期負載；事故即席查詢是偶發的突增負載。三者搶同一個 query engine 時，dashboard 跟 alert 的穩定負載會壓縮即席查詢的可用資源。

Prometheus 原生的資源隔離有限，但 Thanos Query Frontend、Mimir Query Frontend、Grafana Cloud 的 query scheduler 都支援 query priority 或 query queue 分離。設計時把 alert evaluation 設為最高優先（告警不能因 query 排隊而延遲），dashboard 次之，即席查詢的延遲容忍最高但不能被完全餓死。

交接路由

• 04.6 SLI/SLO 訊號設計：把 metric 升級為 user-journey SLI
• 04.7 metric cardinality / cost：label 治理與成本邊界
• 04.9 continuous profiling：metrics 之外的第四角觀測訊號
• 04.23 觀測查詢設計：跨訊號類型的讀取路徑系統設計
• 4.C11 Uber M3：單機 Prometheus 到平台級 metrics 系統的演進

• trace / span 模型
• trace context propagation
• context 斷鏈的常見邊界與修復
• sampling 策略的 tracing 面（SSoT 在 4.7）
• service graph 與依賴發現
• 反模式

概念定位

Trace 是把一次 request 在多個服務、queue 與背景任務中的路徑串起來的診斷訊號，責任是讓團隊從症狀追到跨服務等待點。

Log 回答「某個服務發生了什麼」；metric 回答「某個服務的健康趨勢」；trace 回答「一次 request 跨多個服務時，時間花在哪、錯誤發生在哪一段」。三者互補，trace 的獨特價值在於它串起跨服務的因果鏈 — 沒有 trace，事故定位只能靠人工比對不同服務的 log timestamp。

本章處理的是 context propagation — 怎麼讓 trace context 在 HTTP call、queue 投遞、背景任務啟動等邊界上正確傳遞。Context 斷掉時，trace 從「完整路徑」退化成幾段需要人工拼接的局部紀錄，跨服務診斷的時間成本會從秒級回退到分鐘甚至小時級。

Trace 與 Span 的結構

Span 是 trace 的基本單位

一個 span 代表一段有起止時間的工作。每個 span 記錄：操作名稱（POST /api/orders）、開始與結束時間、狀態（OK / Error）、屬性（service name、http.status_code、db.statement）與事件（exception、log message）。

Span 之間透過 parent-child 關係組成 tree。一個 HTTP request 進入 API gateway 時建立 root span，gateway 呼叫 order service 時建立 child span，order service 查 DB 時建立另一個 child span。整棵 tree 共享同一個 trace id，讓所有 span 可以被聚合成一次 request 的完整路徑。

Trace 是 span tree

一個 trace 是所有共享同一個 trace id 的 span 的集合。在 waterfall view 中，trace 呈現為時間軸上的巢狀條狀圖 — root span 在最上面，child span 依序往下排列，每段的長度代表耗時。

Waterfall view 的診斷價值是「一眼看到時間花在哪」。如果 checkout API 的 total latency 是 800ms，waterfall 會顯示 payment service 佔了 600ms — 問題定位從「整個 checkout 慢」縮小到「payment service 慢」，後續 debug 只需要看 payment service 的 log 跟 metric。

Context Propagation

什麼是 trace context

Trace context 是跨服務傳遞 trace 身份的資料。最小的 trace context 包含 trace id（標識整條 trace）跟 parent span id（標識上游 span）。下游服務收到 trace context 後，建立新的 child span 並繼承 trace id，讓兩端的 span 歸屬同一條 trace。

W3C Trace Context 標準定義了 HTTP header 的傳遞格式：traceparent header 帶 trace id + parent span id + trace flags，tracestate header 帶 vendor-specific 的附加資訊。OpenTelemetry SDK 預設使用 W3C 格式；部分 vendor 有自己的 header 格式（Datadog 用 x-datadog-trace-id、AWS X-Ray 用 X-Amzn-Trace-Id），需要在 collector 或 SDK 層做格式轉換。

Propagation 的傳遞機制

HTTP call 是最常見的 propagation 路徑 — SDK 的 HTTP client middleware 自動把 trace context 注入 request header，下游 SDK 的 HTTP server middleware 自動從 header 提取 context。大部分 OpenTelemetry SDK 的 auto-instrumentation 會自動處理這一層，開發者不需要手動注入。

gRPC 用 metadata（等同 HTTP header）傳遞，機制類似。

Message queue 的 propagation 需要把 trace context 放進 message 的 header 或 metadata。Kafka 用 record header、RabbitMQ 用 message properties、NATS 用 message header。Producer 端注入、consumer 端提取。Queue 的 propagation 比 HTTP 複雜的原因是 consumer 可能在 producer 之後很久才消費 — context 的時間跨度可能從毫秒擴大到分鐘或小時。

Context 斷鏈的常見邊界

Context propagation 在以下邊界容易斷裂：

Thread / goroutine / task 邊界：同步 runtime 通常用 thread-local 存放 context，新開 thread 不會自動繼承。Go 用 context.Context 顯式傳遞，相對不容易遺漏；Java 用 ThreadLocal，啟動新 thread 或提交到 thread pool 時 context 需要手動傳遞或用 agent auto-instrumentation。Async runtime（Node.js 的 AsyncLocalStorage、Python 的 contextvars）各有自己的 context 傳播機制。

Queue / event 邊界：producer 把 trace context 注入 message header，consumer 提取並建立新 span。如果 producer 端的 SDK 沒有自動注入（例如用了原生 Kafka client 而非 instrumented client），context 就斷了。跨 queue 的 trace 在 waterfall view 中會出現時間斷層 — producer span 結束到 consumer span 開始之間可能有秒級到分鐘級的等待。

Background job / cron 邊界：cron job 或 scheduled task 沒有上游 request，沒有 trace context 可繼承。這類工作需要在啟動時建立 root span，並把 job name、schedule、trigger reason 作為 span 屬性，讓 trace 至少可以追蹤 job 內部的行為。

跨語言 / 跨 vendor 邊界：不同語言的 SDK 或不同 vendor 的 instrumentation 可能用不同的 header 格式。W3C Trace Context 標準解決了格式問題，但混用 vendor-specific SDK 時（例如一個服務用 Datadog agent、另一個用 OTel SDK），需要在 collector 層做 context format 轉換。

斷鏈的修復策略

修復斷鏈的目標是讓 trace 在邊界處重新接上，不需要人工拼接。

Queue 邊界：確保 producer 跟 consumer 都使用 instrumented client（OTel SDK 的 messaging instrumentation），而非原生 client。Instrumented client 自動處理 header 注入跟提取。Consumer 端建立的 span 用 CONSUMER kind 標記，waterfall view 會顯示 queue 等待時間。

Thread pool 邊界：Java 生態用 Context.wrap() 包裝提交到 thread pool 的 Runnable/Callable；Go 生態用 context.Context 作為第一個函數參數傳遞（這是 Go 的慣例，不需要額外處理）。Auto-instrumentation agent 可以自動處理常見 thread pool（Java 的 ExecutorService、Node.js 的 worker_threads）。

跨 vendor 邊界：在 collector 層（OTel Collector）統一轉換 header 格式。Collector 的 receiver 支援多種格式輸入，exporter 統一輸出 W3C 格式。這層轉換在 4.11 telemetry pipeline 的 collector 中介段處理。

Trace 與 Log / Metric 的關聯

Correlation id 統一

Trace id 應該同時出現在 log 的結構化欄位中。當 log 的 trace_id 欄位帶著跟 trace 相同的值，debug 工作流就能從 trace waterfall 跳到某個 span 對應的 log，或從 log 跳到完整的 trace view。

實作方式是在 logger 初始化時，把當前 span 的 trace id 注入 log 的 context fields。OTel SDK 的 log bridge 可以自動做這件事；沒有自動橋接的框架需要手動把 span.SpanContext().TraceID() 寫進 log 的 correlation id 欄位。

Exemplar：metric 到 trace 的跳板

Metric 是聚合訊號，本身不帶單一 request 的 trace id。Exemplar 是附加在 metric 資料點上的代表性 trace id — 當某個 histogram bucket 收到一個資料點時，附帶記錄產生這個資料點的 trace id。

Dashboard 上看到 latency p99 升高時，可以從 exemplar 跳到一個具體的高延遲 trace，看 waterfall 定位慢在哪。Exemplar 是 metric 到 trace 的橋樑，讓聚合訊號（metric）跟個別案例（trace）連接起來。

Service Graph 與依賴發現

Trace 資料聚合後可以自動生成 service graph — 哪些服務在呼叫哪些服務、call 的頻率、延遲分布、錯誤率。這個 graph 跟手動維護的 architecture diagram 不同：它來自實際流量，反映的是「現在真的在發生什麼」而非「設計時預期會發生什麼」。

Service graph 的價值在於依賴發現。新服務加入後，如果有 trace instrumentation，它會自動出現在 graph 上。舊服務之間新增的依賴（例如 A 開始直接呼叫 C、繞過 B）也會被 graph 反映。手動維護的 wiki 通常落後實際狀況數週到數月。

Service graph 的完整性取決於 trace 的覆蓋率。如果某些服務沒有 instrumentation 或 sampling 率太低，graph 上會出現斷點或邊權不準。把 service graph 的完整性（「有多少比例的服務有 trace」）作為觀測覆蓋率的一個指標，能推動 instrumentation 的漸進覆蓋。

詳見 4.13 service topology。

核心判讀

判讀 tracing 時，先看 propagation 是否完整，再看 sampling 是否保留可除錯樣本。

重點訊號包括：

• trace id 是否能和 log、metric 共享 correlation id
• async / queue / background job 是否能保留 parent-child 關係
• sampling 是否能在高流量下保留錯誤與高延遲樣本（策略矩陣見 4.7）
• service graph 是否能由 trace 聚合而來，並降低 wiki 手動維護成本
• trace context 在跨語言 / 跨 vendor 邊界是否用 W3C 標準統一

判讀訊號

• Request 跨服務後 trace 斷鏈、靠人重組
• Async / queue 邊界 context 沒傳遞
• 採樣率太低、production debug 找不到對應 trace
• Trace id 跟 log / metric 對不上、無共同 correlation key
• Service graph 不存在或半年沒人看
• 多個 vendor SDK 混用、header 格式不一致
• Background job / cron 沒有 root span、trace 無法追蹤

反模式

交接路由

• 4.4 dashboard-alert：trace 資料在 dashboard 的呈現跟 alert 設計
• 4.7 cardinality / cost：sampling 策略矩陣（Head / Tail / Adaptive / Exemplar）與保留決策
• 4.11 telemetry pipeline：sampling 在 collector 的集中治理、跨 vendor header 轉換
• 4.13 service topology：trace 訊號聚合成依賴圖
• 4.17 telemetry data quality：sampling bias 跟 trace 完整性的資料品質
• 4.23 觀測查詢設計：trace 查詢作為即席診斷的一種模式

• Dashboard 設計原則：SLI 導向 vs 指標堆疊
• Alert 設計：symptom-based vs cause-based
• Alert noise control 與 alert fatigue
• Runbook linkage
• Dashboard / alert 的生命週期與 ownership
• 反模式

概念定位

Dashboard 與 alert 是把觀測訊號轉成操作入口的控制面，責任是讓團隊在正常巡檢與事故響應時看到同一組事實。

Dashboard 讓人理解狀態，alert 讓人採取行動。兩者的設計問題不同：dashboard 的問題是「資訊太多、焦點不明」；alert 的問題是「通知太多、行動不明」。兩者都需要 ownership、生命週期管理與 runbook 連結。

Dashboard 設計

SLI 導向 vs 指標堆疊

Dashboard 的常見失敗模式是「把所有能拿到的指標都放上去」。二十個 panel、五十條曲線、無法在 3 秒內回答「服務現在健康嗎」。

SLI 導向的 dashboard 從使用者體驗出發：第一排 panel 回答「使用者感受到的健康狀態」（availability、latency percentile、error ratio），第二排回答「健康狀態的原因」（dependency latency、queue depth、resource utilization），第三排回答「趨勢與容量」（traffic growth、storage usage、capacity headroom）。

每個 panel 都應該能回答一個具體問題。如果團隊看了某個 panel 後的反應是「所以呢？」，這個 panel 不是放錯位置就是不該存在。

Dashboard 層級

不同使用者看不同層級的 dashboard。把所有資訊擠在同一個 dashboard 會讓每個角色都找不到自己要的。

Service overview：on-call 工程師的第一個入口。5-8 個 panel，回答「這個服務現在有沒有問題」。SLI 指標（error rate、latency p99、availability）、最近的 alert、dependency 健康。

Debug dashboard：事故中的深入診斷入口。按 dependency 分組（database panel group、cache panel group、downstream API panel group），每組顯示延遲、錯誤率、連線數。Panel 數量多但按需展開。

Capacity dashboard：容量規劃用。週到月級的趨勢圖 — traffic growth、storage usage、connection pool saturation、cost trends。刷新頻率低（每小時或每天），panel 讀 recording rule 或 rollup 資料。

Business dashboard：給非工程角色看。轉換率、使用者活躍度、營收指標。資料來源可能不只是觀測訊號，還包括 analytics 跟 business metrics。

Dashboard 的查詢效能

Dashboard 是觀測查詢設計中「聚合趨勢」模式的主要消費者（見 4.23）。每個 panel 每 30 秒刷新一次，十個團隊各自有 dashboard 就是每分鐘數百個背景查詢。

Panel 設計時要注意查詢成本：時間範圍越長、raw series 越多、聚合越複雜，query-time cost 越高。長時間趨勢 panel 應該讀 recording rule 或 rollup series，而非每次刷新都掃描 raw data。

Alert 設計

Symptom-based vs cause-based

Symptom-based alert 觸發在使用者可感知的症狀上 — error rate 升高、latency p99 超過閾值、availability 下降。Cause-based alert 觸發在內部原因上 — CPU > 90%、disk usage > 85%、connection pool exhausted。

Symptom-based 是 alert 設計的起點。原因是：cause-based alert 容易產生大量「系統在忙但使用者沒受影響」的 false alarm。CPU 短暫衝到 95% 然後回落，如果 latency 跟 error rate 都正常，這個 alert 不需要人類介入。

Cause-based alert 的價值是預防性告警 — disk usage 趨勢在兩天後會滿、connection pool 使用率在高峰時逼近上限。這類 alert 不需要立即行動，但需要在工作時間排入 task。把 cause-based alert 設成 warning（不 page）、symptom-based alert 設成 critical（page on-call），能降低 noise。

SLO-based alerting

SLO-based alerting 用 burn rate 取代固定閾值。不是「error rate > 1% 就告警」，而是「error budget 的消耗速度超過預期就告警」。

Burn rate alerting 的好處是自動適應基線。低流量時段的 1% error rate 可能只是幾筆錯誤、不值得 page；高流量時段的 0.5% error rate 可能代表大量使用者受影響。Burn rate 用「相對於 SLO 允許的錯誤量，目前消耗速度有多快」來判斷嚴重性，比固定閾值更能反映使用者影響。

SLO-based alert 的實作通常用 multi-window burn rate — 短視窗（5 分鐘）抓急性問題、長視窗（1 小時）抓慢性問題。兩個視窗都超過 burn rate 閾值時才觸發，減少單一 spike 造成的 false alarm。

SLI/SLO 訊號的詳細設計見 4.6。

Alert 的必要欄位

每個 alert rule 應該帶以下 metadata，讓收到 page 的 on-call 工程師在 30 秒內知道下一步：

• Severity：critical（立即行動）/ warning（工作時間處理）/ info（記錄但不通知）
• Runbook link：對應的 runbook URL，描述診斷步驟跟可能的修復動作
• Owner：負責這個 alert 的團隊或服務
• Dashboard link：點進去直接看相關 panel，不用自己找 dashboard
• Summary：一句話描述發生了什麼（checkout error rate > 2% for 5 minutes），而非只有 alert rule 名稱

缺少 runbook link 的 alert 等於「通知了但不告訴你做什麼」。On-call 工程師收到不認識的 alert 時，第一反應是 ack 然後繼續觀察 — 這就是 alert fatigue 的起點。

Alert Noise Control

什麼是 noise

Alert noise 是「觸發了但不需要人類行動」的 alert。包括：

• False positive：條件觸發但實際沒問題（短暫 spike 觸發固定閾值、maintenance 期間的預期 error）
• Redundant alert：同一個問題觸發多個 alert（database 慢 → query timeout alert + error rate alert + latency alert 同時觸發）
• Stale alert：條件已經不適用（服務改版後舊 alert rule 沒更新、abandoned service 的 alert 還在）

Noise rate 量測

Noise rate = 不需要行動的 alert / 總 alert。追蹤方式是讓 on-call 工程師在 ack alert 時標記「actionable」或「noise」。月度彙整 noise rate，超過 30% 的 alert rule 進入治理流程（業界常用的基線閾值，Google SRE Workbook 建議 actionable rate 維持在 70% 以上；團隊可依自身容忍度調整）。

降噪手段

Grouping：把同一個根因觸發的多個 alert 合併成一則通知。Alertmanager 的 group_by 讓同服務、同 alert name 的 alert 只發一次。

Inhibition：高嚴重性 alert 抑制低嚴重性。Database down 觸發時，所有依賴該 database 的 query timeout alert 被抑制 — 根因已知、不需要每個症狀都通知。

Silence / maintenance window：已知的維護活動期間暫停特定 alert。Silence 需要有過期時間，避免永久靜默掩蓋真實問題。

Hysteresis：alert 觸發需要條件持續 N 分鐘（for: 5m），避免瞬間 spike 觸發。恢復也需要條件持續 N 分鐘，避免「反覆觸發 → 恢復」的 flapping。

Runbook 設計

Runbook 是 alert 的行動指南。每個 critical alert 應該連到一份 runbook，描述「收到這個 alert 時該做什麼」。

Runbook 的有效結構：

1. 症狀描述：這個 alert 代表什麼（「checkout error rate 超過 SLO burn rate」）
2. 影響評估：誰受影響、嚴重程度（「付款功能受影響、影響所有 checkout 流程」）
3. 診斷步驟：先看哪個 dashboard、查哪些 log、跑哪些 query
4. 可能的修復動作：restart service、scale up、rollback deployment、failover to backup
5. 升級路徑：如果 15 分鐘內無法解決，通知誰

Runbook 的維護責任跟 alert 的 owner 一致。Alert rule 改了但 runbook 沒更新是常見的退化 — 把 runbook 的 last-reviewed date 作為 alert 治理的審計項目。

Dashboard 與 Alert 的生命週期

Dashboard 跟 alert 都有生命週期。建立時有用，但隨服務演進可能變得過時、冗餘或誤導。沒有生命週期管理的 dashboard / alert 系統會累積 debt — dashboard 數量膨脹但無人看、alert rule 堆疊但多數是 noise。

Ownership

每個 dashboard 跟每個 alert rule 都需要明確的 owner。Owner 負責：維護 panel / rule 的正確性、定期審視 noise rate 跟使用率、在服務變更時更新對應的 dashboard / alert。

沒有 owner 的 dashboard 跟 alert 應該有過期機制 — 超過 N 天沒有人訪問的 dashboard 標記為候選淘汰、超過 N 天沒有觸發的 alert rule 審視是否仍有意義。

定期審視

Dashboard 跟 alert 的定期審視是 4.8 signal governance loop 的一部分。每季或每次重大事故後，審視：

• 哪些 alert 的 noise rate 過高、需要調整或刪除
• 哪些 dashboard 沒人訪問、可以合併或淘汰
• 事故中是否有缺少的 alert 或 dashboard panel

Ownership 矩陣與 metadata 欄位的詳細設計見 4.18 operating model。

核心判讀

Dashboard 跟 alert 是否有效，最直接的訊號是 alert noise rate 跟 dashboard 訪問頻率 — noise rate 超過 30% 代表通知品質退化，dashboard 長期零訪問代表資訊跟決策脫節。

重點訊號包括：

• Alert 是否能對應到明確 runbook、ownership 與停止條件
• Dashboard 是否有固定使用者與更新責任
• Threshold 是否對齊 SLO、容量邊界或使用者影響
• Noise rate 是否被追蹤並回寫治理流程
• Dashboard panel 是否讀 recording rule 而非每次重算 raw data

判讀訊號

• Alert 跟 runbook 沒連、收到 page 不知道做什麼
• Dashboard 數量爆量、無 owner、半年無人訪問
• 同一訊號多個 alert 重複觸發、無 grouping 或 inhibition
• Alert noise rate > 30%、ack 後無實際動作，形成 alert fatigue
• Alert threshold 用直覺數字、沒對齊 SLO / 商業承諾
• Dashboard panel 載入慢、因為直接查 raw series 而非 recording rule
• Maintenance window 過後 silence 沒移除、真實問題被掩蓋

反模式

交接路由

• 4.3 tracing：trace waterfall 作為 dashboard 的診斷入口
• 4.6 SLI/SLO 訊號設計：alert 的訊號源頭、burn rate alerting 的 SLI 依據
• 4.8 訊號治理閉環：alert / dashboard 的生命週期維運
• 4.10 client-side / RUM：補 server-side 看不到的 dashboard 維度
• 4.14 anomaly detection：rule-based alert 之外的統計訊號
• 4.18 operating model：dashboard / alert 的 ownership 矩陣與 metadata 欄位
• 4.23 觀測查詢設計：dashboard 查詢的效能與 recording rule

• 觀測系統為什麼需要威脅建模
• 三類弱點：觀測盲區、告警失真、資料暴露
• 每類弱點的判讀流程與修復方向
• 跟 4.4 dashboard-alert 跟 07 資安 的分工

概念定位

可觀測性威脅建模的判讀目標是「觀測系統本身有哪些弱點會讓事故更難處理、更慢收斂、或擴大成資安事件」。觀測系統是事故處理的核心工具 — 工具失靈時，事故的 MTTD（偵測時間）跟 MTTR（修復時間）都會被拉長。

本章用三類弱點盤點觀測系統：觀測盲區（看不到問題）、告警失真（看到錯的東西）、資料暴露（觀測資料本身變成風險）。每類弱點有各自的判讀流程跟修復方向。

跟傳統資安威脅建模的差異：資安威脅建模聚焦「攻擊者怎麼入侵系統」；觀測威脅建模聚焦「觀測系統的設計缺陷怎麼讓事故更難處理」。兩者的交叉點在資料暴露 — 觀測資料含 secret 或 PII 時，觀測弱點直接成為資安弱點。

哪些服務要先做觀測弱點盤點

下列情境同時出現時，觀測弱點會快速放大：

• 服務數量增加，跨服務呼叫變深 — trace 斷鏈的影響面擴大
• 值班依賴告警，但告警常常失真或過量 — alert fatigue 讓真正的問題被淹沒
• 調查事故高度依賴人工搜尋 log — 缺少結構化查詢入口
• 支援工具與觀測平台可接觸敏感資料 — 觀測資料的存取控制不足

弱點一：觀測盲區

觀測盲區是「問題存在但觀測系統看不到」的狀態。盲區的危險在於它讓團隊對系統狀態的判斷建立在不完整的資訊上 — 看起來一切正常，但其實有路徑沒被觀測到。

常見盲區

Sampling 導致的盲區：head sampling 按固定比例丟棄 trace，低流量服務的錯誤樣本可能全部被丟。事故時查 trace 查不到，因為 sampling 把剛好那些 request 的 trace 丟了。修復方向是 tail sampling 或 minimum sample floor（見 4.7 sampling 策略）。

Uninstrumented 路徑：新上線的服務沒加 instrumentation、async worker 沒有 span、third-party SDK 的 HTTP call 沒被攔截。這些路徑在 service graph 上不存在，事故時團隊甚至不知道有這條依賴。修復方向是把 instrumentation coverage 作為 readiness review 的檢查項。

Context 斷鏈形成的局部盲區：trace context 在 queue、thread pool、background job 邊界斷掉後，下游的 span 成為孤兒。團隊可以看到下游服務有問題，但看不到跟上游 request 的因果關係。修復策略見 4.3 tracing。

Log schema 漂移：不同服務的 log 用不同欄位名稱記錄同一個概念（request_id vs req_id vs requestId）。查詢時用 request_id 搜尋會漏掉用其他名稱的服務。修復方向是 log schema 的跨服務統一。

盲區的判讀方式

• 列出所有服務，標記哪些有 trace instrumentation、哪些沒有
• 檢查 service graph 跟已知 architecture diagram 的差異 — 差異就是盲區
• 用已知的跨服務 request 做 end-to-end trace 驗證，看有沒有斷點
• 檢查 sampling policy，確認低流量服務跟 error sample 的保留率

弱點二：告警失真

告警失真是「觀測系統看到了、但告訴你的是錯的或沒用的」。失真比盲區更危險 — 盲區至少讓團隊知道「這裡沒資料、要用其他方式查」；失真讓團隊基於錯誤訊號做判斷。

常見失真模式

Threshold drift：alert 的閾值在設定時是合理的（error rate > 1%），但服務改版後基線變了（正常 error rate 從 0.1% 變成 0.5%），閾值沒跟著調。結果是 alert 頻繁觸發但團隊知道是 false alarm — alert fatigue 開始累積。

Aggregation 掩蓋：用 average latency 做 alert，tail latency 被掩蓋。Average 200ms 但 p99 是 5 秒 — 1% 的使用者體驗極差但 alert 沒觸發。修復方向是 percentile 跟 histogram。

Alert storm：單一根因觸發大量 alert（database 慢 → 所有依賴該 database 的服務都觸發 latency alert + error alert + timeout alert）。On-call 收到 20 則通知，分不清哪個是因、哪個是果。修復方向是 alert grouping 跟 inhibition（見 4.4 dashboard-alert）。

Stale dashboard：Dashboard 的 panel 引用的 metric name 已改名、panel 的 query 因 label 變更而回空值。Dashboard 看起來正常（曲線是平的），但其實是 no data 被渲染成 zero。修復方向是 dashboard 的 no-data alert 跟定期審視。

失真的判讀方式

• 追蹤 alert noise rate（每月有多少 alert 是 actionable 的）
• 檢查 alert rule 的 threshold 跟當前 baseline 是否對齊
• 確認 SLI 用 percentile 而非 average
• 事故復盤時問「這次的事故，alert 有沒有在對的時間告訴我們對的事」

弱點三：資料暴露

觀測資料本身是風險資產。Log 可能含 secret（API key、token、password）、trace 可能含 PII（使用者 email、電話號碼在 span attribute 中）、dashboard 可能對所有人開放且顯示敏感業務指標。

常見暴露路徑

Log 含 secret：SDK 或框架在 error 發生時把完整 request body 寫進 log，body 中的 API key、token、password 跟著進入 log storage。Log storage 的存取控制通常比 secret manager 寬鬆 — 有 log 讀取權限的人都能看到 secret。

Trace attribute 含 PII：http.url attribute 帶完整 URL（含 query parameter 裡的 email 或 token）、db.statement attribute 帶完整 SQL（含 WHERE 子句的使用者 ID）。Trace storage 的保留期可能比業務資料庫長，PII 在 trace 裡存活的時間超過必要範圍。

Dashboard 權限過寬：所有工程師都能看所有服務的 dashboard，包含財務相關的 metric（營收、訂單金額分布）。Dashboard 的存取控制粒度通常是「整個 Grafana instance」而非「per-dashboard」。

Collector / pipeline 有管理員權限：OTel Collector 或 log aggregator 以 admin 權限部署，可以讀寫 secret、修改配置、存取所有資料。Collector 被入侵時，攻擊者可以把 redaction 規則關掉、讓後續的 log 全量暴露。

暴露的修復方向

• SDK 端做 redaction（在送出前掃描已知 secret pattern 並替換成 [REDACTED]）
• Collector 端做 attribute 過濾（在 pipeline 中移除敏感 attribute）
• Log / trace storage 做存取控制（RBAC、per-team 隔離）
• Dashboard 做權限分層（業務 dashboard 需要額外授權）
• 定期掃描 log storage 檢查是否有未 redact 的 secret pattern

詳見 07 資安與資料保護 跟 4.12 audit log governance。

設計取捨：訊號完整度與成本控制

觀測覆蓋越完整，盲區越少、事故定位越快。同時儲存、查詢與維護成本也會上升。穩定做法是先定義核心訊號與最低欄位（log schema 的 correlation fields、SLI 的 availability + latency），再按高風險路徑逐步加深觀測。

「全收」的成本問題見 4.7 cardinality；「選擇性收」的品質問題見 4.17 telemetry data quality。

核心判讀

判讀觀測弱點時，按三類依序盤點：

1. 盲區：哪些服務或路徑沒有被觀測到？Sampling 是否丟掉高價值樣本？
2. 失真：Alert noise rate 有多高？Threshold 跟 baseline 是否對齊？SLI 用的是 average 還是 percentile？
3. 暴露：Log / trace 是否含 secret 或 PII？Dashboard 權限是否過寬？Collector 的存取權限是否最小化？

判讀訊號

• 事故時查 trace 查不到（sampling 丟掉）
• Service graph 跟 architecture diagram 有明顯差異（uninstrumented 服務）
• Alert noise rate > 30%（threshold drift 或 aggregation 掩蓋）
• 同一事故觸發 10+ 個 alert（alert storm、缺 grouping / inhibition）
• Log grep 到 API key 或 token（redaction 缺失）
• Dashboard 對所有人開放且顯示營收指標（權限過寬）

交接路由

• 4.3 tracing：context 斷鏈的修復策略
• 4.4 dashboard-alert：alert noise control、grouping、inhibition
• 4.7 cardinality：sampling 策略與保留決策
• 4.8 signal governance：alert / dashboard 的定期審視
• 4.12 audit log：觀測資料的存取控制與稽核
• 4.16 readiness review：instrumentation coverage 的上線前檢查
• 4.17 telemetry data quality：sampling bias 跟 schema drift 的品質問題
• 07 資安：secret management、data masking、存取控制

• SLI 設計起點：user-journey 而非 system metric
• 量測點選擇：edge / gateway / service / dependency 各自代表什麼
• Ratio metric vs latency percentile：何時用哪種
• Burn rate 訊號：multi-window multi-burn-rate alert
• Error budget 計算所需的 metric 結構
• 跟 4.2 metrics 的分工：4.2 是 counter/gauge/histogram 基礎、4.6 是 SLI 化的設計
• 跟 4.4 dashboard-alert 的分工：4.4 是 alert 規則治理、4.6 是 alert 的訊號源頭
• 反模式

概念定位

SLI 訊號設計是把可靠性目標轉成可量測資料的步驟，責任是讓 SLO 政策建立在使用者旅程與服務結果上。

CPU、memory、queue depth 可以提供系統背景，但 SLI 需要回答的是使用者層面的問題：request 是否成功、回應是否夠快、結果是否正確。SLI 量測的位置跟算式決定了 SLO 反映的是「使用者體驗」還是「基礎設施健康」— 兩者的判讀意義不同。

本章處理的是 metric 到 SLI 的轉換。4.2 定義 counter / gauge / histogram 的基礎型別；本章定義怎麼用這些型別組出代表使用者體驗的 SLI，並設計 burn rate alert 的訊號結構。SLO 政策本身（error budget freeze、release gate 決策）由 6.6 SLO 政策 處理。

SLI 設計起點：User Journey

從使用者操作推導 SLI

SLI 的設計起點是「使用者在做什麼、期待什麼結果」，不是「系統有什麼 metric 可以用」。

一個 checkout 流程的使用者期待：request 成功（不會看到 error page）、回應夠快（不會等超過 3 秒）、結果正確（扣款金額正確）。對應三種 SLI：

• Availability SLI：成功 request 的比例（successful_requests / total_requests）
• Latency SLI：回應時間在閾值內的比例（requests_under_3s / total_requests）
• Correctness SLI：結果正確的比例（需要業務邏輯判定，通常用特定 error code 或 reconciliation 結果）

每個 user journey 不需要三種 SLI 都有。Checkout 的 availability 跟 latency 是核心；correctness 靠事後對帳驗證。搜尋頁面的 latency 比 availability 更關鍵 — 使用者容忍偶發的「搜不到結果」但不容忍 5 秒的載入。

System metric 跟 SLI 的差異

CPU > 90% 不是 SLI — 它是 cause signal。CPU 高但 latency 正常，使用者沒受影響。Disk usage > 85% 也不是 SLI — 它是 capacity signal，需要處理但不代表當下使用者體驗退化。

System metric 的價值在 root cause analysis，不在 SLI。事故中先看 SLI 判斷「使用者是否受影響」，確認受影響後再看 system metric 判斷「原因是什麼」。把 system metric 當 SLI 會讓 SLO 反映基礎設施噪音而非使用者體驗。

量測點選擇

SLI 的量測點影響「看到的是誰的觀點」。同一個 request 在不同位置量測會得到不同的 latency 跟 success rate。

Edge / Load Balancer

最貼近使用者的量測點。量到的 latency 包含 network round-trip + TLS handshake + 所有 backend 處理時間。Availability 反映的是使用者實際看到的 success rate（包含 load balancer 自身的 502/503）。

優點是最能代表使用者體驗。缺點是 load balancer 的 metric 粒度有限 — 通常只有 status code 跟 latency，不帶 service-level 的維度切分。

API Gateway

比 edge 更有應用層上下文。可以按 route / method / tenant 切分 SLI。量到的 latency 不含 network round-trip（已經進入服務網路），但包含 authentication、rate limiting 跟所有下游處理。

API gateway 是多數團隊的 SLI 量測起點 — 粒度足夠、位置夠近使用者、通常已有 instrumentation。

Service level

每個服務的 handler-level metric。可以看到單一服務的 latency 跟 error rate，但不含上下游的影響。適合做 service-level SLO（「order service 的 p99 latency < 200ms」），但不直接代表 user-journey SLO。

Service-level SLI 的價值在於 SLO 階層化 — user-journey SLO 拆分成每個服務的 SLO，事故時能快速定位是哪個服務的 SLO 被打破。

Dependency level

量測外部依賴（database、cache、third-party API）的回應時間跟 error rate。Dependency metric 的角色是 SLI 退化時的歸因訊號，用來追溯因果鏈而非直接代表使用者體驗。Database latency 上升 → service latency 上升 → user-journey latency SLO 被打破 — dependency metric 幫助追溯因果鏈。

SLI 的 Metric 結構

Ratio metric：availability 跟 correctness

Availability SLI 的 metric 結構需要兩個 counter：total requests 跟 successful requests（或 failed requests）。SLI = good / total。

1# Availability SLI
2http_requests_total{service="checkout", status="2xx"} / http_requests_total{service="checkout"}

定義「good」的邊界需要明確。5xx 算 bad，4xx 呢？Client error（400）通常不算服務失敗；authentication failure（401/403）也不算。但 429（rate limit）可能代表服務容量不足，視情境可能算 bad。這個邊界要在 SLI 定義時明確寫下來。

Latency metric：threshold-based ratio

Latency SLI 用 histogram 量測，SLI 值是「在閾值內的 request 比例」。

1# Latency SLI：p99 < 500ms 的比例
2histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service="checkout"}[5m])) < 0.5
3
4# 或用 ratio 形式
5sum(rate(http_request_duration_seconds_bucket{le="0.5",service="checkout"}[5m]))
6/ sum(rate(http_request_duration_seconds_count{service="checkout"}[5m]))

Latency 閾值的選擇要對齊使用者期待而非系統能力。使用者期待 checkout 在 3 秒內完成 — 這是閾值的來源，不是「系統平均 latency 是 200ms 所以閾值設 500ms」。

Label 設計

SLI metric 的 label 需要足夠的切分能力（by service、by endpoint、by tenant），但受 cardinality 預算約束。

最小 label set：service name + method（GET/POST）+ status class（2xx/4xx/5xx）。這組 label 支撐 service-level SLO 計算。

擴展 label：endpoint path（normalize 後，例如 /api/orders/{id} → /api/orders/:id）、tenant（多租戶場景）。每增加一個 label 維度，series 數量乘法增長 — 在 4.7 cardinality 的 label 白名單中管理。

Burn Rate 與 Multi-window Alert

Burn rate 的概念

Burn rate 是「error budget 被消耗的速度」。Burn rate = 1 代表按 SLO 允許的速度正常消耗；burn rate = 10 代表消耗速度是允許值的 10 倍 — 如果持續下去，error budget 會在 SLO 週期的 1/10 內耗盡。

用 burn rate alert 取代固定閾值 alert 的好處：burn rate 自動適應流量。低流量時段的幾筆 error 可能 burn rate 很低（因為 total 也少、對 error budget 影響小）；高流量時段的相同 error rate 可能 burn rate 很高（因為 total 多、影響的使用者量大）。

Multi-window multi-burn-rate

單一時間窗口的 burn rate alert 會太吵（短窗口）或太晚（長窗口）。Multi-window 策略組合兩者：

14.4x 的來源：若 SLO 週期是 30 天、要在 1 小時內偵測到會耗盡 2% error budget 的問題，burn rate = (30 × 24) / 1 × 0.02 ≈ 14.4。6x 跟 1x 依此邏輯調整消耗比例跟偵測窗口。

短窗口（5min）抓急性：error rate 突然飆高、burn rate 衝到 14.4x。長窗口（1hr）做確認：退化確實持續、排除瞬間 spike。兩個窗口都超過閾值才觸發 alert，減少單一 spike 的 false alarm。

Recording rule 支撐 burn rate 計算

Burn rate 的計算涉及多個時間窗口的 ratio metric。每次 alert evaluate 都重算會給 TSDB 帶來查詢壓力。用 recording rule 把每個窗口的 error ratio 預計算，alert rule 讀 recording rule 的輸出：

1# Recording rule：5 分鐘窗口的 error ratio
2- record: slo:checkout:error_ratio:rate5m
3  expr: sum(rate(http_requests_total{service="checkout",status=~"5.."}[5m]))
4      / sum(rate(http_requests_total{service="checkout"}[5m]))

Alert rule 讀 recording rule 比每次重算 raw series 高效，也讓 burn rate 的計算邏輯集中管理。

Error Budget 的 Metric 結構

Error budget 是 SLO 週期內允許的錯誤量。SLO = 99.9% 代表 30 天內允許 0.1% 的 request 失敗。Error budget = total requests × 0.001。

Error budget 的 metric 結構需要：

• Total requests（rolling window）：過去 30 天的 total request count
• Failed requests（rolling window）：過去 30 天的 failed request count
• Budget consumed：failed / (total × (1 - SLO target))
• Budget remaining：1 - budget consumed

Budget remaining 作為 dashboard panel 跟 release gate 的輸入 — 餘額低於閾值時 freeze deployment。這個計算的 rolling window 用 recording rule 維護，避免每次查詢掃描 30 天的 raw data。

核心判讀

判讀 SLI 設計時，先看量測點是否貼近使用者，再看算式是否能穩定支援 error budget。

重點訊號包括：

• Edge / gateway / service / dependency 的量測點是否各自有清楚責任
• Latency percentile 與 ratio metric 是否對應不同使用者體驗
• Burn rate 是否使用多時間窗，避免太吵或太晚
• SLI label 是否有足夠切分能力，同時受 cardinality 預算約束
• Error budget 的 rolling window 是否用 recording rule 維護

判讀訊號

• Alert 用 system metric（CPU / memory）而非 user-facing 訊號
• Burn rate 只有單窗、噪音多或偵測太晚
• SLI 計算用平均、不用 percentile
• Error budget 算式分母不穩（流量低時誤觸發、高時稀釋）
• SLI 量測點離使用者太遠（內部 service 而非 edge/gateway）
• SLI 沒有定義「什麼算 good request」的邊界（4xx 算不算 bad）
• Burn rate 計算每次重算 raw series、沒有 recording rule

反模式

交接路由

• 4.2 metrics：counter / gauge / histogram 基礎型別
• 4.4 dashboard-alert：burn rate alert 的 noise control 跟 runbook
• 4.7 cardinality / cost：SLI metric 的 cardinality 預算
• 4.10 client-side / RUM：user-journey-centric SLI 的前端訊號來源
• 4.23 觀測查詢設計：recording rule 支撐 burn rate 計算
• 6.6 SLO 政策：error budget 餘額作為 freeze 條件
• 6.8 release gate：burn rate 觸發 freeze
• 8.1 incident severity：burn rate 對應 severity 門檻
• 4.14 anomaly detection：跟 SLO threshold 的訊號分工

• cardinality 為何爆：unbounded label（user_id / request_id / url path）
• metrics 的 cardinality 影響：時序資料庫 series 爆炸、查詢退化
• log 的 cardinality 影響：索引膨脹、保留成本
• trace 的 sampling 策略：head sampling vs tail sampling、tradeoff
• cost-aware observability：成本作為治理輸入而非事後賬單
• governance 控制面：label 白名單、ingestion quota、保留階梯
• 高峰場景：流量尖峰時 cardinality slope 是 leading indicator
• 跟 4.1 log schema 的分工：4.1 設計欄位、4.7 設邊界
• 跟 4.2 metrics 的分工：4.2 是 metric 種類、4.7 是 label 治理
• 反模式：所有事件都打高 cardinality label、預算耗盡才砍訊號、保留策略無階梯

概念定位

Cardinality 治理是把觀測維度當成有限資源管理的流程，責任是讓訊號足夠可切分，同時不讓儲存、查詢與告警成本失控。

這一頁處理的是成本邊界。可觀測性需要有選擇地收集訊號；它把高價值維度留在可查詢路徑，把低價值或無界維度放到更合適的資料層。

Cardinality 跟成本的關係是非線性的。Label 數目每增加一倍，metric series 數目可能呈乘法增長；查詢延遲、儲存大小、索引重建時間都會跟著放大。把 cardinality 視為一級治理項目，能避免「收得越多越好」的直覺推著成本上升。

Cardinality 在不同訊號的失分模式

Cardinality 在 metric、log、trace 三類訊號的影響機制不同，失分模式也不同。把三者用同一套治理規則處理，會在某類訊號上過度限制、在另一類上失控。

Metric cardinality 是最敏感的維度。Prometheus 等 pull-based TSDB 在 series 數超過數百萬時查詢退化、aggregation 失準、recording rule 跑不完。Cloud 託管型 TSDB 雖然容量更大，但每個 active series 的單價非常具體，cardinality 直接對應 vendor 月帳單。

Log cardinality 的失分比較緩慢。Log 的 unique 值多本身不會立即崩潰，但全文索引 + 結構化欄位索引會持續膨脹，到某個臨界點查詢從毫秒退化到秒、再到分鐘。一般診斷不易察覺，要靠 query latency 跟 index size 的長期趨勢才能發現。

Trace cardinality 的問題是另一種：sampling 過於粗暴會丟失高價值樣本。低流量服務、錯誤樣本、長尾延遲樣本若被 head sampling 平均稀釋，事故時無 trace 可看。Trace 的治理重點是 sampling 策略而非單純限制 cardinality。

高 cardinality 的常見來源

無界維度進入可查詢路徑是 cardinality 失控的最大來源。常見的「無意中變成 label」：

• User / tenant identifier：把 user_id 當 label 時，每個用戶都產生一條 series。10 萬用戶 = 10 萬條 series 乘以其他 label 的笛卡爾積。
• Request / session identifier：request_id、session_id、trace_id 本質是無界的，進入 metric label 後 series 無限增長。
• 完整 URL / path parameters：/users/123/orders/456 這類 path 進入 label，每個 unique URL 都是新 series。
• 錯誤訊息 / stack trace：把 raw error message 當 label 時，每次新錯誤 = 新 series。
• 時間戳跟亂數：偶發出現的 bug，把 timestamp、uuid 寫進 label。

這些都應該進 log 或 trace 的欄位，不該進 metric 的 label。Metric 的 label 應該是有界的維度：service name、environment、region、status code、http method、error class。

高峰場景的 cardinality 失控

高峰場景的 cardinality 治理責任是讓「平時可控的 series 上限」在尖峰時仍能維持決策可用。平時 cardinality 看似穩定，高峰時可能突然出現新 tenant、新 endpoint、新 error class 的湧入，把 series 推到平台極限；治理重點是把「成長斜率」「容量緩衝」「dry-run」「freshness gap」變成預先設計的訊號、而非高峰中即興救火。

對應 4.C2 Gaming 高峰流量下的訊號新鮮度與 Cardinality：揭露「ingestion lag、cardinality growth slope、alert freshness gap」是高峰場景的核心治理項目（三個訊號名稱屬 case 直接列出）；以下做法基於通用工程知識展開。

高峰場景的可操作做法：

1. 把 cardinality growth slope 視為 leading indicator：series 數目的成長斜率比絕對值更早反映異常。突然出現的快速上升通常意味著新 label 值湧入或既有 label 失控。
2. 預設容量 buffer：日常使用容量設在平台上限的 50-60%，留高峰時 cardinality 突發空間。把容量推到 90% 才追加治理會在高峰時來不及。
3. 高峰前的 dry-run：把預期高峰流量的 cardinality 估算進 capacity model，找出可能的 unbounded label。對應 9.6 容量規劃模型。
4. Alert freshness gap 也要監控：高峰時 ingestion lag 上升、告警延遲、值班決策落在過期資料上的風險。把 alert freshness（資料時間 vs 當前時間）變成 dashboard 訊號。

高峰結束後做 retrospective：哪些 label 在高峰時超出預期、哪些 alert 因延遲沒及時觸發、哪些 series 應該下次提前 bucketize。這個 retrospective 是治理閉環的一部分，由 4.8 signal-governance-loop 處理長期回寫。

Sampling 策略

本章是 04 模組的 sampling 策略 SSoT — Head / Tail / Adaptive / Exemplar 四類策略集中在此；sampling 對資料品質的失真風險（low-traffic bias、error sample loss、tail latency loss）由 4.17 Sampling 與代表性 處理；trace context 層的 sampling 配置由 4.3 tracing context 處理。

Sampling 策略的核心責任是控制觀測成本、同時保留足以判讀的高價值樣本。固定比例 head sampling 是最常見、也是最容易丟失高價值樣本的策略。

實務上常用組合：低流量服務用接近 100% 採樣（minimum sample floor）、高流量服務用 tail sampling 保留錯誤跟長尾、metric 帶 exemplar 讓從 dashboard 跳到 trace。

四類策略各自的適用情境：

• Head sampling 適合單體應用、延遲敏感、collector 端資源吃緊的場景。代價是 trace 開始時無法判斷是否錯誤、會等比例丟掉錯誤樣本。
• Tail sampling 適合微服務、需保留錯誤跟長尾的場景。代價是 collector 要 buffer 整條 trace、記憶體跟 CPU 用量明顯增加、對 cluster gateway 容量規劃壓力大。
• Adaptive sampling 適合多租戶、流量差異大的場景。風險是規則複雜化會造成 sampling rate 漂移、必須持續監控每個 service / tenant 的實際保留比例、否則治理會失控。
• Exemplar attachment 補強 metric → trace 跳轉、不解決 sampling 本身。在已有 head/tail sampling 的場景上加 exemplar 是低成本高價值的做法。

關鍵是 sampling policy 本身要可被服務團隊理解跟調整。把 sampling 規則寫在 collector 配置裡、版本化、跟著 release 一起管理；把當前 sampling rate 跟保留分布暴露在 dashboard 上。當服務團隊發現某段時間 trace 殘缺、要能直接查到 sampling policy 的當下值跟變更紀錄。

控制面與保留階梯

可操作的 cardinality / 成本治理控制面有四層，從預防到事後審計都要覆蓋。

1. 設計時 label 白名單：服務團隊新增 metric 時要 review label 是否在白名單內。白名單列出有界維度（service、env、region、status_code、error_class、http_method），明確排除 user_id、request_id、完整 URL。
2. Ingestion 層 quota 與 cardinality limit：collector 或 vendor 端設定每服務、每 tenant 的 series 上限。超過上限時觸發告警，並啟動 graceful 降級（保留高優先 series、其他暫停）。
3. 保留階梯：依資料熱度跟法規責任分層保留。熱資料（最近 7 天）full granularity、溫資料（7-30 天）aggregated、冷資料（30+ 天）長期歸檔。階梯設計要結合 4.12 audit log governance 的法規保留期。
4. 成本歸屬到 owner：把 ingestion、storage、query 成本拆到服務或團隊維度。沒有歸屬的成本會被視為平台問題，治理動力不會傳到產生成本的團隊。詳見 4.15 cost attribution。

保留階梯的另一個價值是事故時的容量保護。當熱資料儲存接近滿載、可以加速冷化、主動釋放容量給當下事件、避免被動等保留期到再恢復。

Storage tiering 對查詢能力的影響

保留階梯不只是成本工具，它直接決定不同時間範圍的查詢能力。每一層的儲存介質、索引密度、rollup 精度決定了該層能回答什麼問題、不能回答什麼問題。

每一層能回答什麼

Hot tier 保留完整精度與完整索引，能支援即席診斷的所有維度切片（by service、by tenant、by error code、by request id）。當資料從 hot 移到 warm，部分索引可能被移除、精度可能被 rollup 降低，能做的查詢從「特定 request id 的完整事件鏈」退化為「某服務過去兩週的 error rate 趨勢」。到 cold tier，通常只剩 timestamp + 少數結構化欄位的最小索引，細節查詢需要先 rehydrate 回 warm 或 hot 層。

這個退化是設計選擇，但需要被使用者感知。事故復盤時，如果團隊想查兩週前的特定 request 但資料已在 warm tier 且 request id 索引被移除，他們需要知道「不是沒有資料，而是需要 rehydrate 才能查」。

跨層查詢的延遲跳變

Dashboard 的時間範圍選擇直接觸發跨層查詢。使用者從「最近 1 小時」（全部在 hot tier）拉到「最近 7 天」（hot + warm tier），查詢延遲從毫秒跳到秒級。再拉到「最近 90 天」（hot + warm + cold tier），延遲可能跳到十秒甚至分鐘級。

這種延遲跳變在事故中的影響是：incident commander 想看長期趨勢來判斷異常是突發還是漸進時，dashboard 卡在載入。應對方式是在 dashboard 設計時就把「長時間趨勢」panel 指向 recording rule 或 rollup series，讓它讀取預聚合資料而非跨層掃描 raw data。

Tier 邊界依訊號類型差異化

不同訊號類型的 tier 邊界應該不同。Error log 跟 trace 的事故診斷價值比 debug log 高，hot tier 保留期應該更長。Audit log 因合規要求可能需要長期可查詢而非純歸檔。SLO-critical 的 metric series 可能需要 hot tier 保留 30 天來支援 monthly burn rate 計算，而 debug-level 的 metric 只需要 7 天 hot tier。

把所有訊號用同一個 tier 邊界管理（「全部 7 天 hot、30 天 warm、1 年 cold」）會讓高價值訊號過早退化、低價值訊號佔用過多 hot tier 容量。依訊號優先級設定差異化的 tier 邊界是保留階梯設計的進階步驟。

詳細的跨訊號查詢設計見 4.23 觀測查詢設計。

核心判讀

判讀 cardinality 時，先看維度是否有決策價值，再看它是否有上界。

重點訊號包括：

• user id、request id、完整 URL 是否進入不該承受的 metric label
• log index 是否只索引常用查詢欄位
• trace sampling 是否能優先保留高價值樣本
• retention 是否依資料熱度與法規責任分層
• cardinality growth slope 是否被監控為 leading indicator

判讀訊號

• metric series 數量曲線陡升、TSDB 查詢退化
• log ingestion 成本月對月雙位數成長
• label 含 user_id / request_id / 完整 URL 直接送到 metric
• ingestion quota 觸發時靠砍訊號救火、無 graceful 降階
• 保留策略全平、無冷熱分層、舊資料拖累查詢
• 高峰時 alert freshness gap 擴大、值班用過期資料

反模式

交接路由

• 4.6 SLI/SLO：SLI metric 的 cardinality 上限
• 4.8 signal-governance-loop：高峰 retrospective 回寫治理
• 4.11 telemetry pipeline：pipeline 層 quota 執行
• 4.12 audit log governance：audit 保留期銜接
• 4.15 cost attribution：成本治理的責任分配層
• 4.23 觀測查詢設計：storage tiering 對查詢能力的完整設計
• 6.9 容量成本：observability 成本作為容量規劃輸入
• vendors：各平台的 ingestion / query quota 模型

• 為何訊號需要治理閉環：alert / metric / dashboard 是會老化的資產
• 偵測缺口的來源：post-incident review、chaos test、日常 noise
• 訊號生命週期：新增 → 調整 → 淘汰
• Alert 健康度量測
• Dashboard 健康度量測
• 治理節奏與 ownership
• 反模式

概念定位

訊號治理閉環是把事故、演練與日常使用經驗回寫到觀測系統的流程，責任是讓 alert、metric 與 dashboard 隨服務變化而更新。

觀測資產會老化：服務拓撲會變、流量型態會變、告警接收者會離職或轉組。設定一次就不再動的 alert rule 會在數月後變成 noise 來源；建立一次就不再看的 dashboard 會累積成系統負擔。訊號治理把觀測系統當成需要持續維護的產品，而非建好就完成的基礎設施。

跟 4.4 dashboard-alert 的分工：4.4 處理設計（怎麼設計好的 dashboard 跟 alert），4.8 處理維運與淘汰（設計好之後怎麼讓它們持續有效）。

偵測缺口的來源

Post-incident review

每次事故的 post-incident review 都可能揭露偵測缺口 — 事故發生到被偵測到的時間太長、alert 觸發了但指向錯誤的方向、或根本沒有 alert 觸發。

偵測缺口的分類：

Post-incident review 的 action items 中標記為「detection gap」的項目，應該指派給觀測系統的 owner，帶明確的 metric / alert / dashboard 變更規格。

Chaos test 與演練

Chaos test 跟災難恢復演練會在受控條件下暴露觀測盲區。注入 dependency failure 後，觀測系統是否在預期時間內觸發 alert？Alert 是否指向正確的方向？Dashboard 是否有足夠的 panel 支援診斷？

演練揭露的盲區跟事故揭露的盲區性質相同，但成本更低 — 在受控環境發現的缺口不會拉長真實事故的 MTTR。

日常 noise 累積

Alert noise 的日常累積是漸進式的退化 — 每個月新增幾個 alert rule 但沒有淘汰舊的，noise rate 從 10% 慢慢升到 30% 再到 50%。退化的訊號是 on-call 工程師開始忽略某些 alert（先 ack 再看、或直接 resolve 不看）。

訊號生命週期

新增

新訊號的來源：新服務上線時的 readiness review 檢查、post-incident review 的 detection gap、chaos test 暴露的盲區、新功能上線時的 SLI 定義。

新增訊號時要同時定義：metric / alert 的 owner、預期的 noise rate baseline、review 週期、淘汰條件。沒有 owner 跟 review 週期的訊號會在累積後變成治理負擔。

調整

調整的觸發條件：alert threshold 跟當前 baseline 偏差過大、dashboard panel 的資料來源（metric name、label）已改變、alert 的 runbook link 過期、noise rate 超過團隊可接受的上限。

調整是訊號治理的主要日常工作。多數訊號不需要刪除，但需要隨服務演進跟著更新。

淘汰

淘汰的觸發條件：alert rule 超過 N 天（例如 180 天）沒有觸發、dashboard 超過 N 天沒有人訪問、metric 被 recording rule 取代後原始查詢不再使用、服務已下線但 alert / dashboard 還在。

淘汰需要 owner 確認。自動淘汰（超過 180 天不觸發就自動刪除）風險太高 — 有些 alert 本來就是極低頻但極高價值（年度高峰才觸發的 capacity alert）。安全做法是自動標記候選淘汰，由 owner 在定期審視中決定保留或刪除。

Alert 健康度量測

Alert 的健康度用四個指標追蹤：

Noise rate：不需要行動的 alert / 總 alert。On-call 在 ack 時標記 actionable / noise。月度彙整。目標：< 30%。

MTTD（Mean Time to Detect）：事故開始到 alert 觸發的時間。從 incident timeline 回溯。目標：跟 SLO burn rate window 對齊（急性問題 < 5 分鐘）。

False positive rate：alert 觸發但事後確認沒有問題 / 總 alert。跟 noise rate 不同 — noise 包含 redundant alert（有問題但重複），false positive 是真的沒問題。

Coverage：有 alert 覆蓋的 user journey / 總 user journey。未覆蓋的 user journey 代表潛在的偵測盲區。

Dashboard 健康度量測

Dashboard 的健康度用三個指標追蹤：

訪問頻率：每個 dashboard 的每週 / 每月訪問次數。Grafana 的 usage analytics 或 access log 可以提供。長期零訪問的 dashboard 是候選淘汰。

Data freshness：Dashboard panel 是否顯示有效資料。Panel 因 metric name 改變或 label 漂移而回空值時，曲線看起來是平的零線 — 容易被誤讀成「一切正常」。定期掃描所有 panel 的 no-data 狀態。

Owner coverage：有 owner 的 dashboard / 總 dashboard。沒有 owner 的 dashboard 沒人負責更新，退化只是時間問題。

治理節奏

訊號治理需要固定節奏，避免「只在事故後才補訊號、平時不管」的反應式治理。

事故驅動（每次事故後）：Post-incident review 的 detection gap action items 在兩週內 close — 新增 / 調整的 metric、alert、dashboard 已部署並驗證。

定期審視（每季）：

• Alert noise rate 報告：noise rate > 30% 的 alert rule 進入調整或淘汰流程
• Dashboard 訪問頻率報告：零訪問 dashboard 進入淘汰審視
• Orphan alert / dashboard（owner 離職或轉組、未交接）指派新 owner

年度回顧：

• 觀測覆蓋率（有 instrumentation 的服務 / 總服務）
• SLI / SLO 的量測點跟閾值是否需要調整（業務變化、流量變化）
• 觀測成本 vs 事故成本的 ROI 評估

核心判讀

判讀訊號治理時，先看缺口是否有來源，再看改善項是否真的關閉。

重點訊號包括：

• Post-incident review 是否把偵測缺口轉成具體 metric / alert / dashboard 變更
• Chaos test 或 DR 演練是否暴露新的觀測盲區
• Alert noise、ack time、false positive 是否有趨勢追蹤
• Orphan dashboard 與過期 alert 是否有定期清理節奏

判讀訊號

• Alert 數量只增不減、無淘汰流程
• Alert noise rate > 30%、ack 後無實際動作
• Dashboard 半年無人訪問、仍存在於主目錄
• Post-incident review action items 大半 open > 90 天
• 同類事故重複發生、觀測系統無更新
• Alert owner 離職後無人接手、alert 成為孤兒

反模式

交接路由

• 4.4 dashboard-alert：alert / dashboard 的設計原則
• 4.5 威脅建模：告警失真作為觀測弱點
• 4.7 cardinality：新訊號的成本邊界
• 4.14 anomaly detection：anomaly false positive 的淘汰
• 4.16 readiness review：上線前的觀測覆蓋檢查
• 4.18 operating model：ownership 矩陣
• 8.5 post-incident review：action items 回寫機制
• 8.11 閉環：跨模組視角的閉環

• Continuous profiling 的定位：metrics / logs / traces 之外的第四角
• Profile 維度：CPU、heap、allocations、lock contention、goroutine / async task
• Always-on vs on-demand：何時用哪種
• Flame graph 與版本差異比較
• Overhead 控制
• Vendor 定位
• 反模式

概念定位

Continuous profiling 是把 CPU、memory、allocation 與 lock contention 變成長期可比較的 production 訊號，責任是補上 metrics、logs、traces 看不到的 callstack 成本。

Metrics 會告訴你「CPU usage 上升了」，trace 會告訴你「這條 request 的 latency 從 200ms 變成 800ms」，profile 會告訴你「增加的 600ms 花在哪幾個 function call、哪幾行程式碼」。Profile 是唯一能精確到 callstack level 的觀測訊號。

「Continuous」的關鍵差異是：傳統 profiling 是事故時才手動開啟，continuous profiling 是 production 常駐的低開銷採樣。事故時不需要重現問題 — baseline profile 已經在那裡，直接跟事故期間的 profile 做 diff。

Profile 維度

不同的 profile 維度回答不同的效能問題。服務的退化模式決定需要哪些維度。

CPU profile

回答「CPU 時間花在哪些 function」。最常用的 profile 維度。適合診斷 latency 退化（某個 function 開始佔更多 CPU 時間）跟 CPU 利用率異常（某段程式碼意外進入 hot path）。

CPU profile 用 sampling 方式採集 — 定期（例如每秒 100 次）記錄當前的 callstack。統計意義上，出現在 sample 中的次數跟實際 CPU 消耗成正比。Sampling 頻率越高精度越好，但 overhead 也越高。

Heap / memory profile

回答「memory 被哪些 function 持有」。適合診斷 memory leak（allocation 持續增長、GC 回收不了）跟 GC pressure（大量短命物件導致 GC 頻繁）。

Heap profile 記錄的是某個時間點的 live object 分布。Allocation profile 記錄的是一段時間內誰做了多少 allocation — 兩者互補。Memory leak 用 heap profile 的時間趨勢看；GC pressure 用 allocation profile 看。

Lock contention profile

回答「哪些 lock 的等待時間最長」。適合診斷 mutex contention（多個 thread / goroutine 搶同一把 lock、等待時間累積成 latency）。

Lock profile 在高並發服務的診斷中特別有用。Metrics 只能看到整體 latency 上升；trace 能看到某個 span 變慢；lock profile 能精確定位是哪把 lock 在哪個 callstack 被等待。

Goroutine / async task profile

Go 的 goroutine profile 回答「有多少 goroutine、它們在做什麼（running / waiting / blocked）」。Goroutine leak（goroutine 數量持續增長、都在等待某個 channel 或 lock）是 Go 服務常見的退化模式。

其他語言有對應的概念：Java 的 thread dump、Node.js 的 async resource tracking、Python 的 asyncio task inspection。

Always-on vs On-demand

Always-on（continuous）

Production 常駐的低開銷 profiling。CPU sampling 頻率降低（每秒 19 或 100 次，避免跟系統 timer 共振），heap sampling 用語言 runtime 內建機制（Go 的 runtime/pprof、Java 的 JFR）。

Always-on 的核心價值是 baseline — 平時就有 profile 資料，事故時可以跟 baseline 做 diff，看「哪些 function 的 CPU 消耗跟平時不同」。沒有 baseline 的 profiling 只能看「現在的 profile 長什麼樣」，無法判斷哪些是異常的。

On-demand

事故中或效能調查時手動開啟的高精度 profiling。Sampling 頻率更高、涵蓋更多維度、但 overhead 也更高（可能影響 production 服務的 latency）。

On-demand profiling 適合在 always-on profile 定位到可疑 function 後，做更細粒度的 callstack 分析。兩者搭配使用 — always-on 做日常監控跟 baseline，on-demand 做事故深挖。

Overhead 控制

Continuous profiling 的可行性取決於 overhead 是否夠低。目標是 CPU overhead < 1%、memory overhead < 10MB。

影響 overhead 的因素：

• Sampling 頻率：CPU profile 每秒 100 次 vs 1000 次，overhead 差一個數量級
• 採集機制：eBPF-based profiler（Parca、Pyroscope eBPF）在 kernel 層採集，overhead 比 language-level profiler 低；language runtime 內建機制（Go pprof、Java JFR）overhead 居中；instrumentation-based profiler overhead 最高
• 資料傳輸：profile 資料定期傳到 backend 的網路跟序列化成本

Production 部署前要用 benchmark 驗證 overhead。在 load test 環境開啟 profiling、比較開啟前後的 latency p99 跟 CPU usage — 差異超過 1% 要調整 sampling 頻率或換更輕量的 profiler。

Flame Graph 與版本差異比較

Flame graph

Flame graph 是 profile 資料的標準視覺化。X 軸是 callstack 的寬度（代表 sample 佔比 = 資源消耗佔比），Y 軸是 callstack 深度（底部是 root function、頂部是 leaf function）。寬的矩形代表消耗多、窄的代表消耗少。

讀 flame graph 的方式是「從寬的開始看」— 最寬的矩形是當前最大的資源消耗者。如果某個 function 佔整個 flame graph 的 40%，它就是最值得最佳化的候選。

Diff flame graph

Diff flame graph 是兩個 profile 的差異視覺化。紅色代表新版本消耗增加、綠色代表減少。適合用在：

• 版本間比較：v1.2.3 vs v1.2.4 的 CPU profile diff，看新版本哪些 function 變慢
• Canary 對照：canary instance vs baseline instance 的即時 diff
• 事故 vs baseline：事故期間的 profile vs 平時的 profile

Diff flame graph 需要 profile 帶 version / deploy label。Profile 跟版本標記失聯時，跨版本比較只能靠手動對照時間範圍 — 精確度跟效率都會下降。

Vendor 定位

選擇要點：如果已有 Grafana 生態（Prometheus + Loki + Tempo），Pyroscope 整合最自然。如果不想改 application code（零 instrumentation），eBPF-based 的 Parca 是選項。如果已用 Datadog APM，Datadog Profiler 跟 trace 的整合（從 trace span 跳到對應的 profile）是獨有優勢。

核心判讀

Continuous profiling 的持續價值取決於兩件事：profile 能否按版本做 diff（沒有 baseline 就無法判斷哪些 callstack 是異常的），以及 overhead 能否低到 production 常駐（overhead 過高等於回到「事故時才開」的模式）。

重點訊號包括：

• Profile 是否帶有 service、version、environment 與 deploy label
• Flame graph diff 是否能對照 canary / baseline
• CPU、heap、lock、allocation 是否覆蓋主要退化模式
• Production sampling 是否足夠低成本且常駐穩定

判讀訊號

• 同一段熱點程式碼反覆出現在事故 RCA 中、無 baseline profile
• CPU / memory 異常時靠重現除錯、無 production profile 可對照
• 版本升級後 latency 退化、定位具體 callstack 需要重現環境
• Profile 跟 commit / version label 失聯、跨版本 diff 需要人工對照
• Profiling overhead 過高、production 環境常駐成本過高

反模式

交接路由

• 4.2 metrics：metrics 是聚合訊號、profile 是 callstack 級別
• 4.3 tracing：trace 是 request 維度、profile 是 process 維度
• 4.7 cardinality / cost：profile 儲存量與保留策略
• 4.21 rule-level CPU signal：規則執行成本的 CPU 訊號治理
• 8.5 post-incident review：RCA 引用 profile flame graph

• Server-side 觀測的盲區
• RUM（Real User Monitoring）：真實用戶端訊號
• Synthetic monitoring：主動探測
• Core Web Vitals 與 backend SLI 的整合
• Client trace 跟 server trace 的串接
• Vendor 定位
• 反模式

概念定位

Client-side、Synthetic 與 RUM 訊號是把使用者實際感知納入觀測系統的資料來源，責任是補上 server-side 指標看不到的網路、瀏覽器、地區與裝置差異。

服務端 200 率正常只代表 backend 有回應。使用者是否真的能完成操作，還要看 DNS 解析、CDN 快取、ISP 路由、瀏覽器渲染與 client-side JavaScript 執行。這些環節每一個都可能讓使用者的體驗跟 server-side dashboard 顯示的完全不同。

跟 monitoring 模組 的分工：monitoring 模組聚焦「非 server 端 runtime 的監控體系」（SDK 設計、collector 架構、rule engine）；本章聚焦「backend 觀測系統如何整合 client-side 訊號」。交叉點是事件格式跟 transport。

Server-side 觀測的盲區

Server-side 觀測能看到「request 到達 server 之後發生了什麼」，看不到「request 到達 server 之前」跟「response 離開 server 之後」的環節。

這些盲區意味著 server-side 的「一切正常」跟使用者的「用不了」可以同時存在。

RUM（Real User Monitoring）

RUM 在使用者的瀏覽器或 app 中嵌入監控 SDK，收集真實使用者的效能跟錯誤資料。跟 synthetic monitoring 的差異是 RUM 看的是真實流量，能反映真實的地理分布、裝置差異跟網路條件。

核心指標

頁面效能：First Contentful Paint（FCP）、Largest Contentful Paint（LCP）、Cumulative Layout Shift（CLS）、Interaction to Next Paint（INP）。這四個指標（Core Web Vitals 系列）是 Google 定義的使用者體驗量化標準。

JS error：未捕獲的 exception、promise rejection、resource loading failure。RUM SDK 自動攔截（window.onerror、unhandledrejection），帶 stack trace、browser info、page URL。

API call 效能：從 client 端量測的 API latency（包含 DNS + TCP + TLS + server processing + response download）。跟 server-side 量測的差異就是網路延遲跟 client 處理時間。

切分維度

RUM 資料的價值在於可以按維度切分：地區（哪個國家 / 城市慢）、裝置（mobile vs desktop、iOS vs Android）、網路型態（4G vs wifi vs 3G）、瀏覽器（Chrome vs Safari vs Firefox）。

切分後的資料能回答 server-side 回答不了的問題：「為什麼巴西的使用者比美國慢 3 倍？」（CDN 沒覆蓋巴西）、「為什麼 Safari 的 error rate 比 Chrome 高？」（某個 JS API 在 Safari 的行為不同）。

取樣與成本

RUM 的事件量跟使用者流量成正比。高流量網站的 RUM 資料量可能很大（每秒數千筆 page view + error + resource timing），成本隨之上升。

RUM 的取樣策略跟 server-side trace sampling 類似：可以全收（低流量網站）、按比例取樣（高流量）、或按條件取樣（error 全收、正常 page view 取樣）。取樣後的資料仍能看到趨勢跟 percentile，但個別 session 的完整 replay 需要該 session 被取樣到。

Synthetic Monitoring

Synthetic monitoring 用自動化的 probe 從外部網路定期發起請求，測量 availability 跟 latency。跟 RUM 的差異是 synthetic 是主動探測（沒有真實使用者也能跑），能 24/7 持續監控。

適用場景

Availability 探測：每分鐘從多個地區對關鍵頁面或 API endpoint 發 request，確認可達性。DNS 異常、CDN 故障、TLS 過期 — 這些 server-side 看不到的問題，synthetic probe 能第一時間抓到。

SLO probe：用 synthetic probe 量測關鍵 user journey 的端到端 latency（login → homepage → checkout），作為 SLO 的 client-side 量測點。

Third-party 依賴監控：探測 payment gateway、SSO provider、CDN 的可用性。這些外部依賴故障時 server-side 只能看到 timeout 或 error code，synthetic probe 能從使用者的角度看到完整影響。

常見陷阱

Synthetic probe 的探測路徑必須跟真實使用者一致。Probe 從 datacenter 內部發 request、走內部 DNS、不經過 CDN — 這種 probe 量到的 latency 跟 availability 不代表真實使用者的體驗。

Probe 應該從外部網路、經過公開 DNS、經過 CDN / edge、用真實 browser（headless Chrome）渲染頁面。Catchpoint、Pingdom、Datadog Synthetic 都提供從多個公開地理位置發 probe 的能力。

Core Web Vitals 與 Backend SLI 的整合

Core Web Vitals（LCP、CLS、INP）是 client-side 的使用者體驗指標。Backend SLI（availability、latency p99）是 server-side 的服務健康指標。兩者各自反映不同層面、需要整合看才能得到完整圖像。

整合方式是在 dashboard 上並排顯示：backend SLI panel 旁邊放 RUM 的 LCP / INP panel。當 backend latency 正常但 LCP 退化，問題在 frontend rendering 或 CDN；當 backend latency 升高且 LCP 同步退化，問題在 backend。

4.6 SLI/SLO 設計 的 user-journey-centric SLI 應該同時考慮 server-side 跟 client-side 的量測點。只看 server-side 的 SLI 會低估使用者實際感知的延遲。

Client Trace 跟 Server Trace 的串接

RUM SDK 跟 backend 的 trace 串接讓一個 user action 的完整路徑可追蹤 — 從 button click 到 browser 發 API request 到 backend 處理到 response rendering。

串接方式是 RUM SDK 在發起 API request 時注入 trace context header（W3C traceparent）。Backend 的 trace instrumentation 提取 header、建立 child span。完整的 trace waterfall 從 browser span 開始、經過 backend span、到 database span。

串接的條件是 RUM SDK 跟 backend SDK 使用相同的 trace context format。OTel 生態（browser SDK + backend SDK）天然支援；混用 vendor 時需要確認 header format 一致。

Vendor 定位

選擇要點：已有 APM vendor 的團隊優先用同 vendor 的 RUM（trace 串接最自然）。只需要 availability probe 的用 Pingdom 或 Synthetic 功能。需要 session replay（重現使用者操作序列）的選 Datadog RUM 或 Sentry。

核心判讀

判讀 client-side monitoring 時，先看訊號是否代表真實使用者，再看 synthetic probe 是否覆蓋關鍵旅程。

重點訊號包括：

• RUM 是否能按地區、裝置、網路型態與瀏覽器切分
• Synthetic probe 是否從外部網路與真實入口進入
• Core Web Vitals 是否能和 backend SLI 並排比較
• Client trace / session 是否能和 server trace 串接

判讀訊號

• 使用者回報慢但 server-side latency 正常
• CDN / edge 故障時內部 dashboard 全綠
• 行動弱網場景無 visibility、僅有 wifi 桌面端訊號
• Synthetic probe 從 datacenter 內部跑、路徑跟真實使用者不同
• 客戶投訴定位耗時長、無 client 端 trace / RUM session

反模式

交接路由

• 4.6 SLI/SLO：user-journey-centric SLI 需要 client-side 量測點
• 4.3 tracing：client trace 跟 server trace 的 context 串接
• 05 部署：CDN / edge 配置變更影響 RUM 訊號
• 08 incident response：客戶感知影響量化
• Monitoring 模組：非 server 端的監控體系設計
• 4.24 Client-to-Server 觀測串接：從 browser click 到 server span 的完整 trace 鏈路實作

• 為何要把 telemetry 當 pipeline 看：每層有獨立失敗模式與成本邊界
• 分層責任：agent（採集）、collector（聚合 / 轉換）、ingest（寫入 buffer）、storage（保留 / 查詢）、query（dashboard / alert）
• buffer 與 backpressure：collector 端緩衝、ingest 滿時的降級策略
• OpenTelemetry Collector 的角色：vendor-neutral 中介層
• pipeline 失敗時的 graceful degradation：訊號斷一層、其他層仍可用
• multi-tenant 環境的 quota / 隔離
• 觀測遷移流程：先換 collector 再換 instrumentation、雙軌期保留對照
• 跟 4.7 cardinality 的分工：4.7 是治理輸入、4.11 是 pipeline 執行
• 反模式：pipeline 是黑盒、無 self-monitoring；agent 直連 vendor 無 collector 中介；ingest 滿時直接 drop 無告警

概念定位

Telemetry pipeline 是把訊號從 service process 帶到查詢與告警面的資料路徑，責任是讓採集、轉換、寫入、儲存與查詢各層都有可觀測的邊界。

這一頁處理的是觀測系統本身的可靠性。當 pipeline 是黑盒，訊號消失時團隊需要額外排查服務是否真的沒事件，或 agent、collector、ingest、query 哪一層失效。

Pipeline 視角的另一個價值是把採集策略跟儲存後端解耦。應用層只需要產生標準訊號，pipeline 處理 schema 轉換、sampling、enrichment、routing 與 vendor 對接；當儲存後端或 vendor 改變時，應用層不必重新 instrument。

分層責任與失敗模式

Pipeline 各層責任不同，失敗模式也不同。把 pipeline 視為單一黑盒會讓事故定位停在「訊號不見了」這層觀察，無法回答是哪一層的問題。

Agent 層的關鍵風險是部署綁定。若 agent 跟應用同進程，升版需要重啟服務；若 agent 是獨立 DaemonSet 或 sidecar，升版可以獨立進行，但要承擔網路與資源額外開銷。Agent 自身故障時，service 看起來健康，dashboard 看起來空，事故指揮會把這個空白誤讀成系統靜默。

Collector 層是 pipeline 最有彈性的地方，也是最容易漏掉自我觀測的地方。OpenTelemetry Collector 的 receiver / processor / exporter 各自有 metrics，部署時要把這些 metrics 自身送回觀測平台。配置漂移是長期維護的主要失敗：sampling 規則改了沒紀錄、attribute 重命名沒同步、tail sampling decision window 縮短，都會讓下游看到的訊號跟以前不同。Collector 的三種部署位置（agent / gateway / sidecar）與 pipeline 設計細節見 OTel Collector 部署模式。

Ingest 層的失敗模式集中在容量邊界。當 vendor 端 quota 觸發或內部 queue 滿，ingest 會回 429 或直接丟棄；應用層通常無感、dashboard 顯示流量下降。這層需要把拒收事件本身變成告警訊號、讓事故定位即時看到拒收量、避免靠事後對賬發現。

Storage 跟 query 層的失敗多半是漸進式：保留策略誤刪、查詢隨時間退化、索引隨流量膨脹。這類失敗不會在當下觸發告警，要靠週期性審視 storage size、query latency 與 retention compliance 才能發現。

Buffer 與 Backpressure

Buffer 是 pipeline 吸收瞬時尖峰的緩衝，責任是讓 collector 跟 ingest 在後端短暫故障或速率不足時仍保住高價值訊號。

• In-memory queue：吸收秒級尖峰、容量小、process 重啟會丟。
• Persistent queue（local disk、Kafka）：吸收分鐘到小時級積壓、有持久性、需要額外運維成本。
• Spillover storage（S3 等冷儲存）：當 hot path 滿載時，把低優先訊號暫存到便宜後端、之後 replay。

Backpressure 策略決定 buffer 滿時的行為。block 策略會讓上游採集慢下來、可能影響應用；drop oldest 跟 drop newest 各自影響 timeline 的開始或結束；sample-by-priority 則保留錯誤、長尾與低流量樣本、丟棄一般成功 request。Buffer 跟 backpressure 策略要在容量規劃階段顯式設定、進 release flow、避免事故時臨時拍定。

Buffer 對事故判讀的影響是 freshness。當 buffer 累積分鐘級資料時，dashboard 看到的指標其實落後當前狀態；incident commander 看到 error rate 下降時，需要知道是真的恢復還是 buffer 尚未排空。把 buffer depth 跟 ingest delay 暴露成 dashboard 指標，能避免事中決策建立在過期資料上。

Buffer 跟 backpressure 怎麼選：低延遲容忍 + 容量充足的場景用 in-memory queue + drop oldest（保留最新狀態）；高訊號完整性需求（例：audit log、事故證據）用 persistent queue + block 或 sample-by-priority；高流量爆量但允許部分遺失（例：debug log）用 spillover storage + drop newest。事故時的回退路徑是「在 backpressure 政策中先標明哪類訊號絕對保留、哪類訊號可丟」、避免事故當下臨時決定。

OpenTelemetry Collector 的中介定位

OpenTelemetry Collector 把採集、轉換與 routing 從應用程式抽離，責任是讓觀測 vendor 跟採集 SDK 各自演進。

Collector 在 pipeline 中扮演三個角色：

1. Vendor-neutral 中介：應用層只需 export OTLP，collector 端決定要不要把資料同時送到多個後端（Datadog、Honeycomb、self-hosted Prometheus）。切換 vendor 時不需要改應用層。
2. Schema / sampling 集中治理：attribute 重命名、敏感欄位 redaction、tail sampling decision、cardinality 限制都集中在 collector，不分散在每個服務。
3. Topology 適配層：collector 可以部署為 sidecar（與應用同 Pod）、DaemonSet（每個 node 一份）或 gateway（集中接收）。不同部署形態適合不同規模與隔離需求，並不互斥；大型部署常見「應用 → sidecar → cluster gateway → 後端」的多級拓樸。

對應 4.C5 Cloud Trace OTLP 導入：標準化傳輸協定降低跨環境的 instrumentation 重複，揭露「資料通道標準化」是觀測平台轉換的常見起點。對應 4.C6 ADOT on EKS 管線遷移：多代理混用在規模化時放大配置漂移，揭露 collector 集中治理的營運價值。兩個案例的具體實作差異留給原案例，本章關注的是 collector 在 pipeline 中的責任邊界。

觀測遷移的執行順序

觀測遷移的執行順序決定短期雙軌成本能否轉化為長期語意一致性。把替換風險限制在採集中介層、是先換 collector / agent、再換應用層 instrumentation 的設計理由。

可重複套用的順序是先換採集中介、再換採集點：

1. 先換 collector / agent：把 collector 從 vendor-specific 換成 vendor-neutral（如 OTel Collector），同時保留舊 vendor 的 exporter，讓資料同時送到新舊後端。這層替換對應用層無感，可以快速完成。
2. 建立雙軌對照：以新舊後端對照 SLI 是否一致（query 設計、偏差閾值、退出條件等對照細節由 4.17 telemetry data quality 處理）、差異超過閾值時停止下一步。
3. 逐步改應用端 instrumentation：把應用層的 vendor-specific SDK 換成 OTel SDK，分服務分批進行。每批切換後重跑對照驗證。
4. 以對照驗證進入 release gate：在 release pipeline 加上「新舊管線 SLI 偏差」檢查，作為遷移階段的閘門。對照穩定後才能關閉舊管線。

執行順序的設計理由：collector 是 vendor-neutral 抽象、可以雙軌並存承受對照成本；應用層 instrumentation 改動會跨眾多 service team、變更面廣、要在 collector 對照穩定後才大規模推進。把次序反過來容易在 instrumentation 全面改完才發現 collector 抽象有缺失、被迫重做。

對應 4.C4 X-Ray 到 OpenTelemetry 轉換：揭露「先 collector 後 instrumentation」的階段切換方向。對應 4.C7 Datadog OTel 相容遷移實務：揭露「雙軌期成本跟語意漂移是遷移期主要風險」（單一 agent 安裝是次要議題）。本章關注的是執行順序，schema drift 跟資料品質的對照驗證細節由 4.17 處理。

規模差異下的遷移節奏

遷移節奏由團隊規模、可承受雙軌成本、配置漂移風險與治理成熟度共同決定。本段聚焦遷移期的節奏取捨；常態 ownership 配置由 4.18 規模差異下的角色配置 處理，兩者 lens 不同。

對應 4.C10 規模差異下觀測遷移：揭露三種規模團隊的失敗模式骨架；以下三段的具體操作做法均屬通用工程知識展開、case 本身只列方向。

小團隊的核心風險是雙軌維護消耗人力。同時看兩套 dashboard、雙倍 alert noise、雙倍 on-call 負擔，很容易讓遷移本身拖累業務維運。小團隊適合用「短期對照、快速收斂」策略：把對照期壓到一個迭代週期內，固定一個服務作為先導，把問題在小範圍內收斂，再快速複製到其他服務。

中型團隊的失敗模式集中在 schema 漂移。服務數量增加後，attribute 命名一致性、service name 規約、label cardinality 邊界容易在雙軌期擴散。中型團隊要在遷移開始前先固化 semantic convention，並在 collector 層自動校驗；不固化會在遷移後拼湊出多套互相矛盾的 dashboard。

大型團隊的主要失敗集中在治理面：collector 拓樸（sidecar / DaemonSet / gateway 的選擇）、sampling 政策、成本分攤、tenant 隔離都會在遷移後顯著影響成本與告警品質。大型團隊用「pilot region 先行、其他 region 批次跟進」策略、把 collector 配置版本化、變更接到 release gate。大型團隊的回退單位通常是 region 或 tenant 群、不是整體切回。

三類團隊的共同教訓是：先決定「何時可以關閉舊管線」的退出條件，再開始遷移。沒有退出條件的雙軌會無限期延長，最後在成本壓力下被動關閉，反而失去對照驗證的能力。

遷移漂移的回退判讀

漂移回退的責任是把降級決策權跟資料採集分離、讓回退保留可分析的對照證據。直接關閉新管線會失去漂移原因的線索、後續再遷移容易出同樣的事故。

對應 4.C9 OTel 遷移訊號漂移反例：揭露遷移失敗的主要型態是語意漂移、回退要保留對照證據。

漂移發生時，主要訊號是「兩套儀表板看似都有資料、但對同一事故的判讀不同」。新舊管線對同一服務的 error rate 長期偏離、missing span 或 missing metric 比例上升、alert 噪音增加但事故量沒對應增加，都是漂移在 pipeline 層的表現。

回退判讀的核心是分辨「遷移問題」跟「服務問題」。比較穩定的回退節奏：

1. 先停止讓新管線主導告警跟 SLO 判定，把告警入口切回舊管線。
2. 保留新管線採集、但只作為對照證據，不參與決策。
3. 用對照資料找出語意漂移點（attribute 名稱、sampling 規則、aggregation 視窗），分項修正。
4. 修正後重新進入雙軌對照、確認偏差收斂、再讓新管線恢復主導。

這個流程把回退視為降級決策權的釋放、而非整體關閉訊號採集。把回退做成可重播流程，下次遷移才能避免在錯誤訊號上做服務回退。

Multi-tenant 與 Quota

Pipeline 的多租戶治理責任是讓單一服務或團隊的爆量不會拖累其他租戶。沒有租戶隔離時，單一服務的 cardinality 爆炸或 sampling 失控會直接耗盡 pipeline 容量。

可操作的隔離手段：

• Ingestion quota per tenant：限制單一服務的 ingest rate，超過時觸發降級或退單。
• Buffer 與 storage 分區：高優先 tenant 使用獨立 buffer 或 storage shard，避免 noisy neighbor。
• Sampling 政策 per tenant：成本敏感 tenant 走較高採樣比例，關鍵 tenant 走 minimum sample floor。
• Cost attribution：把 ingestion、storage、query 成本拆到 tenant，回到 4.15 cost attribution。

Quota 觸發時的告警設計比 quota 本身更重要。沒有告警的 quota 等於沒有 quota，因為觸發後訊號靜默，事故定位會把靜默誤讀為系統穩定。

讀取路徑作為 pipeline 的延伸

Pipeline 的分層敘事（agent → collector → ingest → storage → query）在 query 這層停得太早。寫入路徑的資料從 agent 流到 storage 是單向的；讀取路徑從 query engine 向 storage 發起請求，方向相反、效能瓶頸不同、治理責任也不同。把 query 視為 pipeline 的終端消費者而非獨立系統，才能完整理解觀測資料的生命週期。

Query engine 的責任邊界

Query engine 在 pipeline 中的責任是把儲存層的資料轉換成使用者可操作的回應。這包括 query planning（決定掃描哪些 shard、哪些 tier）、聚合計算（rate / sum / quantile）、結果快取與 query 排程。

Query engine 的設計取捨跟儲存層不同。儲存層追求寫入吞吐與持久性；query engine 追求查詢延遲與併發能力。兩者獨立擴展 — 寫入量大但查詢量小的場景，storage 需要更多容量但 query engine 不需要；反過來，dashboard 多但寫入量穩定的場景，query engine 需要更多 CPU 但 storage 不需要。

Query-time 的資源隔離

Query engine 服務三種查詢模式：alert rule evaluation（系統關鍵、定期、不可延遲）、dashboard 刷新（高頻、穩定、可容忍短暫延遲）、即席診斷（偶發、突增、事故中最需要低延遲）。三者搶同一個 query engine 時，穩定的背景負載會擠壓突發的即席查詢。

資源隔離的可操作方式：

• Query priority：alert evaluation 最高、即席查詢次之、dashboard 最低。Alert 不能因為 dashboard 重查詢排隊而漏發。
• Query queue 分離：不同類型的查詢進不同的 queue，各自有併發上限。Thanos / Mimir 的 query-frontend 支援 query 分類與排程。
• Query timeout 差異化：alert evaluation 設短 timeout（跑不完就是問題）、即席查詢設中等 timeout、dashboard 的大範圍查詢允許較長 timeout。
• Query cost estimation：在查詢執行前估算掃描量，超過閾值的查詢降級或拒絕，避免單一 heavy query 拖垮整個 query engine。

Buffer lag 對查詢 freshness 的影響

寫入面的 buffer lag 會直接影響讀取面的 freshness。當 collector 或 ingest 端有分鐘級的 buffer 累積，query engine 讀到的是延遲過的資料。Dashboard 顯示的 error rate 可能反映的是兩分鐘前的狀態；incident commander 看到 error rate 下降，可能是 buffer 開始排空而非服務真的恢復。

把 buffer lag 轉成查詢面的可見指標是基本的設計要求。在 dashboard 上顯示「資料延遲：目前最新資料點是 N 秒前」，讓讀取者知道自己看到的資料有多新。當 lag 超過告警閾值，除了觸發 pipeline 健康告警外，dashboard 本身也應該標示警告狀態。

跨訊號類型的查詢設計見 4.23 觀測查詢設計。

核心判讀

判讀 telemetry pipeline 時，先看每一層是否有健康訊號，再看滿載時是否能降級。

重點訊號包括：

• agent、collector、ingest、storage、query 是否各自有 SLI
• buffer 與 backpressure 是否能保住高價值訊號
• multi-tenant quota 是否能隔離單一服務爆量
• collector 是否保留 vendor-neutral 的轉換空間
• 遷移期是否有雙軌對照、是否有退出條件

判讀訊號

• 訊號間歇性消失、需要人工判斷是 pipeline 還是 service 問題
• agent 升版需要 service 重啟、運維成本高
• ingest 拒收（429）發生時、應用層無感
• 切換 vendor 需要改所有 service 的 instrumentation
• pipeline 自身無 SLI、健康度靠經驗判斷
• 遷移期雙軌維護過久、退出條件不明

反模式

交接路由

• 4.7 cardinality / cost：pipeline 各層的 quota
• 4.17 telemetry data quality：雙軌對照的資料品質判讀
• 4.18 operating model：collector / pipeline 的 ownership 邊界
• 4.23 觀測查詢設計：讀取路徑的系統設計與資源治理
• 05 部署：collector 部署形態（DaemonSet / sidecar / gateway）
• 6.4 chaos：pipeline 故障模擬作為 chaos 場景
• 4.15 cost attribution：pipeline 各層的成本歸屬
• 4.C12 Cloudflare 內部觀測：大規模自建 pipeline 的三層能力設計

• audit log 跟 operational log 的本質差異：對象、不變性、保留、法規
• audit log 該記什麼：who / what / when / where / outcome、不可被應用層改寫
• 不變性保證：append-only storage、tamper-evident hash chain、independent retention
• PII 治理：log 中的 PII 偵測、data masking、tokenization、最小揭露原則
• 法規維度：GDPR / HIPAA / SOC2 / 個資法 對保留期與存取的要求
• 跨團隊存取證據連續性：避免責任鏈斷在團隊邊界
• 跟 4.1 log schema 的分工：4.1 是欄位設計、4.12 是治理邊界
• 跟 07 資安 的交接：稽核責任邊界
• 反模式：audit 跟 operational 混在同 stream；PII 直接打進 log；audit log 跟 application DB 同保留期

概念定位

Audit log 是把責任、授權與敏感操作留下可稽核證據的訊號，責任是支援合規、責任追蹤與安全事件調查。

這一頁處理的是 governance 邊界。Operational log 服務於除錯，audit log 服務於證據；兩者可以共享部分欄位，但保留、不變性、存取權限與 PII 規則不同。

Audit log 的治理優先序跟 operational log 相反。Operational log 優先服務 當下 的事故定位、追求即時性與覆蓋廣度；audit log 優先服務 未來 的責任追蹤、追求完整性、不變性與長期可查詢。當這兩種優先序衝突時，audit 治理要勝過 operational 便利性。

兩種 log 的責任分工

Audit log 跟 operational log 承擔兩條獨立治理鏈：前者服務證據與責任追蹤、後者服務除錯與事故定位。兩者在對象、保留、不變性、權限與粒度上的差異決定它們需要走分開的 pipeline、storage 與保留策略。把 audit log 視為 operational log 的子集、混在同一 stream 治理、會在第一次合規稽核或法規請求時讓證據鏈被打斷（典型徵兆是「靠 grep operational log 拼湊稽核需求」）。

Operational log 在 incident timeline 還原時是主力證據。它的失分容忍度高：丟掉 1% 的 log 通常不影響 root cause 分析。

Audit log 的失分容忍度極低。一次授權記錄遺失、一個欄位漂移、一段時區錯位，都可能讓事後責任追蹤失效。這個差異決定 audit log 必須走獨立 pipeline、獨立 storage、獨立保留策略。

核心欄位與不變性

Audit event 的核心責任是回答五個問題：誰（who）、做了什麼（what）、何時（when）、在哪（where）、結果如何（outcome）。任一欄位缺失，責任追蹤鏈就有缺口。

不變性保證有三層遞進：

1. Append-only storage：寫入後不可修改、不可刪除。一般 object storage（S3 Object Lock、GCS Bucket Lock）或 immutable database table 可實作。
2. Tamper-evident hash chain：每個 audit event 含前一個 event 的 hash，篡改任一筆會破壞整條 chain。需要週期性 anchor 到外部時間戳服務或第三方公證。
3. Independent retention：audit log 的保留期跟 application DB 解耦，application 刪資料不影響 audit。retention 由合規團隊定義、不由應用團隊調整。

對應 4.C1 FinTech 審計證據鏈：揭露「audit log completeness、event correlation integrity、retention policy drift」是合規場景的核心治理項目，本章關注的是治理邊界跟欄位設計，事件相關的 evidence 包裝由 4.20 處理。

跨團隊存取證據連續性

跨團隊 audit 治理的核心責任是維持責任鏈在團隊邊界上的連續性。應用團隊記應用層事件、基礎設施團隊記 infra 層存取、IAM 團隊記授權變更，三段證據各自必要、但只有拼接後才能還原一次跨團隊敏感操作。常見失敗來自團隊邊界上的責任鏈斷裂 — 而非單一團隊技術不到位 — 任一段缺失都會讓事後復盤無法閉合。

對應 4.C3 Healthcare 存取可追溯性與保留邊界：揭露「access evidence continuity、retention boundary violations、timestamp integrity」三個方向。Healthcare 場景把這個問題放大，但跨團隊存取連續性是所有合規場景的共同議題。

讓存取證據跨團隊連續的可操作做法：

1. 共用 correlation field：把 request id、trace id、session id 拉到應用層、infra 層、IAM 層共用，讓三段 log 可以拼起來。
2. 明確團隊 ownership 邊界：每類 audit event 指定唯一 owner team，避免「應該是另一隊負責」的責任轉嫁。
3. 跨團隊 retention 對齊：應用 audit、infra audit、IAM audit 的保留期要對齊或互為超集，避免一段過期一段還在的拼接斷裂。
4. 跨團隊查詢入口：合規團隊有單一查詢介面能跨三段 log 拉同一 correlation id 的完整證據鏈。

把這些做法寫進 4.18 operating model 的 ownership 矩陣，能避免單次合規請求引發跨團隊的拼接工作。

Retention 與保留策略漂移

Retention 是 audit log 跟 operational log 最大的治理差異。Operational log 通常用 30-90 天 rotation；audit log 依資料類型跟法規可能要 1-10 年。

把 audit log 跟 operational log 用同一條 retention 策略治理，會在合規稽核時被抓出來。常見的失敗：

• audit log 跟 application DB 同保留 90 天、不符 GDPR / HIPAA / 金融法規。
• audit log 經過 aggregation 處理、原始事件丟失、但 aggregated view 無法滿足法規要求。
• retention 策略由應用團隊調整、不經合規團隊審批、容易在成本壓力下被縮短。

Retention 漂移的偵測手段：把 retention compliance 變成可查詢的訊號。週期性對照各類 audit log 的實際留存時間跟政策要求、偏差超過閾值時觸發告警、讓漂移在治理週期內就被處理、避免等到稽核時才發現。

對應 4.C1 FinTech retention policy drift 跟 4.C3 Healthcare retention boundary violations：兩個案例的判讀訊號都把 retention 偏離列為一級訊號（兩 case 的表格行明示這點）；本章在此基礎上補上「偏離視為治理事件、retention compliance 變成可查詢訊號」的展開、屬章節推論。

保留階梯（hot / warm / cold tier）與成本歸屬的詳細設計見 4.7 控制面與保留階梯。

PII 治理與最小揭露

PII 在 log 治理裡是雙重風險：寫入時的合規風險、長期保留時的外洩風險。Audit log 的長保留期讓 PII 風險被放大。

可操作的 PII 治理層次：

1. 寫入前 redaction：應用層在輸出 log 時用結構化欄位 + 顯式 marking，避免把整個 request body 序列化進 log。
2. Pipeline 層 PII 偵測：collector 加上 PII pattern 偵測（信用卡號、身分證、token），預設遮罩、例外要顯式授權。
3. Tokenization / pseudonymization：把直接識別碼換成 token，token 跟原值的映射存在獨立、受嚴格授權的 vault 中。
4. 存取本身的稽核：誰存取了哪段 audit log、何時存取、為什麼存取，本身也是 audit event。

最小揭露原則的實作關鍵是「預設遮罩、需要時申請」。把預設值設成揭露，會在某次事故除錯為了方便而打開、之後忘記關閉。預設遮罩讓每次解碼都是可追蹤的事件。

核心判讀

判讀 audit log 時，先看事件是否能回答 who / what / when / where / outcome，再看資料是否受到獨立保護。

重點訊號包括：

• audit event 是否不可由一般應用流程修改
• PII 是否經過 redaction、tokenization 或最小揭露
• retention 是否符合法規與客戶合約要求
• security incident 與 operational incident 是否能引用同一條證據鏈
• 跨團隊存取的 correlation field 是否連續

判讀訊號

• 稽核需求出現時、靠 grep operational log 拼湊
• log 中發現 credit card / 身分證 / token 等 PII
• audit log 跟 application 同 retention（30 / 90 天）、不符法規
• 應用層帳號可寫入 / 修改 audit log
• 法規稽核請求耗時數週、事件鏈定位需要人工補洞
• 跨團隊查詢同一 correlation id 拼不出完整鏈

反模式

交接路由

• 4.1 log schema：欄位設計
• 4.7 cardinality / cost：audit 的長期保留成本
• 4.18 operating model：跨團隊 audit ownership 矩陣
• 4.20 evidence package：audit log 進入 evidence 交接
• 07 資料保護：PII redaction 與責任邊界
• 8.5 post-incident review：事故證據鏈引用 audit log
• 8.17 security vs operational IR：證據鏈來源
• 4.23 觀測查詢設計：鑑識回溯查詢模式跟 audit log 的長期查詢設計

• 為何依賴拓撲需要獨立節點：人工維護的依賴圖永遠過時
• 拓撲訊號的來源：trace（4.3）、service mesh（mTLS / sidecar）、network flow log
• 服務 graph 的維度：呼叫頻率、latency、錯誤率、版本
• 依賴變化告警：新增依賴、刪除依賴、依賴方向反轉
• blast radius 分析：上游失效時下游影響範圍預測
• 動態叢集下的拓撲追蹤：擴縮事件如何回寫拓撲訊號
• 跟 4.3 tracing 的分工：trace 是單 request、topology 是統計聚合
• 跟 05 deployment platform 的整合：service mesh 部署
• 反模式：架構圖只在 wiki 上、跟實際流量漂移；新依賴上線缺 review；拓撲圖回答「這服務掛了誰受影響」需要人工追查

概念定位

Service topology 是把跨服務依賴從文件轉成可觀測資料的能力，責任是讓團隊能用實際呼叫關係判斷依賴、影響面與變更風險。

這一頁處理的是服務關係圖。Trace 解釋單次 request、topology 解釋一段時間內的依賴結構；兩者合起來才能回答「這個服務壞了會影響誰」。

人工維護的依賴圖在快速變動的微服務環境下會持續漂移。新服務上線、舊服務下架、依賴方向反轉、版本切換都會發生在 wiki 圖更新之前；事故時依賴 wiki 圖判讀 blast radius，會把過期的依賴結構誤當成當前事實。

拓撲訊號的來源

Service topology 的可信度取決於資料來源是否反映真實流量。常見的訊號來源各有覆蓋範圍跟限制：

實務上常用組合：trace 作為主要來源（提供應用語意跟錯誤率），service mesh 作為補充（補上未 instrument 的服務），network flow log 作為兜底（揭露未管理的外部依賴）。

把不同來源的拓撲訊號合併時，要顯式記錄每段依賴的來源。當 trace 看不到某段依賴、service mesh 卻看得到時，可能意味著 instrumentation 缺失或服務 bypass mesh，這本身是治理訊號。

服務 Graph 的維度

服務 graph 的責任是把跨服務依賴量化成可判讀的訊號、支援事故決策跟容量規劃。每段依賴關係要帶上維度（頻率、latency、錯誤率、版本、可選性）、才能在事故時被直接使用、而非只能呈現拓撲輪廓。

• 呼叫頻率：高頻依賴跟低頻依賴的失效影響不同。高頻依賴失效會立即放大成 5xx，低頻依賴失效可能要數小時才浮現。
• Latency 分布：依賴 p50 / p99 latency 決定下游 timeout 應該設多少。沒有 latency 訊號的依賴圖無法支援 timeout 設計。
• Error rate：依賴的錯誤率提供 budget 訊號。當某依賴錯誤率上升，下游應觸發降級、保護自身可用性、避免進入無限重試放大故障。
• 版本 / API contract：依賴的版本變化跟 API contract 變更要進拓撲訊號。版本升級後若某段依賴消失，可能是 contract breaking。
• 方向跟可選性：是必要依賴（失效 = 服務失敗）還是可選依賴（失效 = 功能降級），影響事故分級。

這些維度進入拓撲訊號後，配合 6.14 dependency budget 才能把依賴可靠性變成可量化決策。

依賴變化的治理

依賴關係的變化本身是訊號。新增依賴、刪除依賴、依賴方向反轉，都是值得告警的事件。沒有依賴變化偵測時，新服務接入往往跳過依賴 review，事故發生才從 trace 反查到「原來這條 path 已經接了三個月」。

可操作的依賴變化告警：

1. 新增依賴 alert：當 trace 出現新的 service-to-service 呼叫，觸發 review。新依賴是否在預期內、是否經過 contract review、是否有 fallback。
2. 依賴消失 alert：某段穩定存在的依賴在 N 分鐘內 trace 看不到，可能是 instrumentation 漏、可能是上游被誤改、可能是真實事故的早期訊號。
3. 依賴方向反轉：A → B 變成 B → A 通常意味著 refactor 或誤改、應該觸發 review。
4. 循環依賴偵測：環狀依賴會在事故時放大恢復難度、應該在拓撲訊號層級就阻擋。

動態叢集下的拓撲訊號

動態叢集下拓撲訊號的責任是讓觀測模型追上實際依賴結構的變化。Pod 數量浮動、node 換代、service IP 變化、跨 cluster 流量重新分配都會在分鐘級內改變服務間的可達性、若拓撲訊號停留在週期性快照、事故時看到的會是過期結構。

對應 4.C8 Airbnb K8s 規模化下的觀測訊號治理：揭露「叢集擴縮跟工作負載變動需要回寫觀測模型」「叢集層指標跟服務層指標要分開治理」「擴縮事件跟事故關聯要可回溯」三個方向（case 直接列出）；以下展開的 service 層級節點、跨 cluster failover、drill-down 設計屬通用 K8s observability 經驗、case 本身未細說。

動態叢集對拓撲訊號的挑戰有三個面向、性質不同、各自的對應做法也不同。

拓撲節點不穩定 是資料模型層的問題。Pod 短暫存在、IP 不固定、若直接把 Pod 當拓撲節點、graph 會分鐘級持續抖動、事故時看到的依賴結構不可信。對應做法是把節點層級從 Pod / IP 提升到 service（service name + version + region）、把 instance / Pod 層級放到 dashboard drill-down、讓主拓撲圖反映穩定的服務依賴而非瞬時實例分布。

擴縮事件 vs 真實事故區分 是訊號分辨層的問題。HPA scale-up / scale-down、cluster autoscaler 加 node 失敗、Pod 重啟、health check 短暫失敗，這些擴縮動作本身會產生跟事故相似的訊號（5xx 短暫升高、reconnect、依賴連線中斷）、若沒分辨機制、值班會把擴縮過程的正常波動誤判成事故、或把真正的事故誤判成擴縮。對應做法是把擴縮事件本身打進 timeline、跟事故 timeline 共用同一張圖、判讀時對齊看。

跨 cluster 流量變化 是視角層的問題。multi-cluster 部署下、流量可能因 cluster 變更從 cluster A 切到 cluster B、若拓撲圖只看單 cluster 視角、B cluster 突增的流量會被解讀為 traffic spike、漏掉真正的 failover 事件。對應做法是讓拓撲圖呈現跨 cluster 邊界、把 cluster 間流量變化也標到圖上、避免 cluster 邊界成為觀測盲區。

把叢集層指標（node count、Pod count、HPA event）跟服務層指標（call rate、error rate、latency）分開治理，是動態叢集環境的基本要求。叢集層指標的 owner 通常是 platform team、服務層指標的 owner 通常是 service team，兩者放在同一 dashboard 上要清楚標示來源跟責任。

擴縮事件回溯到事故關聯的另一個價值是 capacity retrospective。當 HPA 在事故前後觸發、scale-up 是否足夠、scale-down 是否過快，都需要把擴縮 timeline 跟事故 timeline 拼起來看，回到 6.9 容量成本 跟 9.6 容量規劃 的回寫。

Blast Radius 推導

Blast radius 分析的核心責任是回答「如果這個服務或依賴失效、哪些上游 / 下游會受影響、影響多深」。沒有實時拓撲訊號時，這個分析靠經驗、容易低估或高估。

實時 topology 加上依賴可選性標記後，blast radius 可以分層推導：

• 直接下游：直接呼叫該服務的服務、立即受影響。
• 間接下游：透過中間服務間接依賴、影響時間延後。
• 可降級下游：依賴是 optional、失效會觸發降級但不失敗。
• 必要下游：依賴是 mandatory、失效會傳播成服務失敗。

事故時把 blast radius 從拓撲推導出來、再對照實際看到的 5xx 跟 SLO burn rate、能驗證影響面是否符合預期。當實際影響超出推導 blast radius、通常意味著存在未紀錄依賴。

核心判讀

判讀 topology 時，先看資料是否來自真實流量，再看依賴變化是否能被治理。

重點訊號包括：

• service graph 是否包含呼叫方向、頻率、latency 與 error rate
• 新增依賴是否能觸發 review 或 alert
• blast radius 是否能從上游 / 下游關係推導
• topology 是否能餵給 dependency budget 與事故型態判讀
• 動態擴縮事件是否打進 timeline、能跟事故區分

判讀訊號

• 事故時回答「誰呼叫這服務」需要人工追查
• 新服務接入無依賴 review、出事後才發現連結
• 架構文件跟實際呼叫關係漂移、半年沒更新
• service mesh 部署但拓撲訊號未被使用
• 循環依賴存在但無人發現
• 擴縮事件造成的短暫錯誤被誤判成事故

反模式

交接路由

• 4.3 tracing：拓撲訊號的原始來源
• 4.18 operating model：叢集層 / 服務層 ownership 分工
• 05 部署：service mesh 配置
• 6.5 pre-mortem（規劃中）：依賴失效路徑分析
• 6.9 capacity cost：擴縮事件 retrospective
• 6.14 dependency budget：拓撲是依賴可靠性評估的資料來源
• 8.9 事故型態庫：cascading failure 型態的拓撲依據

• Anomaly detection 跟 rule-based alert 的分工
• Baseline 模型類別
• Anomaly 訊號的處理路徑
• False positive 與 alert noise 共用預算
• Explainability：anomaly 要能定位到維度
• Vendor 定位
• 反模式

概念定位

Anomaly detection 是用統計基線或模型找出偏離常態的訊號，責任是補上 rule-based alert 難以事先列舉的變化。

Rule-based alert 抓已知模式 — 團隊事先定義「error rate > 1% 就告警」。Anomaly detection 抓未知模式 — 系統觀察到「今天的 latency 分布跟過去 30 天的同時段不同」。兩者互補：rule-based 精確但只能抓團隊已預見的問題，anomaly detection 有噪音但能發現團隊沒想到的退化。

Anomaly 適合作為提示層（hint），通常先進 dashboard 或低 severity 路由，再由 SLO 判讀或人工確認決定是否升級。把 anomaly 直接接 page 是噪音爆量的常見原因。

跟 Rule-based Alert 的分工

最有效的整合方式：rule-based alert 處理已知的 SLO violation（symptom-based、高 severity），anomaly detection 處理趨勢異常跟 novel failure mode（低 severity、dashboard widget）。兩者共用 alert fatigue 的 noise budget — anomaly 的 false positive 也算進整體 noise rate。

Baseline 模型類別

Seasonal baseline

按日夜、週末、節慶、促銷等週期建立基線。同一個指標的「正常範圍」在週一上午跟週日凌晨不同。Seasonal model 用歷史同期資料建立預期帶（expected band），偏離帶外視為 anomaly。

Seasonal baseline 的失敗模式是週期性假設錯誤 — 業務改變後流量模式跟歷史不同（新產品上線改變了週末流量），模型用錯誤的基線判斷。需要定期驗證模型跟實際流量的吻合度。

Moving window baseline

用過去 N 分鐘 / 小時的資料建立動態基線。比 seasonal model 簡單、延遲更低，但對突發變化更敏感（release 後 latency 自然變化可能觸發 anomaly）。

Moving window 適合不需要週期性建模的指標 — 連線數、queue depth、goroutine count 等「預期穩定、突變代表問題」的指標。

ML-based（forecast / clustering）

用機器學習模型做時間序列預測（Prophet、ARIMA）或高維度聚類（isolation forest、DBSCAN）。能處理複雜的多變量異常（A 指標上升 + B 指標下降 = 異常，但各自單獨看都在正常範圍）。

ML 模型的成本是訓練、retrain、模型版本管理跟 explainability。多數團隊的起步方式是先用 seasonal + moving window（不需要 ML pipeline），等 false positive 管理穩定後再引入 ML。

Anomaly 訊號的處理路徑

Anomaly detection 的輸出是「這個指標在這段時間偏離基線」— 候選訊號，不是確認的問題。處理路徑決定 anomaly 是有用的提示還是噪音來源。

Dashboard widget：anomaly 標記在 time series panel 上（標色、annotation），讓巡視 dashboard 的工程師注意到。低成本、零噪音（不通知任何人）、但需要有人主動看。

Low severity alert（info / warning）：anomaly 進入 alerting pipeline，但 severity 設為 info 或 warning。不 page on-call、但記錄在 alert history 中。事故發生後可以回溯「事故前有沒有 anomaly 提早預警」。

Conditional escalation：anomaly 搭配 rule-based 條件升級。「Latency 偏離基線 + error rate 超過 SLO burn rate」→ 升級為 critical。單獨的 anomaly 不足以 page，但跟其他訊號組合時有判讀價值。

Explainability

Anomaly 觸發時，工程師需要回答「為什麼異常」 — 是哪個服務、哪個 endpoint、哪個 tenant、哪個地區導致的。只告訴你「overall latency 異常」但不說維度，診斷價值有限。

可操作的 explainability 有兩層：

維度歸因：anomaly detection 系統自動拆分異常到子維度 — 「overall latency 異常，主要來自 region=us-east + endpoint=/api/search」。Datadog Watchdog 跟 New Relic AI 提供這種維度下鑽能力。

Root cause hint：anomaly 跟其他訊號（deploy event、config change、dependency error spike）的時間關聯。「Latency anomaly 開始的時間跟 v2.3.1 deploy 吻合」— 提示 root cause 可能跟 deploy 有關。

Vendor 定位

自建 vs 託管的判準：團隊是否有 ML pipeline 維運能力。託管方案的好處是零 ML 運維、跟觀測平台深度整合；自建的好處是可控性高、可以針對業務邏輯客製模型。

核心判讀

Anomaly detection 最常見的失敗是 baseline 沒對齊流量週期（週末自然下降被判成異常）跟異常觸發後無法歸因到具體維度（只知道「latency 異常」但看不出是哪個 service、哪個 region）。

重點訊號包括：

• Baseline 是否理解日夜、週末、節慶與促銷週期
• Anomaly 是否能指出 service、tenant、region 或 endpoint 維度
• False positive 是否納入 alert noise governance
• Anomaly 與 rule-based alert 是否有清楚分工

判讀訊號

• Alert 規則寫到數百條、仍漏掉 novel failure mode
• 已知 anomaly 訊號被忽略、靠人工巡視 dashboard
• Anomaly 觸發後無人能解釋「為什麼異常」
• 模型未對齊週期性（週末 / 節慶 / promo）造成噪音
• 同一指標 anomaly + rule alert 重複觸發、無協調

反模式

交接路由

• 4.4 dashboard-alert：anomaly 升級 alert 的條件
• 4.6 SLI/SLO：跟 SLO burn rate 的訊號分工
• 4.8 signal governance：anomaly false positive 的淘汰
• 4.18 operating model：anomaly 系統的 ownership

• 為何需要 attribution：共享平台模式下成本無人擁有
• 拆分維度：team / service / environment / tenant / cost driver
• 拆分的訊號來源：metric label / log tag / span attribute
• Showback vs chargeback
• Attribution dashboard 設計
• Vendor 帳單拆分能力
• 反模式

概念定位

Cost attribution 是把 observability 成本拆回團隊、服務、環境與成本來源的治理能力，責任是讓使用訊號的人也看見訊號成本。

Observability 平台（自架或託管）的成本來自三個層面：ingestion（收了多少資料）、storage / retention（保留了多久）、query（查了多少次跟多大範圍）。沒有 attribution 時，這三層的成本由平台團隊背，產品團隊把 observability 當免費資源 — 新增 metric label、延長 retention、加 dashboard panel 都沒有成本意識。

跟 4.7 cardinality 的分工：4.7 是技術治理工具（控制 cardinality、sampling、retention 階梯），4.15 是組織治理工具（讓成本對應到 owner、驅動 owner 採取行動）。

拆分維度

按 service / team

最基本的拆分。每個服務產生的 ingestion 量（events/sec、series count、log volume）歸到服務 owner。團隊是多個服務的集合。

實作方式：metric 跟 log 的 service label / tag 是拆分的基礎。如果 label 穩定且全覆蓋，用 sum by (service) 就能拆分 ingestion 成本。Label 不穩定（部分服務沒打 service tag）或 label 值漂移（service name 改名但 cost 系統沒更新）會讓拆分不準。

按 environment

Production / staging / dev 環境的成本各自歸因。常見發現是 staging 環境的 observability 成本跟 production 相當 — staging 開了跟 production 一樣的 retention、sampling 率、dashboard，但 staging 的觀測需求遠低於 production。

可操作的做法：staging 跟 dev 環境用更短的 retention（7 天 vs production 的 30 天）、更高的 sampling 比例、關閉不需要的 dashboard。把 environment 的成本差異展示在 attribution dashboard 上，讓團隊自行判斷 staging 的 observability 是否過度。

按 cost driver type

Ingestion / storage / query 三層的成本增長模式不同、控制手段也不同。

Ingestion 成本：跟 events/sec 跟 series count 成正比。控制手段是 sampling、cardinality 限制、低價值訊號過濾。歸因到產生訊號的服務。

Storage / retention 成本：跟資料量 × 保留期成正比。控制手段是 retention 階梯（4.7）、rollup 跟 storage tiering。歸因到資料保留政策的 owner。

Query 成本：跟查詢次數 × 掃描量成正比。控制手段是 recording rule、query cache、query cost estimation（4.23）。歸因到 dashboard 跟 alert rule 的 owner。

三層分開歸因的價值是精確定位成本增長來源。「這個月成本增長 30%」→ 是 ingestion 增長（某服務開了新 metric）還是 query 增長（某人加了 heavy dashboard panel）？分層歸因讓回答這個問題只需要查一個 dashboard。

按 tenant（多租戶場景）

Multi-tenant 平台的 observability 成本跟 tenant 的活躍度有關。大 tenant 產生的事件量可能是小 tenant 的 100 倍，但如果 observability 成本平攤，小 tenant 補貼大 tenant。

Tenant-level attribution 需要 metric / log / trace 帶 tenant label。Label 的 cardinality 問題在 4.7 處理 — tenant label 在 metric 層通常過高 cardinality（每個 tenant 一條 series），可以改在 log 或 trace 層按 tenant 統計 ingestion 量。

Showback vs Chargeback

Showback：讓團隊看到自己產生的 observability 成本，但不實際扣款。透明化驅動行為改變 — 當 team A 發現自己的 log ingestion 成本是其他團隊的 5 倍時，自然會開始檢視「是不是 debug log 開太多」。

Chargeback：把 observability 成本從團隊的預算中實際扣除。驅動力更強，但需要精確的 attribution（誤差會讓團隊不信任系統）跟組織層面的支持（財務流程、管理層買單）。

多數團隊的起步方式是 showback。Showback 的 attribution 精度要求比 chargeback 低 — 差 10-20% 的歸因不影響行為改變的驅動力。Chargeback 需要差 < 5% 才能讓團隊接受。

Attribution Dashboard 設計

Attribution dashboard 回答三個問題：

1. 誰在燒？ — 按 service / team 排序的成本排行榜。前 10 個服務通常佔 70-80% 的成本。
2. 燒在哪一層？ — 前 10 個服務的 ingestion / storage / query 成本比例。
3. 趨勢是什麼？ — 月對月的成本趨勢、哪些服務的成本增長最快。

Dashboard 的更新頻率可以低（每天或每週），因為 attribution 驅動的是策略決策而非即時操作。Panel 讀 pre-aggregated 資料（daily cost summary table），查詢成本本身很低。

Attribution dashboard 的 owner 是 observability platform team，但 actionable insight 的 owner 是各服務團隊。Platform team 負責維護 attribution 的精確性跟 dashboard 的正確性；服務團隊負責看自己的成本趨勢跟採取控制行動。

Vendor 帳單拆分能力

自架的 attribution 精度最高（因為完全可控），但維護成本也最高。託管 vendor 通常提供 service 或 team 級的 usage attribution，但跨 ingestion / storage / query 的分層拆分需要用 vendor API 自建 dashboard。

核心判讀

Cost attribution 的核心目標是讓成本對應到能採取行動的 owner — 成本只有總額而無歸屬時，沒有團隊有動力控制。

重點訊號包括：

• Ingestion、retention、query 是否能分開歸因
• Team / service / environment label 是否穩定
• Showback 是否足以改變行為，或需要 chargeback
• 高成本訊號是否能對應事故、SLO 或除錯價值

判讀訊號

• 成本季度增長、無人能說「哪個團隊 / 服務在燒」
• 高成本服務跟高價值服務不對應、無 ROI 視角
• 平台團隊背所有預算、產品團隊把 observability 當免費資源
• Attribution dashboard 存在但無 owner、半年沒看
• Vendor 帳單只有總額、無服務級拆分
• Staging 的 observability 成本跟 production 相當但無人注意

反模式

交接路由

• 4.7 cardinality / cost：技術層面的成本治理工具
• 4.11 telemetry pipeline：pipeline 各層的成本歸屬
• 4.18 operating model：platform team 跟 service team 的 cost ownership
• 4.23 觀測查詢設計：query 成本的 estimation 跟治理
• 6.9 capacity / cost：observability 成本作為整體容量規劃的一部分
• 4.C14 觀測平台成本治理：從帳單驚嚇到可預測成本的綜合情境

• readiness review 的責任：在 production 前確認訊號能支援分級、定位、回復與復盤
• 檢查面向：log schema、metrics、trace context、dashboard、alert
• 上線前判準：核心 user journey 是否有 SLI、錯誤是否有 correlation key、依賴是否可追蹤
• 變更前判準：新依賴、新 queue、新 feature flag 是否帶出新訊號需求
• 演練前判準：game day / chaos / DR drill 是否能被 04 訊號觀察
• 跟 06 的交接：readiness 缺口進入 reliability readiness / release gate
• 跟 08 的交接：readiness 缺口影響 severity trigger、runbook 與 decision log
• 反模式：服務先上線、事故後才補 dashboard；alert 有通知但缺定位欄位；trace 需要人工對回 log

Observability readiness review 的價值在於把「事故時才會被問到的問題」提前成上線條件。服務進 production 前，團隊需要先確認訊號能回答三件事：哪裡出問題、影響到誰、下一步由誰處理。

概念定位

Observability readiness review 是把「訊號是否足以支援操作」變成上線前檢查的流程，責任是讓服務進入 production 前已具備基本診斷能力。

這一頁處理的是準備度。工具已存在時，仍需要確認訊號是否對應使用者旅程、依賴邊界、事故分級與復盤證據。

readiness review 不等於打勾清單。它是一次跨角色對齊：服務團隊確認事件語意，平台團隊確認採集與查詢路徑，on-call 確認事故前 10 分鐘真的能定位。三者同時成立，才算可操作準備度。

適用情境

Observability readiness review 適合放在服務生命週期的高風險節點。這些節點共同特徵是：一旦變更進入 production，第一次異常就會依賴既有訊號做判讀。

新服務上線時，readiness review 的責任是確認基本診斷能力已經存在。典型服務至少要能從 request、tenant、region、dependency 與錯誤分類回到同一條事件鏈，讓 on-call 能在前 10 分鐘判斷影響範圍。

重大變更時，readiness review 的責任是確認變更帶來的新風險已有訊號。加入新的外部 API、queue、background job、feature flag 或資料同步流程，都會增加新的失效面；每個失效面都應有對應 log、metric、trace 或 alert。

演練前，readiness review 的責任是確認驗證行為能被觀測。chaos experiment、load test 或 DR drill 需要同時產生故障與判讀證據，讓團隊能確認 steady state、blast radius 與回復狀態。

核心判讀

判讀 observability readiness 時，先看服務的核心旅程是否有訊號，再看事故時能否從症狀走到原因。

重點訊號包括：

• 核心 user journey 是否有 SLI/SLO 與 error rate
• log 是否有 request id、trace id 與 tenant 欄位
• trace 是否覆蓋同步、async、queue 與 background job 邊界
• dashboard 是否能支援 on-call 的前 10 分鐘判讀
• alert 是否能連到 runbook 與 owner

Review 流程

Readiness review 的流程是從使用者旅程走向操作路由。先從服務承諾的體驗開始，再反推工具與訊號清單，才能讓監控資產對應事故時的實際判讀。

1. 定義核心旅程與失敗後果。
2. 對每個旅程列出依賴、async workflow 與資料寫入點。
3. 為每個失效點指定 log、metric、trace 或 dashboard。
4. 驗證 alert 是否連到 owner、runbook 與下一步動作。
5. 標記尚未補齊的訊號缺口，決定是否阻擋上線或納入 follow-up。

核心旅程是 readiness review 的錨點。購物服務的核心旅程可能是 checkout、payment、order confirmation；內容平台可能是 upload、publish、read path；B2B API 可能是 authentication、request processing、webhook delivery。訊號需要優先對到這些旅程，再補 CPU、memory 與 pod restart 等資源層訊號。

依賴圖是 readiness review 的第二層。每個資料庫、cache、broker、third-party API、object storage 與 internal service 都應能被定位為 upstream 或 downstream，並且在 trace、metric 或 log 中留下可查詢欄位。

操作路由是 readiness review 的交付物。當 alert 觸發時，on-call 需要知道先看哪個 dashboard、用哪個 query、找哪個 owner、用哪個 runbook、何時升級到 incident commander。

判讀訊號

• 服務上線 checklist 有監控項目，但沒有事故判讀欄位
• 新依賴上線後，dashboard 看不到 upstream / downstream 影響
• alert 觸發後仍需要人工 grep 多個系統拼事件鏈
• chaos 或 DR 演練產生故障，但 04 訊號沒有反映出預期現象
• 事故復盤 action item 反覆要求「補監控」

在真實服務中，最常見的 readiness 缺口是工具已存在，但工具沒有對到決策。例如 alert 可以 page on-call，但查詢第一步就要跨三個系統手動對帳，代表 readiness 還停在可見層，尚未進入可操作層。

控制面

Readiness review 的控制面是把檢查結果轉成可執行決策。每個缺口都要被分類為阻擋、降級接受或後續改善，並且留下 owner 與期限。

阻擋條件應該以「事故時是否能決策」為核心。核心旅程 SLI、request correlation、upstream / downstream 分辨能力與 alert owner 都是第一次事故能否被接住的基本條件。

降級接受需要明確寫出限制。若某個低流量背景任務暫時缺 trace，但有 log query、DLQ dashboard 與人工 replay 流程可以承接，團隊可以接受短期限制；限制需要進入 incident decision log，避免事中被誤讀為完整訊號。

後續改善適合處理長期品質問題。dashboard 可用但查詢成本過高、alert 可行但 noise 偏高、欄位命名需要統一，這些缺口適合進入 signal governance，讓上線決策與長期治理分流。

常見反模式

Observability readiness 的反模式通常來自把「有監控」誤當成「可操作」。監控存在只是起點，能支援判讀、路由與回復才是 readiness。

事後補 dashboard 的風險是把第一次事故變成探索行為。事故期間的主要工作應是止血與決策；如果團隊還在建立第一個查詢、猜欄位語意、找 owner，代表 readiness 沒有完成。

告警只有通知會把壓力丟給 on-call。有效 alert 應該同時提供症狀、範圍、第一個查詢入口與下一步路由，讓值班者能直接進入判讀流程。

與 06 和 08 的關係

Observability readiness 是可靠性驗證與事故處理的輸入層。06 需要用它判斷驗證前提是否成立，08 需要用它判斷事故 evidence 是否足以啟動流程。

在 06 中，readiness 缺口會影響 load test、chaos、DR drill 與 release gate。驗證行為需要可觀測訊號支撐，測試結果才足以證明系統維持在可接受狀態內。

在 08 中，readiness 缺口會影響 severity trigger、incident intake 與 decision log。若 evidence 不完整，事故指揮需要先標記資料限制，再決定是否升級、降級或等待更多證據。

交接路由

• 04.1 log schema：補事件關聯欄位
• 04.2 metrics：補服務健康與容量指標
• 04.3 tracing：補跨服務與 async context
• 04.4 dashboard / alert：補操作入口與通知條件
• 4.5 威脅建模：觀測盲區跟資料暴露的上線前檢查
• 06.19 reliability readiness：把觀測準備度納入上線前門檻
• 08.18 incident intake：把訊號接進事故 intake 與 evidence triage

• telemetry data quality 的責任：確認觀測資料本身可信
• 缺漏類型：missing signal、partial trace、dropped log、stale metric
• 漂移類型：schema drift、label drift、service name drift、semantic convention drift
• 偏誤類型：sampling bias、low-traffic bias、high-cardinality truncation
• 時間類型：clock skew、ingest delay、out-of-order event、timezone mismatch
• 品質指標：completeness、freshness、consistency、accuracy、coverage
• 跟 4.11 telemetry pipeline 的分工：pipeline 看路徑，data quality 看資料可信度
• 反模式：dashboard 看起來正常但資料少一半；trace sample 漏掉錯誤；timestamp 導致 timeline 錯序

Telemetry data quality 的核心是把「觀測資料失真」當成一級事件。服務事故判讀建立在觀測資料上，資料品質不穩時，團隊會把資料缺口誤讀成系統行為，進而做出錯誤分級、錯誤回復或錯誤 SLO 判斷。

概念定位

Telemetry data quality 是把觀測資料當成資料產品治理的能力，責任是讓 log、metric、trace 與 alert 的判讀建立在可信資料上。

這一頁處理的是資料可信度。訊號存在不等於訊號可信；缺漏、漂移、偏誤與時間錯位都會讓事故判讀走向錯誤路徑。

資料品質治理最有效的做法是把品質指標產品化：讓 completeness、freshness、drift、sampling coverage 也進 dashboard 與告警，讓團隊在事故前就能看見資料限制。

品質模型

Telemetry data quality 的品質模型由五個面向組成。這五個面向分別回答資料是否存在、是否及時、是否一致、是否代表真實流量，以及是否足以覆蓋關鍵旅程。

Completeness 是事故判讀的基礎。log、metric 或 trace 的缺口如果沒有被標示，dashboard 會呈現一條看似平順的線，實際上可能只是 ingestion pipeline 丟了資料。

Freshness 決定資料能否支援事中決策。告警延遲、metric scrape delay、trace export queue backlog 與 log indexing lag 都會讓 incident commander 用過期資料判斷是否擴大或回復。

Consistency 決定資料能否跨服務拼接。service name、region、tenant、environment、error class 與 semantic convention 若在不同系統漂移，單一服務看起來正常，跨服務事件鏈卻會斷裂。

Accuracy 決定資料能否代表真實狀態。常見問題包含錯誤單位、重複計數、counter reset 誤判、histogram bucket 設錯與 status code mapping 錯誤。

Coverage 決定資料能否覆蓋高風險邊界。低流量服務、VIP tenant、錯誤樣本、長尾 latency 與 rare dependency failure 常被 sampling 或聚合策略稀釋。

核心判讀

判讀 telemetry data quality 時，先看資料是否完整與新鮮，再看不同訊號之間是否能互相對齊。

重點訊號包括：

• log / metric / trace 是否有 coverage 與 drop rate
• schema 是否有版本與 drift 偵測
• sampling 是否保留錯誤、高延遲與低流量樣本
• timestamp 是否能支援 incident timeline 還原
• dashboard 是否標示資料延遲、缺口與查詢範圍

缺漏與漂移

缺漏是 telemetry data quality 最容易造成錯誤安全感的問題。缺漏發生時，圖表通常不會直接報錯，而是呈現較低的流量、較少的錯誤或不完整的 trace。

Missing signal 代表觀測需求沒有覆蓋服務路徑。常見場景是新 feature flag 開啟後走到新 code path，但 SLI、log schema 與 trace 還停在舊路徑。

Partial trace 代表跨邊界 context 缺少完整傳遞。request 進入 queue 後，如果 message 缺少 correlation id 或 consumer 缺少 span，團隊只能知道 request 發出去，背景流程的失敗時間與失敗點會留在盲區。

Dropped log 代表資料流量超過 pipeline 或成本限制。burst error 發生時，如果 log pipeline 開始 sampling 或丟棄，事故團隊看到的錯誤量會比真實狀態少。

Schema drift 是長期維護最常見的品質問題。欄位改名、label 粒度改變、service name 不一致、semantic convention 升級，都會讓查詢與 dashboard 在沒有明顯錯誤的情況下失準。

Sampling 與代表性

本段聚焦 sampling 對資料品質的失真風險；sampling 策略（Head / Tail / Adaptive / Exemplar）的 SSoT 在 4.7 Sampling 策略。

Sampling 的責任是控制觀測成本，同時保留足以判讀的高價值樣本。sampling policy 若只按固定比例抽樣，最容易丟掉低頻但高風險的事件。

Low-traffic bias 會讓小服務或小 tenant 的問題長期不可見。這些路徑平時量小，但可能承擔高價值客戶、管理操作或資安事件；抽樣策略需要保留最低樣本量。

Error sample loss 會直接破壞事故判讀。錯誤、timeout、retry exhausted、DLQ、payment failure 與 authorization failure 應該有更高保留權重，因為它們代表決策價值高於普通成功 request。

Cardinality truncation 需要明確揭露。當平台為了成本截斷 label 或聚合 tenant 維度時，dashboard 應標示資料限制，讓讀者知道當下看的是聚合視角與可用粒度。

時間對齊

時間對齊是 incident timeline 的基礎能力。事件發生時間、採集時間、寫入時間、查詢時間與顯示時區若未分清，事故復盤會把原因與結果順序看反。

Clock skew 會讓跨服務事件鏈失去可信度。若 API、worker、database proxy 與 observability collector 的時間基準不同，trace 中的等待點可能看起來是負時間或錯誤順序。

Ingest delay 會影響事中決策。incident commander 看到 error rate 下降時，需要知道資料是即時下降，還是 pipeline 還沒收完高峰區段。

Timezone mismatch 常出現在 status page、support ticket、vendor notice 與內部 timeline 對接時。所有事故證據都應保留原始時間與標準化時間，避免復盤時重排錯誤。

判讀訊號

• 同一事故在 log、metric、trace 中呈現不同時間線
• service name / region / tenant label 在不同系統拼不起來
• 低流量服務的錯誤被 sampling 稀釋
• pipeline drop 發生但 dashboard 沒提示資料缺口
• post-incident review 發現判讀基於不完整資料

常見場景是「圖看起來穩，但資料在悄悄掉」。例如 ingest 層 partial drop 後 error rate 下降，看似健康，實際是訊號少了高風險區段。這類情況若沒有資料品質指標，會讓事故決策建立在錯誤安全感上。

控制面

Telemetry data quality 的控制面是把資料限制顯性化。資料品質不需要追求完美，但需要讓讀者知道目前能相信什麼、限制在哪裡、何時需要改用其他 evidence。

1. 為每種 telemetry 設定品質指標。
2. 在 dashboard 標示 freshness、coverage 與 known gap。
3. 對 schema drift、drop rate 與 sampling policy 建立告警。
4. 在 incident decision log 記錄資料限制。
5. 在 post-incident review 中回寫造成判讀錯誤的資料品質缺口。

品質指標本身也需要 owner。平台團隊可以維護 pipeline drop、ingest delay 與 semantic convention；服務團隊需要維護 service-specific schema、business event 與 user journey coverage。

資料限制應直接出現在操作入口。若某 dashboard 的 trace sample 只保留 10%、某 tenant label 被聚合、某時間區段有 log gap，讀者應在同一個畫面看到限制，並把限制納入當下決策。

常見反模式

Telemetry data quality 的反模式來自把查詢結果視為事實本身。查詢結果只是資料產品的輸出，仍然受採集、轉換、抽樣、儲存與查詢限制影響。

dashboard 即事實會讓事故決策失去資料謙遜。圖表顯示健康時，仍要確認資料有沒有缺口、延遲或抽樣偏誤，尤其在 pipeline 自身承受壓力時。

sampling policy 黑箱會降低服務團隊的風險判讀品質。平台可以為成本抽樣，但抽樣規則要能被服務團隊理解，並且允許錯誤、高延遲與低流量關鍵路徑保留更高權重。

遷移期的雙軌對照驗證

觀測平台遷移是資料品質最容易失分的窗口。新舊管線並存期間，若沒有顯式對照驗證，語意漂移會在 dashboard 看起來「都有資料」的情況下緩慢偏離，直到事故時才浮現。

雙軌對照的核心責任是把新管線當被檢驗的對象、用舊管線作為對照基準。新舊管線同時採集相同訊號、用相同 query 對照 error rate、p95 latency、burn rate、trace coverage 是否一致；偏差超過閾值時先停止下一步遷移、保留證據後再決定下一步。

對應 4.C7 Datadog OTel 相容遷移實務：揭露「先建立雙軌採集對照、用品質指標決定何時關閉舊管線」的做法。對應 4.C9 OTel 遷移訊號漂移反例：揭露遷移失敗的主要風險來自語意漂移 — metric 名稱、label、sampling、aggregation 在新舊管線間出現微小差異，導致同一現象被歸到不同 service / label / latency bucket。

可重複套用的對照驗證做法：

1. 固定一組 baseline query：選定關鍵服務的核心 SLI query（error rate、p99 latency、throughput），新舊管線各跑一份、定期比對。
2. 設定偏差閾值：每個 SLI 設可接受偏差（例如 ±5%）。超過閾值的時段標記為待調查，不能無視。
3. 追蹤 missing signal 比例：missing span、missing metric、missing log 的比例是漂移的早期指標。比例持續上升時，停止下一批服務切換。
4. 退出條件顯式化：「對照偏差連續 N 天 < X%」作為關閉舊管線的退出條件，把雙軌期變成有界的、不是無限延長。

遷移期的告警條件本身也是治理項目。新舊管線對同服務的 error rate 長期偏離、missing span / missing metric 比例持續上升、同一事件在兩套 dashboard 得到相反結論、這些都該成為高優先告警、讓漂移在發生當下即時可見、避免堆積到 retrospective 才被注意。

雙軌期的成本是顯而易見的：兩份採集、兩份儲存、兩份查詢。但放棄對照的代價更大 — 沒有對照證據，事故時無法分辨是「服務問題」還是「遷移問題」，回退也失去依據。詳細的回退判讀流程由 4.11 telemetry pipeline 處理，本章關注的是品質指標的對照設計。

與 SLO 和事故的關係

Telemetry data quality 是 SLO 與事故 evidence 的可信度前提。SLI 若建立在失真資料上，error budget、burn rate alert 與 release freeze 都會被錯誤資料牽動。

在 SLO 場景中，資料品質缺口會直接改變可靠性政策。若 availability SLI 漏掉 mobile client、region label 漂移、error sample 被抽掉，團隊會高估可靠性並繼續放行高風險變更。

在事故場景中，資料品質限制需要進入 incident decision log。當 IC 做出升級、降級、等待或 rollback 決策時，應同時記錄當下 evidence 的 completeness、freshness 與 confidence。

交接路由

• 4.1 log schema：治理欄位漂移
• 4.7 cardinality / cost：sampling 策略矩陣、高維度截斷與成本取捨
• 4.11 telemetry pipeline：追查 drop、delay 與 ingest 問題
• 4.14 anomaly detection：避免模型學到偏誤資料
• 4.18 operating model：品質指標的 platform / service ownership 邊界
• 8.19 incident decision log：標記事中判讀使用的資料品質限制
• 4.23 觀測查詢設計：pre-aggregation 跟 raw data 的一致性驗證
• 4.C13 Discord 儲存→觀測缺口：儲存演進反覆暴露觀測盲區的教訓

• operating model 的責任：定義誰擁有訊號、誰維護 dashboard、誰處理 alert、誰承擔成本
• 角色分工：platform team、service team、on-call、incident commander、security / compliance
• ownership 欄位：owner、review cadence、retention、cost center、runbook link、deprecation date
• 生命週期：新增、審核、使用、修訂、淘汰
• 治理節奏：dashboard review、alert review、cost review、post-incident write-back
• 跟 4.15 cost attribution 的關係：成本歸屬是 operating model 的一部分
• 跟 08 的關係：事故時使用同一組 owner 與 escalation route
• 反模式：平台團隊擁有所有 alert；service team 不看 dashboard；成本無 owner

Observability operating model 的價值是把觀測從「工具責任」改成「服務責任」。平台團隊提供共用能力，服務團隊提供業務語意，on-call 使用這些資產做決策；operating model 負責固定三者的接口。

概念定位

Observability operating model 是把觀測資產的責任分配明確化的治理模型，責任是讓訊號有人維護、告警有人回應、成本有人決策。

這一頁處理的是 ownership。可觀測性需要平台工具、服務脈絡、操作責任與淘汰條件一起維持。

這層的判準是事故當下能否立刻知道誰要看哪個面板、誰有權調整閾值、誰負責決定淘汰過期訊號。dashboard 數量與 alert 覆蓋率只是輔助訊號。

角色分工

Observability operating model 的角色分工以「誰能做決策」為核心。owner 是有權維護、調整、下架或升級觀測資產的人，名義聯絡人只能作為補充欄位。

Platform team 的責任是維持共同語言。它需要定義 service name、environment、region、tenant、trace context、retention tier 與成本政策，讓跨服務查詢可行。

Service team 的責任是維持服務語意。它需要定義哪些 user journey 是核心、哪些錯誤影響用戶、哪些 dependency failure 需要 alert、哪些 dashboard 仍有操作價值。

On-call 的責任是把資產用在事中決策。alert 應能帶到 dashboard、runbook 與 owner，讓 operating model 真正進入操作流程。

Security / compliance 的責任是把觀測資料的證據價值與資料風險同時納入治理。audit log、PII redaction、retention 與 access review 需要在觀測模型中有明確 owner。

核心判讀

判讀 operating model 時，先看每個觀測資產是否有 owner，再看 owner 是否有權限與節奏採取行動。

重點訊號包括：

• dashboard 是否有明確使用者與 review cadence
• alert 是否有 runbook、owner 與 escalation path
• 高成本訊號是否能對應服務價值與成本中心
• post-incident review 是否能回寫到訊號 owner
• orphan dashboard 與 stale alert 是否有清理流程

觀測資產欄位

Observability asset 需要像服務 artifact 一樣有 metadata。沒有 metadata 的 dashboard、alert、query 與 schema 會在幾個月後變成無人敢刪、無人敢改、也無人信任的資產。

Owner 欄位要搭配權限才有意義。有效 owner 需要能調整 threshold、更新 dashboard、下架 query 或決定 retention，讓 ownership 成為可執行責任。

User 欄位能避免 dashboard 變成展示資產。面板若沒有明確使用者，例如 on-call、service owner、capacity planner 或 compliance reviewer，就很難判斷它是否仍值得維護。

Runbook link 是 alert 從通知變成行動的關鍵。每個可 page 的 alert 都應連到第一步查詢、初始判讀、升級條件與 rollback / degrade / wait 的決策路由。

Cost center 讓觀測成本有業務語意。高 cardinality、長 retention、full-fidelity trace 與大量 log indexing 都有價值，但價值需要由能受益的服務或團隊承擔與檢視。

生命週期

Observability operating model 的生命週期是新增、審核、使用、修訂與淘汰。這個生命週期讓訊號保持有用，並讓觀測資產累積在可治理範圍內。

1. 新增：服務變更、事故復盤、演練需求或合規要求產生新訊號。
2. 審核：確認 schema、成本、owner、runbook 與 retention。
3. 使用：進入 dashboard、alert、incident intake 或 SLO 計算。
4. 修訂：根據噪音、缺口、成本與使用頻率調整。
5. 淘汰：移除 stale alert、orphan dashboard、過期 query 與無價值高成本訊號。

新增訊號需要清楚的需求來源。最好的來源是 user journey、SLO、incident review、game day 或 audit requirement；最弱的來源是「可能有用」。

審核訊號需要同時看語意與成本。欄位是否穩定、cardinality 是否可控、retention 是否合理、PII 是否被遮罩、owner 是否能維護，都是訊號上線前的固定問題。

淘汰是 operating model 的必要能力。舊 alert 沒有人敢關，會增加 alert fatigue；舊 dashboard 沒有人敢刪，會讓事故時不知道哪個面板可信。

判讀訊號

• alert 觸發後沒人知道該由平台或服務團隊處理
• dashboard 存在但半年無人打開
• 成本暴增時只能找平台團隊吸收
• post-incident review 指派 action item，但沒有訊號 owner
• service team 調整欄位後，平台查詢與 dashboard 斷裂

實務上常見的治理斷點是「有 owner 名字，缺 owner 權限」。owner 需要能調整 alert、建立或下架 dashboard、分配成本，治理流程才會停在資產責任人，減少回流到平台集中處理的積壓。

治理節奏

Operating model 的治理節奏把觀測資產拉回日常工程流程。review cadence 的重點是定期回答「這個資產還能支援決策嗎」，會議只是其中一種執行形式。

Dashboard review 應看使用情境與操作價值。面板需要支援 on-call 的前 10 分鐘、capacity planning 或 SLO review；脫離這些用途的面板適合合併、重命名或下架。

Alert review 應看行動品質。alert 若經常觸發但缺少明確處置，通常更適合變成 dashboard signal、ticket 或長期治理項。

Cost review 應看服務價值。觀測成本上升不一定是壞事，但需要能說明這些成本降低了哪一種事故風險、合規風險或容量風險。

規模差異下的角色配置

Operating model 的角色配置隨組織規模調整。可投入的治理人力、可承受的協調成本、可維持的審核頻率三項一起決定當前該採哪種配置。把大組織的治理模型套到小團隊會造成過度治理；把小團隊的鬆散模型套到大組織會造成責任懸空。

本段聚焦常態 ownership 配置（不同規模下角色矩陣的差異）；遷移期的節奏取捨由 4.11 規模差異下的遷移節奏 處理、兩者 lens 不同。

對應 4.C10 規模差異下觀測遷移：揭露「規模差異會放大不同治理失分模式」的方向；case 主場景是觀測遷移、本章將此 frame 借用到常態 operating model 場景、以下展開屬通用工程知識補充。

小型組織的 operating model 重點是「角色合一、節奏明確」。一個 SRE 同時承擔 platform、service、on-call、cost owner 多重身份。治理重點是顯式記錄當前 ownership 跟 review cadence、避免角色合一被誤讀成默契傳遞（「大家都管 = 沒人管」是典型失敗）。Dashboard review、alert review、cost review 可以合併在同一個月會中，但要有具體的決議紀錄。

中型組織開始出現 platform 跟 service team 的分化，治理失分集中在介面定義。schema convention、cardinality 限制、cost center 命名規約若未在 platform / service 之間明確化，會在跨服務查詢時持續出現拼接斷裂。中型組織適合先固化「平台保證什麼、服務保證什麼」的契約，再擴大角色拆分。

大型組織的 operating model 牽涉多層 platform team、跨地區 on-call、合規 / 安全 / 財務的橫切責任。治理失分的核心來源是審核節奏跟不上資產成長速度 — 角色分工通常已經清晰，但每週 / 每月人工 review 數百個 dashboard / alert 不切實際。大型組織需要自動化的 stale dashboard 偵測、orphan alert 提示、retention compliance 報表，把 review 從手動週期變成事件驅動，讓治理隨資產數量自動擴展。

三類組織的共同前提是先把 ownership 視為可演進的、再決定當前該採哪種配置。組織成長過程中 ownership 矩陣會反覆調整，每次調整都要把新配置寫進文件、進入 release / runbook 流程、讓 ownership 變更跟釋出流程同步可見。

常見反模式

Observability operating model 的反模式通常是責任集中或責任懸空。前者讓平台團隊成為所有訊號的瓶頸，後者讓服務團隊在事故時找不到可信入口。

平台擁有所有 alert 會讓服務語意被削弱。平台知道 pipeline 與 infra，但通常不知道某個錯誤是否影響 checkout、資料同步、帳單或客戶 SLA。

服務各自為政會讓跨服務事故難以判讀。每個服務都可以有自己的 dashboard，但 service name、environment、region、tenant、error class 與 trace context 需要共用標準。

復盤無回寫會讓 operating model 停在文件。post-incident review 揭露的偵測缺口、runbook 缺口與成本缺口都應回到對應 owner 的資產生命週期。

與事故流程的關係

Observability operating model 是事故流程的責任基礎。事故期間，IC 需要知道哪些訊號可信、哪個 owner 能解釋欄位、誰能調整 alert、誰能決定保留或匯出 evidence。

在 incident command 中，observability owner 不一定是 incident commander，但必須能提供訊號解釋與操作建議。當 telemetry data quality 有限制時，owner 需要把限制交給 scribe 或 decision log。

在 runbook lifecycle 中，dashboard、alert 與 query 都應被視為 runbook 的依賴。runbook 更新時，如果沒有同步更新觀測資產，下一次事故仍會走到舊入口。

交接路由

• 4.4 dashboard / alert：設計 owner、runbook 與停止條件
• 4.8 signal governance loop：淘汰 stale alert 與 orphan dashboard
• 4.13 service topology：動態叢集環境下、cluster 層 vs 服務層的 ownership 路由
• 4.15 cost attribution：把成本接回 owner 與服務
• 08.2 incident command roles：事故時使用相同 ownership 模型
• 08.16 runbook lifecycle：把觀測資產接進 runbook 版本治理

• debuggability by design 的責任：讓系統設計本身支援定位、重現與證據收集
• API 設計：request id、error code、idempotency key、semantic status
• async workflow：message id、correlation id、retry count、dead-letter reason
• dependency call：timeout、fallback、upstream response、circuit state
• error model：可分類錯誤、可追蹤錯誤鏈、可對應使用者影響
• 診斷入口：diagnostic endpoint、health check、probe
• 跟語言教材的分工：語言處理 logger / error chain，04 處理跨服務診斷能力
• 反模式：事後補 log；錯誤只回 500；async 任務缺 correlation id；依賴失敗無上下文

Debuggability by design 的核心是讓系統在設計時就暴露足夠上下文。事故時需要的資訊若沒有在 API、message、dependency call 與 error model 層留下來，後端平台再完整也只能收集到片段訊號。

概念定位

Debuggability by design 是把可診斷性當成服務設計輸入的做法，責任是讓系統在出問題時自然留下定位所需的脈絡。

這一頁處理的是設計前移。觀測工具只能收集系統吐出的訊號；如果 API、async workflow、dependency call 與 error model 沒有診斷欄位，事後補平台也只能看到破碎片段。

這層與可觀測平台互補：平台負責收、存、查，設計負責產生可判讀語意。兩者任一缺失，都會讓事故定位時間呈倍數增加。

設計輸入

Debuggability by design 的設計輸入是「未來出問題時需要回答什麼問題」。系統設計時先列出這些問題，才能決定 API、message、dependency call 與 error model 要留下哪些欄位。

Request id 與 trace id 的責任不同。request id 通常對應對外請求與支援查詢，trace id 對應跨服務路徑；兩者互相連結時，支援查詢與工程診斷都會有穩定入口。

Correlation id 與 causation id 能讓 async workflow 保留因果。事件進入 queue、fan-out、retry、DLQ 或 replay 後，團隊需要知道它從哪個 request 或上游事件來，並且知道目前是哪一次處理嘗試。

Diagnostic endpoint 的責任是提供低風險查詢入口。它是受權限、速率、遮罩與審計保護的操作面，讓 on-call 能查健康、依賴、queue、cache 或 feature flag 狀態。

核心判讀

判讀 debuggability 時，先看關鍵流程是否保留 correlation，再看錯誤是否能路由到下一步。

重點訊號包括：

• API request 是否有穩定 request id 與錯誤分類
• async message 是否有 correlation id、retry count 與 DLQ reason
• dependency call 是否記錄 upstream、timeout、fallback 與 response class
• error chain 是否能連到 trace、log 與 user impact
• diagnostic endpoint 是否能支援 on-call 的低風險查詢

API 可診斷性

API 可診斷性的責任是讓每一次 request 都能被支援、工程與事故流程共同定位。API 不只回傳成功或失敗，也要留下足夠語意讓團隊知道錯在哪個層級。

Request ID 是支援與工程之間的共同鑰匙。客戶只知道某次操作失敗，支援需要 request id 或可查詢等價欄位，才能把客訴轉成 incident intake evidence。

Error code 應該表達穩定語意，並保持內部實作封裝。PAYMENT_PROVIDER_TIMEOUT、QUOTA_EXCEEDED、TOKEN_EXPIRED 這類分類能支援路由；隨程式碼結構變動的錯誤字串則會讓查詢與客戶端處置不穩定。

Idempotency key 是 recovery 的診斷欄位。當 retry、rollback、replay 或補償流程啟動時，團隊需要知道哪些請求已被接受、哪些副作用已完成、哪些可以安全重送。

Async Workflow 可診斷性

Async workflow 可診斷性的責任是讓事件離開同步 request 後仍保留因果鏈。queue、worker、event handler 與 scheduled job 會把時間拉長、路徑拉開，欄位不足時最容易形成診斷斷點。

Message ID 讓團隊能看見單一訊息的生命週期。它應該能串到 publish、broker delivery、consumer ack、redelivery、DLQ 與 replay。

Correlation ID 讓 async 任務保留業務脈絡。缺少 correlation id 時，DLQ dashboard 只能顯示失敗數量，tenant、request 與 user journey 影響範圍會留在人工追查階段。

Retry count 與 DLQ reason 讓回復路徑可排序。高 retry count 可能代表下游依賴失效，也可能代表 poison message；兩者需要不同處置。

Dependency Call 可診斷性

Dependency call 可診斷性的責任是讓團隊分辨本地問題、下游問題與保護機制啟動。每一次外部依賴呼叫都應留下足夠上下文，支援等待、降級、切換或升級 vendor incident 的判斷。

Upstream name 需要是穩定維度。若每個 adapter 使用不同名稱，dashboard 與 trace 很難把同一個供應商或內部依賴聚合在一起。

Deadline 是 dependency call 的診斷欄位。timeout 發生時，團隊需要知道是下游慢、呼叫預算過短、queue backlog 導致開始太晚，還是 retry policy 放大壓力。

Fallback state 讓事故團隊知道保護是否生效。服務錯誤率可能沒上升，是因為 fallback 吸收了下游失敗；若沒有 fallback 訊號，團隊會低估風險。

Error Model 可診斷性

Error model 可診斷性的責任是把錯誤轉成可分類、可路由、可復盤的語意。錯誤不只服務於程式控制流，也服務於事故判讀與使用者影響評估。

錯誤分類應該讓下一步明確。internal error 適合作為最後防線；主要分類需要支援 on-call 判斷是重試、降級、rollback、升級資安，還是進入資料修復。

Error chain 需要保留上下文。過度包裝錯誤會讓原始 dependency、timeout、request id 或 schema version 消失；完全不包裝則會把底層細節直接丟給外部使用者。好的 error model 會分開內部診斷語意與外部穩定契約。

判讀訊號

• 事故時只能看到「500」，需要重跑才能定位原因
• queue message 進 DLQ 後缺少原始 request 脈絡
• 外部 API timeout 無 upstream 名稱、耗時與 fallback 狀態
• 錯誤被包裝後 trace 與 error chain 斷裂
• health check 顯示 healthy，但核心旅程已經失效

典型情境是 queue 任務在三次重試後進 DLQ，但缺少 request 與 tenant 脈絡。工程師可以看到「失敗很多」，後續需要先補「誰受影響、哪個流程壞、該先修哪一段」的判讀資訊。這就是設計期缺欄位造成的診斷斷點。

控制面

Debuggability by design 的控制面是把診斷欄位納入設計審查與契約驗證。可診斷性若只靠事後補 log，會在每次新 API、新 workflow 或新 dependency 上重複遺漏。

1. 在 API design review 中檢查 request id、error code、idempotency 與 impact hint。
2. 在 async workflow review 中檢查 message id、correlation、retry 與 DLQ reason。
3. 在 dependency review 中檢查 timeout、deadline、fallback 與 upstream naming。
4. 在 error model review 中檢查分類、內外部語意與 error chain。
5. 在 contract testing 中驗證關鍵診斷欄位與錯誤語意。

設計審查需要明確區分必填欄位與情境欄位。request id、trace context、error class 與 owner 通常是跨服務必填；idempotency key、DLQ reason、circuit state 則依 workflow 與依賴類型決定。

Contract testing 可以保護可診斷性。若 API 或 event schema 調整後移除了 correlation id、error code 或 retry metadata，測試應該阻擋這類破壞，因為它會讓事故判讀退回人工拼接。

常見反模式

Debuggability by design 的反模式是把診斷能力推遲到事故後。事故後補 log 可以修下一次，已發生事件的證據缺口則會留在復盤限制中。

事後補 log 的代價是已發生事故會留下復盤缺口。若缺少原始 request、tenant、message 或 dependency 欄位，工程師只能用間接推論重建時間線。

錯誤只回 500 會把所有問題導向同一條路由。validation、authorization、dependency、capacity 與 data consistency 的處置完全不同，錯誤模型應該支援這些分流。

Diagnostic endpoint 無治理會把可診斷性變成資安風險。診斷入口需要最小權限、資料遮罩、速率限制與 audit log，並且只提供事故判讀需要的 read-only 資訊。

與語言教材的分工

Debuggability by design 位在 Backend 服務設計層。語言教材負責如何在特定 runtime 中傳遞 context、包裝 error、實作 middleware、處理 async local storage 或 goroutine context；本章負責定義跨語言都需要保留的診斷語意。

同步 runtime 的重點是 thread-local、connection pool 與 blocking dependency call 是否能保留 request context。async runtime 的重點是 task、promise、callback 與 queue boundary 是否能保留 trace context。goroutine 或 lightweight task runtime 的重點是廉價並發是否放大下游壓力，並且是否保留 deadline 與 cancellation。

不同語言可以用不同實作方式，但 API、async workflow、dependency call 與 error model 的診斷責任相同。這也是 Backend 章節保留跨語言抽象的理由。

交接路由

• 04.1 log schema：定義診斷欄位
• 04.3 tracing：保留跨服務 context
• 04.11 telemetry pipeline：確保診斷訊號能被採集
• 06.10 contract testing：把錯誤模型與外部契約納入驗證
• 08.18 incident intake：把設計期留下的診斷欄位轉成 evidence

• evidence package 的責任：把分散的 observability 資料包成可交給 reliability 與 incident response 的證據
• 資料來源：log、metric、trace、audit log、dashboard、query、client-side signal、deployment event
• 欄位：source、time range、owner、query link、data quality、confidence、known gap、retention
• 跟 4.17 的關係：telemetry data quality 提供資料限制，evidence package 提供交接格式
• 跟 6.23 的關係：可靠性驗證使用同一格式保存 experiment evidence
• 跟 8.18 / 8.19 的關係：事故 intake 與 decision log 使用同一組 evidence link
• 反模式：只貼 dashboard 截圖；query 沒有時間窗；evidence 沒標示 sampling / freshness 限制

Observability evidence package 的核心是把可觀測資料從「查詢結果」升級成「可交接證據」。事故與驗證需要一組能說明來源、時間窗、可信度、限制與 owner 的 evidence。

概念定位

Observability evidence package 是可觀測性模組交給可靠性驗證與事故處理的證據包，責任是讓 log、metric、trace 與 audit log 能被重用、回放與復盤。

這一頁處理的是交接格式。4.17 Telemetry Data Quality 說明資料是否可信；evidence package 說明如何把可信度、查詢入口與限制一起交給下游流程。

證據包的價值在於保存判讀上下文。只有截圖時，讀者看不到 query、時間窗、sampling、資料延遲與 owner；有 evidence package 時，後續 release gate、incident decision log 與 post-incident review 才能回放同一組事實。

Evidence 欄位

Evidence 欄位的責任是讓每個觀測證據都可查、可解釋、可追蹤。欄位不需要複雜，但要覆蓋事中判讀與事後復盤的最小需求。

Source 欄位讓讀者知道 evidence 的能力邊界。Metric 適合看趨勢，log 適合看事件細節，trace 適合看路徑，audit log 適合看責任鏈。

Time range 是 evidence package 的基本欄位。事故前後 30 分鐘、部署期間、DR drill 時窗、burn rate 短窗與長窗都需要明確，否則同一張圖可能被不同人解讀成不同結論。

Query link 比截圖更重要。截圖適合溝通當下狀態，query link 才能讓下一班 on-call、可靠性 owner 或 PIR reviewer 重跑同一個判讀。

Data quality 欄位讓 evidence 保留限制。sampling ratio、ingest delay、schema drift、log drop、cardinality truncation 與 timestamp skew 都應直接出現在證據包中。

資料來源

Evidence package 的資料來源要按判讀責任分層。每一層回答的問題不同，下游使用時也要保留這個差異。

Log evidence 適合進入 incident intake。它要保留 request id、tenant、region、error class 與 trace id，讓事故候選能被查證。

Metric evidence 適合進入 SLO、release gate 與 steady state 判讀。它要保留時間窗、分母分子、聚合粒度與資料延遲，讓 burn rate 與容量判斷可回放。

Trace evidence 適合支援 dependency 與 async workflow 判讀。它要標示 sampling policy 與缺失 span，讓下游知道 trace 能支持到哪個邊界。

Audit log evidence 適合支援資安、資料修復與高風險操作。它要保留 access path、retention、masking 與 chain of custody 限制。

打包流程

Evidence package 的打包流程是從問題開始。先問下游要做什麼決策，再選擇足以支援該決策的資料與工具入口。

1. 定義 evidence 要支援的決策：readiness、release gate、incident intake、decision log 或 PIR。
2. 選擇最小資料集合：metric 看趨勢、log 看事件、trace 看路徑、audit 看責任。
3. 補上 time range、query link、owner 與 data quality。
4. 標示 confidence 與 known gap。
5. 把缺口回寫到 4.16 readiness、4.17 data quality 或 4.18 operating model。

Readiness 用的 evidence package 要回答「服務是否能被判讀」。它重視核心旅程、依賴、dashboard、alert、trace 與 owner。

Reliability 用的 evidence package 要回答「驗證是否有結果」。它重視 steady state、stop condition、experiment timeline、SLO burn 與回復訊號。

Incident 用的 evidence package 要回答「事故是否需要啟動、升級或回退」。它重視 source、impact scope、confidence、decision log 與 stakeholder update。

資料庫 migration 用的 evidence package 要回答「資料語意是否能進入下一階段」。它重視 validation query、row count、mismatch sample、replication lag、slow query 與資料限制；完整服務路徑可接到 1.7 Schema Migration Rollout 證據。

案例中的證據包判讀

證據包的價值要放回真實事故才看得清楚。Cloudflare 2019 與 AWS S3 2017 都不是「缺資料」，而是「資料若沒被包成可交接證據，決策會慢、通訊會亂、回寫會斷」。

Cloudflare 2019 的第一波判讀來自跨區 CPU、5xx 與 latency 同步惡化。這組訊號如果只有圖表截圖，團隊只能知道「全網變慢」；把 query link、time range、rule rollout event 與 confidence 一起交接，才能快速形成「先回滾規則」的決策。

AWS S3 2017 的關鍵是恢復分層：GET/LIST/DELETE 與 PUT 回線時間不同，且狀態頁通訊入口也受依賴影響。證據包若保留 subsystem 狀態、操作類型影響範圍與已知限制，對外更新才不會把「部分恢復」誤寫成「全面恢復」。

兩個案例共同指向同一個判讀原則：證據包要保留「能支持當下決策」的最小閉環，蒐集越多越好的思路反而製造噪音，至少包含事件時間窗、跨訊號對位、資料限制與決策責任人。

誤判風險與修正路徑

事故中的誤判多半源自證據包缺少判讀上下文，演算法本身很少是問題。當 evidence 只有結論沒有限制，下游就會把暫時訊號當成穩定事實。

修正路徑的核心是把 evidence package 當成事故中的工作物，而不是事故後整理物。當下有完整欄位，後續 8.19 決策紀錄才有可回放證據，8.22 回寫才有可追蹤缺口。

常見反模式

Evidence package 的反模式通常來自把資料貼出來就當作證據交接。證據需要上下文，否則只是一段輸出。

只貼 dashboard 截圖會讓 evidence 失去可回放性。截圖可以當摘要，query、時間窗與資料限制則提供復盤與交接能力。

缺資料品質限制會讓下游高估證據。若 trace sampling 只保留 10%、log pipeline 有 drop、metric 有 ingest delay，這些限制要跟證據一起交接。

交接路由

• 4.16 observability readiness：補 evidence package 所需的訊號入口
• 4.17 telemetry data quality：標示 completeness、freshness、drift 與 sampling 限制
• 4.18 operating model：指定 evidence owner、retention 與 review cadence
• 1.7 Schema Migration Rollout 證據：把 validation query 與資料限制包成 migration gate 可用的證據
• 6.23 verification evidence handoff：把驗證結果包成同一格式
• 8.18 incident intake：把 evidence package 轉成事故候選
• 8.19 incident decision log：把 evidence package 連到事中決策

概念定位

Rule-level CPU signal governance 是把「哪一條規則在吃 CPU」變成可量測、可回退、可治理的觀測能力，責任是補上服務級 CPU 指標看不到的規則層風險。

服務級 CPU 只告訴團隊「系統變慢了」，rule-level 訊號才告訴團隊「是哪個規則讓系統變慢」。兩者一起存在，事故才能從症狀快速收斂到可操作原因。

核心判讀

判讀順序是先看服務級異常，再下鑽到規則層成本分佈。若 CPU、latency、5xx 同步惡化，且 rule hit 分佈在短時間發生偏移，通常代表規則層出現新的成本熱點。

訊號模型

Rule-level CPU 訊號模型的重點是同時保留成本、命中與上下文。只有成本沒有命中，無法判斷影響面；只有命中沒有成本，無法判斷風險等級。

控制面

Rule-level CPU signal governance 的控制面是把「測到異常後要怎麼停」直接接到 rollout 流程，而不是只做監控展示。

1. 對高風險規則建立 rule-level CPU baseline 與異常門檻。
2. 把 rule-level 訊號接到 staged rollout gate。
3. 對 top-N 高成本規則建立自動降級或回退條件。
4. 在 evidence package 記錄當次 rollout 的 rule-level 成本分佈與限制。
5. 在 post-incident review 回寫新 payload 類型與新風險樣式。

常見反模式

案例回扣

• Cloudflare 2019 Regex CPU Outage
• 6.24 規則推送安全閘門

Cloudflare 2019 事故顯示高成本 regex 可以在全網同步推送下快速放大。Rule-level CPU 訊號治理的價值是把這類風險前移到 rollout 過程，而不是等到全球 5xx 才回頭排查。

交接路由

• 04.17： Telemetry Data Quality
• 04.20： Observability Evidence Package
• 06.24： Rule Rollout Safety Gate
• 08.19： Incident Decision Log

服務路徑與邊界

本篇服務路徑是 client -> checkout-api -> payment-adapter -> order-db。觀測邊界只處理「這條路徑目前是否可判讀」，不處理重試策略與回退決策本身；後者交給 06 與 08。

要先定義 evidence package 的最小欄位：Source、Time range、Query link、Owner、Data quality、Confidence、Known gap。這些欄位在事故期與放行期共用，避免兩套語言。

實作步驟

1. 固定交易路徑的觀測主鍵：trace_id、order_id、tenant_id、region。
2. 建立三組查詢入口：延遲分布（p50/p95/p99）、錯誤率與錯誤類別、下游 payment dependency timeout。
3. 為每組查詢補欄位：時間窗、資料延遲、採樣比例、目前 owner。
4. 在 deploy 前把同一份 evidence package 連到 6.8 Release Gate。
5. 事故期間把同一份 evidence package 連到 8.19 Incident Decision Log。

判讀訊號

常見誤區

把 evidence package 寫成 dashboard 截圖集合，會失去可重跑性。沒有 query link 與時間窗，事故交班時很難重建判讀脈絡。

把 confidence 省略也會導致誤判。事故前期資料常不完整，若不標示 suspected 與 known gap，下游決策容易把猜測當成結論。

案例回寫

這條路徑可用 GCP 2019 Network Incident 回寫。先看跨服務訊號如何失真，再回到本章檢查欄位是否能支撐「先分流、再判斷」。

這個案例主要支撐的是「證據欄位完整度」判讀，不直接支撐 release gate 停損門檻設計；停損規則要回到 6.8。

跨模組路由

1. 與 4.17 的交接：資料限制與偏差回到 Telemetry Data Quality。
2. 與 6.8 的交接：放行判斷使用同一份 evidence package。
3. 與 6.23 的交接：驗證證據欄位對齊 Verification Evidence Handoff。
4. 與 8.19 的交接：事故決策直接引用 evidence link 與 confidence。

下一步路由

要把證據轉成放行條件，接著讀 6.25 Provider Dependency Release Gate 實作示範。

• 觀測資料的讀寫不對稱：一種寫入路徑對應多種讀取路徑
• 三種查詢模式：即席診斷、聚合趨勢、鑑識回溯
• Storage tiering 與查詢路由：hot / warm / cold 不只是成本分層、是查詢能力分層
• Pre-aggregation 策略：recording rule、materialized view、rollup 的使用情境與維護成本
• Query 資源治理：priority、queue 分離、timeout 差異化、cost estimation
• 觀測領域的讀寫分離：CQRS 的特化應用
• 反模式：把 raw log 當 OLAP 查、dashboard 查詢直打 raw storage 無 pre-aggregation、recording rule 跟 raw query 重複計算

概念定位

觀測查詢設計是把「產生訊號之後怎麼被讀取」當成獨立的系統設計問題。觀測資料的寫入路徑（agent → collector → ingest → storage）在 4.11 telemetry pipeline 處理；本章處理的是讀取路徑 — 從 storage 經 query engine 到 dashboard、alert 與即席查詢的資料流。

寫入路徑的設計目標是吞吐穩定、schema 一致、成本可控；讀取路徑的設計目標是在不同的時間壓力下，用對的精度取回對的切面。兩者的效能瓶頸不同、擴展方向不同、治理責任也不同。把讀取當寫入的附屬處理，會在流量成長後遇到「寫入正常但查詢崩潰」的局面。

觀測資料的讀寫不對稱

觀測資料有一個 application data 不常見的特性：同一份資料被多種完全不同的查詢形狀讀取，每種查詢的時間壓力、精度需求、結果形狀差距可以到三個數量級。

寫入面相對單純。不管是 log、metric 還是 trace，寫入都是 append-only、schema 由產生端定義、吞吐由流量決定。寫入路徑的設計問題集中在 cardinality 控制（4.7）、pipeline 可靠性（4.11）與 sampling 策略。

讀取面則至少有三種模式，各自有獨立的 SLA、索引需求與資源消耗模型。把三種模式混在同一個未分化的 query engine 裡，會在任何一種模式的負載增長時拖累其他模式。

三種查詢模式

即席診斷

事故中的查詢，責任是在秒級內定位問題。

查詢形狀是精確 filter + 短時間範圍：拿一個 request id 查關聯事件、拿一個 error code 加 time window 撈錯誤樣本、拿一個 trace id 展開完整 span tree。

對儲存的要求：需要 hot tier 的完整索引、完整精度、毫秒到秒級回應。即席查詢幾乎不命中 warm 或 cold tier — 事故通常發生在「現在」或「剛才」。

資源特性：低頻（事故時才有）、單次掃描量小、但延遲要求最嚴格。事故中的每一秒等待都在消耗 MTTR。

聚合趨勢

Dashboard 跟 alert rule 的查詢，責任是提供持續的服務健康視圖。

查詢形狀是 group by + aggregation + 中等時間範圍：過去 5 分鐘的 error rate by service、過去 1 小時的 latency p99 by endpoint、過去 24 小時的 log volume by level。Dashboard 每 30 秒到 1 分鐘刷新，alert rule 每 1 到 5 分鐘 evaluate。

對儲存的要求：可以讀 recording rule 或 rollup 的預聚合資料，不需要完整精度。延遲容忍比即席查詢寬（秒級到十秒級），但查詢頻率比即席查詢高兩到三個數量級。

資源特性：高頻、穩定、佔 query engine 的常態負載大頭。一個 Grafana dashboard 有 20 個 panel、每 30 秒刷新一次 = 每分鐘 40 個查詢；十個團隊各自有 dashboard = 每分鐘 400 個背景查詢。

鑑識回溯

事後分析、合規稽核與根因調查的查詢，責任是在大時間範圍內還原完整脈絡。

查詢形狀是寬時間範圍 + 條件掃描：過去 30 天某 tenant 的所有 authentication failure、過去 90 天某 API 的 error 分布演變、某次事故前後 48 小時的完整 log 流。

對儲存的要求：會命中 warm 甚至 cold tier。完整性比延遲重要 — 漏掉一筆 audit log 比多等 30 秒更嚴重。可能需要 rehydrate（把 cold tier 歸檔資料暫時載回可查詢狀態）。

資源特性：低頻但單次掃描量極大。一個 cold tier 的全量掃描可能佔用 query engine 數分鐘的計算資源。

三種模式的設計衝突

三種模式搶同一個 query engine 時，聚合趨勢的穩定高頻負載會佔滿常態資源、擠壓即席診斷的突發需求；鑑識回溯的大範圍掃描會吃掉臨時資源、拖慢同時進行的即席查詢。

事故中是衝突最嚴重的時刻：incident commander 在做即席診斷、dashboard 在高頻刷新聚合趨勢、事後調查團隊可能同時在做鑑識回溯。三種負載同時打在同一個 query engine 上，誰先退讓取決於 query 資源治理的設計。

Storage tiering 與查詢路由

Storage tiering 在讀取路徑上的責任不只是降低儲存成本，而是為不同時間範圍的查詢提供對應的查詢能力。每一層的儲存介質、索引密度、資料精度共同決定該層能回答什麼問題。

每一層的查詢能力

查詢跨越 tier 邊界時，回應時間由最慢的 tier 決定。Dashboard 時間範圍從「最近 1 小時」（全部 hot）拉到「最近 30 天」（hot + warm + cold），查詢延遲可能從毫秒跳到分鐘。這個延遲跳變需要在 dashboard UI 上提示使用者。

查詢路由的設計

查詢路由的責任是根據查詢的時間範圍跟精度需求，自動選擇最合適的 tier 跟資料精度。

• 時間範圍在 hot tier 內：直接查 raw data，完整精度。
• 時間範圍跨越 hot 跟 warm：hot 部分查 raw data、warm 部分查 rollup series，query engine 負責拼接。
• 時間範圍延伸到 cold tier：cold 部分需要 rehydrate 或走 object storage 查詢路徑，延遲大幅增加。

查詢路由的透明度影響使用者信任。使用者需要知道目前看到的資料是什麼精度、來自哪一層、是否有 freshness lag。Grafana 的 annotation 機制可以在 dashboard 上標示 tier 邊界跟精度切換點，避免使用者把精度變化誤讀成服務異常。

Rehydrate 的操作成本

Cold tier 的資料通常儲存在 object storage（S3、GCS、Azure Blob），查詢前需要 rehydrate — 把資料從歸檔格式解壓、重建索引、載入到可查詢狀態。這個操作有時間成本（分鐘到小時）、儲存成本（臨時佔用 hot/warm 空間）跟計算成本（CPU 用在解壓跟索引重建）。

Rehydrate 是事故事後分析跟合規稽核的常見操作。設計 tiering 時要把 rehydrate 的 SLA（多久可以完成）、容量（同時可以 rehydrate 多少資料）跟觸發方式（手動 / API / 自動 policy）納入規劃。

Pre-aggregation 策略

Pre-aggregation 是把讀取時的計算成本轉移到寫入時的策略。觀測領域有三種常見的 pre-aggregation 機制，適用場景跟維護成本不同。

Recording rule

Recording rule 在 TSDB 層定期執行 query expression，把聚合結果寫成新 series。適合 metrics 的高頻聚合查詢（SLO burn rate、error ratio、跨服務 latency summary）。

Recording rule 的維護成本集中在規則增長後的管理。數百條 recording rule 需要命名慣例、版本控制、執行時間監控（rule evaluation duration）與定期審計（是否有 rule 不再被 dashboard 或 alert 引用）。

Log-to-metric 轉換

在 collector 端把高頻 log pattern 轉成 metric。適合「從 log 衍生的聚合查詢」— 例如把 level=error 的 log 計數轉成 error_log_total counter，把 specific exception 的出現率轉成 gauge。

Log-to-metric 的好處是讓 dashboard 讀 metric 而非重掃 log volume。維護成本在於 collector 配置要跟 log schema 保持同步 — log 的 field name 改了，轉換規則沒跟著改，metric 會靜默歸零。

Rollup / downsampling

Rollup 把高精度時間序列聚合成低精度版本。適合長時間範圍的趨勢查詢（90 天 error rate 趨勢、capacity planning 的年度成長曲線）。

Rollup 的設計關鍵是聚合函數必須按 metric type 選擇。Counter 用 sum、gauge 用 average（或 min/max 保留極端值）、histogram 需要保留 bucket boundary 而非做 average（否則 percentile 計算會失真）。混用聚合函數是 rollup 最常見的 silent data corruption。

Pre-aggregation 的維護成本

Pre-aggregation 不是免費的。每一條 recording rule、每一個 log-to-metric 轉換、每一層 rollup 都需要：

• 儲存空間：預聚合結果本身佔用 series 或 index 空間，增加 cardinality 負擔。
• 計算資源：定期執行聚合需要 CPU，rule evaluation lag 會讓 dashboard 看到過期資料。
• 配置維護：規則需要跟 schema、label、service 保持同步，漂移會靜默產生錯誤資料。
• 除錯成本：dashboard 讀的是 recording rule 輸出，事故時可能需要同時查 raw data 驗證 recording rule 是否正確。

設計時的判準是：預聚合的讀取節省是否大於維護成本。高頻讀取（dashboard auto-refresh、alert evaluation）的聚合計算值得 pre-aggregation；低頻讀取（月度報表、偶發 ad-hoc query）直接查 raw data 更簡單。

Query 資源治理

觀測平台的 query engine 是共用資源，需要顯式的治理機制避免單一查詢類型或單一使用者耗盡資源。

Query priority 與排程

Query engine 需要知道每個查詢的優先級，在資源不足時讓高優先查詢先執行。

Query timeout 差異化

不同查詢類型設不同的 timeout：alert evaluation 設短 timeout（30 秒到 1 分鐘，跑不完說明 query 有問題）、即席診斷設中等 timeout（1 到 5 分鐘）、鑑識回溯允許較長 timeout（10 到 30 分鐘）。統一 timeout 會讓鑑識查詢被過早截斷、或讓 alert evaluation 等太久。

Query cost estimation

在查詢執行前估算掃描量（掃描的 series 數、time range、shard 數），超過閾值的查詢被拒絕或降級。避免單一 heavy query（例：跨所有 service 的 90 天 full-resolution 聚合）拖垮 query engine。

Query cost estimation 對使用者的回饋要足夠清楚。拒絕查詢時要說明「這個查詢預計掃描 N 條 series × M 天，超過單次查詢上限；請縮小時間範圍或增加 filter 條件」，而不是只回 timeout 或 500 error。

Query cache

聚合趨勢查詢的特徵是高頻重複 — 同一個 dashboard panel 每 30 秒查一次，查詢的時間範圍大部分重疊。Query cache 在 query-frontend 層快取最近的聯合結果，下一次刷新只需要增量計算新進的資料區間。

Thanos Query Frontend、Mimir Query Frontend、Grafana Cloud 的 query splitting + caching 都實作這個模式。Cache 的命中率直接影響 query engine 負載 — 高命中率讓 query engine 的常態負載下降、留更多資源給即席查詢。

觀測領域的讀寫分離：CQRS 的特化應用

觀測查詢設計的底層問題是讀寫不對稱 — 寫入跟讀取的形狀、頻率、SLA 都不同，單一模型無法同時服務。這個問題在 application data 層有成熟的設計框架：CQRS。觀測領域面對的是同一類不對稱，但不對稱的程度更極端，實作層級也不同。

觀測場景的不對稱比 application 更極端

CQRS 知識卡描述了讀寫不對稱的三個維度（形狀、頻率、SLA）。觀測場景在這三個維度上都比典型 application 更極端：

形狀不對稱：application 的 read model 通常是一到兩種（列表頁、報表）。觀測的讀取面至少三種：即席診斷要精確 filter + 完整精度、聚合趨勢要 group by + pre-aggregated、鑑識回溯要寬範圍 + 完整性優先。三種形狀對索引、精度、儲存層的需求互斥。

頻率不對稱：application 的讀寫比通常在 10:1 到 100:1 之間。觀測的 dashboard 每 30 秒刷新一次、alert 每分鐘 evaluate、十個團隊各自有 dashboard — 讀取頻率可以到寫入的千倍以上，而且是持續穩定的背景負載而非突發。

SLA 不對稱：application CQRS 的讀寫 SLA 差距通常在同一個數量級（毫秒 vs 數百毫秒）。觀測的三種讀取模式 SLA 跨三個數量級 — 即席診斷要求毫秒到秒級、聚合趨勢容忍秒到十秒級、鑑識回溯容忍分鐘級。

觀測領域怎麼實作讀寫分離

CQRS 在 application 層透過 event handler、projector、read store 實作。觀測領域用自己的 first-class 機制做同樣的事：

CQRS 的代價在觀測領域同樣存在

CQRS 知識卡列出的三項代價（最終一致性、同步可靠性、多模型維護）在觀測場景都找得到對應：

最終一致性：Recording rule 每 N 秒 evaluate 一次，dashboard 看到的聚合結果落後 raw data。Rollup 的延遲更長。事故中 incident commander 看 dashboard 做決策時，需要知道資料的 freshness — 這就是 CQRS 的 read model 延遲在觀測領域的具體表現。

同步可靠性：Recording rule evaluation 本身可能失敗（expression 太重跑不完、TSDB 暫時不可用）。Log-to-metric 轉換可能因 schema 漂移而靜默歸零。這些同步失敗跟 application CQRS 的 projector 失敗是同一類問題 — read model 看起來有資料但其實是過期的。

多模型維護：Metric schema 變更後，raw series、recording rule、rollup、dashboard query 都需要同步更新。Recording rule 引用的 label name 改了沒跟著改，aggregation 結果會靜默錯誤。這跟 application 的「schema migration 要同時更新 write model 跟所有 read model」是同一個維護負擔。

術語邊界

觀測領域的讀寫分離跟 CQRS 概念對應，但在業界溝通中直接說「log 的 CQRS」或「metrics 的 CQRS」會造成混淆。觀測領域有自己的 first-class 術語（recording rule、rollup、tiering、query routing），跟 application CQRS 的術語（command、query、projection、read model）平行但不互通。

理解 CQRS 的讀者可以把觀測查詢設計視為「infrastructure-level 的讀寫分離」，同樣的設計原則（分離的動機、最終一致性的代價、多模型維護的負擔）在不同層級重複出現。但設計決策時要用觀測領域的術語，把 recording rule 跟 rollup 當第一等公民，而非 CQRS 的衍生品。

核心判讀

判讀觀測查詢設計時，先看三種查詢模式是否有對應的資源與資料形狀，再看 pre-aggregation 跟 tiering 是否對齊實際查詢負載。

重點訊號包括：

• 即席查詢在事故中的延遲是否在秒級以內
• Dashboard 刷新是否佔用過多 query engine 資源
• 長時間範圍查詢是否有 rollup / recording rule 支撐
• Storage tiering 的查詢路由是否對使用者透明
• Alert evaluation 是否有最高 query priority
• Pre-aggregation 規則是否跟 schema 保持同步

判讀訊號

• Dashboard 載入時間持續退化、panel timeout 增加
• Alert rule evaluation duration 成長、偶發 missed evaluation
• 事故中即席查詢被 dashboard 背景負載擠壓
• 長時間範圍的查詢精度突變但使用者不知道
• Recording rule 輸出跟 raw query 結果不一致
• Rehydrate 需求頻繁但沒有預設流程
• Query engine CPU 被少數 heavy query 佔滿

反模式

交接路由

• 4.1 log schema：log 的即席 / 聚合 / 鑑識三種查詢模式細節
• 4.2 metrics：metrics 的 recording rule 與 rollup 設計
• 4.7 cardinality / cost：storage tiering 對查詢能力的影響
• 4.11 telemetry pipeline：讀取路徑作為 pipeline 的延伸
• 4.15 cost attribution：query 資源的成本歸屬
• 4.17 telemetry data quality：pre-aggregation 與 raw data 的一致性驗證
• 4.18 operating model：query 資源治理的 ownership
• Monitoring 讀寫分離：Monitor 專案的讀寫分離具體應用

完整鏈路

以使用者在 web app 點擊「結帳」為例，一次操作產生的觀測鏈路：

 1Browser: user clicks "checkout"
 2  → RUM SDK 建立 client span（type: resource / xhr）
 3  → HTTP POST /api/checkout + W3C traceparent header
 4    → Server middleware 提取 trace context
 5    → Server 建立 child span（checkout-handler）
 6      → DB query span（order insert）
 7      → Cache span（inventory check）
 8      → Queue span（event publish）
 9    → Server 回 200 + response body
10  → Browser 收到 response → resource timing 結束
11  → RUM SDK 關閉 client span（記錄 duration + status）
12  → 統一 trace waterfall：client span 是 root、server spans 是 children

鏈路的每一段都需要 trace context 正確傳遞。任何一段斷掉，trace waterfall 就會出現孤立的 span — server 端看到的 trace 跟 client 端看到的 trace 是兩條不相關的紀錄。

Trace context propagation

W3C traceparent header

W3C Trace Context 是跨 vendor 的標準 propagation 格式。Header 長這樣：

1traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
2              │  │                                │                  │
3              │  trace-id (32 hex)                 parent-id (16 hex) flags
4              version

RUM SDK 在發起 XHR / fetch 時把 traceparent 注入 request header。Server 的 trace SDK 從 header 提取 trace-id 和 parent-id，建立 child span。

Client 端注入

各 RUM SDK 的注入方式：

三者的共同模式：只對設定的 domain 注入 trace header。不設定白名單時，header 不會被注入到第三方 API（避免 information leakage）。

Server 端提取

Server 端的 trace SDK（OTel auto-instrumentation 或 vendor agent）從 incoming request 的 header 提取 trace context：

 1# OTel Python 範例 — auto-instrumentation 自動處理
 2# 不需要手動提取，middleware 自動讀 traceparent header
 3# 建立的 span 會繼承 client 傳來的 trace-id 和 parent-id
 4
 5# 手動提取（不用 auto-instrumentation 時）
 6from opentelemetry.propagate import extract
 7ctx = extract(carrier=request.headers)
 8with tracer.start_as_current_span("checkout-handler", context=ctx):
 9    # server logic
10    pass

CORS 限制

跨域請求時，browser 的 CORS preflight 會阻止非標準 header。Server 需要明確允許 trace header：

1Access-Control-Allow-Headers: traceparent, tracestate, sentry-trace, baggage

CORS 是 client-server trace 串接最常見的斷裂原因。Server 沒有回 Access-Control-Allow-Headers: traceparent 時，browser 會 strip 掉 trace header，server 端收到的 request 沒有 trace context，建立的 span 成為新的 root — 跟 client span 斷裂。

跨層 correlation 設計

Trace ID 串接

統一 trace-id 是最基本的 correlation。同一個 trace-id 下的所有 span（client + server）可以在 trace backend 的 waterfall view 裡按時間排列，看到完整的 request 路徑。

Session 跟 transaction 的 mapping

RUM SDK 的 session（使用者的一次造訪）包含多個 user action，每個 action 可能觸發多個 HTTP request。Mapping 關係：

1RUM session
2  └── user action (click "checkout")
3        ├── HTTP request /api/checkout  →  server transaction (trace)
4        ├── HTTP request /api/inventory →  server transaction (trace)
5        └── client-side rendering time

Datadog RUM 和 Sentry 都支援從 session replay 點進去看對應的 server trace。這個 mapping 靠的是 RUM event 裡記錄的 trace-id，跟 server trace backend 裡的同一個 trace-id 做 join。

Breadcrumbs 跟 server log 的時間對齊

RUM SDK 收集的 breadcrumbs（使用者操作序列：page view → button click → form submit）跟 server-side log 的 timestamp 需要可比對。時間對齊的前提是 client 和 server 的 clock 差距在可接受範圍（通常 < 1s）。

NTP 同步的 server 端 clock 通常精準。Client 端（browser）依賴使用者裝置的系統時間，可能偏差數秒到數分鐘。RUM SDK 通常會記錄 relative timing（相對於 session 開始的 offset），而非絕對 timestamp，來降低 clock skew 的影響。

Error correlation

Client-side JS error 跟 server-side 5xx 可能是同一個問題的兩面。Correlation 方式：

• 同一 trace-id：client error 發生在某個 HTTP request 的 response 處理中，該 request 的 trace-id 跟 server-side 500 的 trace-id 相同 — 直接 correlation
• 時間窗 + endpoint：client error 沒有 trace-id（例如 CORS block 導致 request 沒發出），用時間窗 + endpoint 模式做 fuzzy correlation
• Server 無異常但 client 報錯：client-side rendering error（JSON parse failure、type error），server 端看不到 — 需要 RUM 獨立分析

Evidence package 整合

把 client-side 訊號納入 4.20 Observability Evidence Package 時，需要額外記錄：

Client perceived latency 跟 server-side latency 的差異本身就是一個觀測訊號。差異穩定在 50ms 是正常的 network overhead；差異突然從 50ms 跳到 500ms 代表網路或 CDN 出了問題 — 而這個問題 server-side dashboard 完全看不到。

失敗場景判讀

Vendor 整合模式

同 vendor 組合的串接最自然。跨 vendor 組合只要雙方都支援 W3C Trace Context，trace-level correlation 可以通；但 session-level 的功能（session replay → server trace）需要同 vendor 才有。

交接路由

• 4.10 Client-side / Synthetic / RUM：概念定位和 vendor 選型
• 4.3 Tracing Context：server-side trace context 設計
• 4.22 Checkout API Evidence Package：evidence 整合到 release gate
• 4.20 Observability Evidence Package：evidence 欄位標準
• Monitoring 03 SDK 設計：client-side SDK 埋點設計
• Monitoring 06 商業方案：Sentry / Datadog RUM 的 client-side 能力比較
• 監控資料的雙重用途：同一份 event data 如何同時服務行為分析與訊號治理