可觀測性基礎 (Logs / Metrics / Traces)

每種訊號回答哪一類問題、為什麼缺一不可，以及在系統設計版圖中的座標。

在單體應用的年代，排查問題幾乎等於「SSH 進機器看 /var/log/app.log + 跑 top」。但當一個結帳請求會橫跨 API Gateway、訂單服務、風控模型、庫存資料庫與外部金流共十幾個節點時，沒有任何一台機器的本機日誌能單獨回答「為什麼這筆訂單卡了 4 秒」。

傳統監控（Monitoring）處理的是已知的未知（Known Unknowns）：你事先知道 CPU 會滿、硬碟會爆、5xx 錯誤率會升高，所以預先寫好告警規則；而可觀測性（Observability）處理的是未知的未知（Unknown Unknowns）：只有當「iOS 18.1 客戶端 + 東京區域 + 特定促銷券組合」才會觸發的死鎖，你不可能事先為這個組合寫一條專屬告警，必須靠訊號的任意維度切片與關聯分析把問題挖出來。

三大訊號的資料模型與成本光譜

Logs、Metrics、Traces 常被稱為可觀測性的三大支柱（Three Pillars），但工程師在架構設計上真正該記住的不是名詞，而是它們用什麼儲存成本，換取回答哪一類問題的能力：

三大訊號的工程折衷：Metrics 將單筆請求壓縮成統計數字以換取極低查詢延遲與固定成本；Logs 保留全部細節但成本隨流量線性暴增；Traces 則專門紀錄跨服務的因果關係。

Counter、Gauge、Histogram 與 Summary 的本質差異，以及為什麼對 P99 取平均會在面試直接出局。

時序資料庫（TSDB，如 Prometheus、CloudWatch Metrics 底層儲存）中的每一條時間序列（Time Series），都是由指標名稱（Metric Name）+ 一組排序後的 key="value" 標籤（Labels / Dimensions）唯一決定的。序列裡面只存放按時間排序的 (timestamp, float64) 樣本點。

四種核心指標型別

• Counter（單調遞增計數器）：只增不減，唯一歸零的時機是行程重啟（Process Restart）。例如 http_requests_total、payment_errors_total。查詢時絕不直接看絕對值，而是透過 rate(metric[5m]) 計算每秒增長斜率（QPS），TSDB 會自動偵測並補償重啟造成的數值重置（Counter Reset）。
• Gauge（瞬時水位計）：可增可減的當下快照。例如 memory_usage_bytes、goroutines_active、佇列當前堆積深度。適合取跨時間的 avg_over_time 或 max_over_time，但對 Gauge 算 rate() 毫無物理意義。
• Histogram（直方圖）：在採集端預先切好固定延遲桶位（Buckets，如 le="0.05"、le="0.1"、le="0.5"、le="+Inf"），每個桶位本質上都是一個獨立的 Counter，統計「落入該上界以下的累積請求數」。此外還會附帶 _sum（總耗時）與 _count（總請求數）兩條序列。
• Summary（客戶端摘要）：由應用程式在本地滑動視窗內直接算好 quantile="0.99" 後上報一個浮點數。雖然省去了桶位序列，但無法跨實例聚合，在分散式多副本環境中幾乎已被 Histogram 取代。

面試必考陷阱：為什麼百分位數（Percentiles）絕對不能直接平均或相加？

假設訂單服務有兩台實例 Pod A 與 Pod B。在過去 1 分鐘內：

• Pod A（正常節點，流量佔 99%）：處理了 9900 筆請求，每筆都在 10 ms 內完成，其本機算出的 P99_A = 10 ms。
• Pod B（發生資料庫連線池飢餓，流量佔 1%）：只處理了 100 筆請求，但全部卡死到 2000 ms 才回應，其本機算出的 P99_B = 2000 ms。

如果每個 Pod 用 Summary 型別各自上報自己的 P99，而你在儀表板上寫出「把所有 Pod 的 P99 取平均」：

但實際上，全站這 10000 筆請求裡面，有 9900 筆（剛好 99%）是 10 ms，剩下 100 筆（剛好 1%）是 2000 ms。全站真正的 P99 其實落在第 9900 筆與第 9901 筆的交界處（即 10 ms 附近，而 P99.1 才會跳到 2000 ms）；反過來，若 Pod B 處理了 200 筆慢請求（佔全站 2%），全站真實 P99 應該是 2000 ms，取平均算出來的 1005 ms 則會嚴重低估災情！

為什麼在 Metric Label 塞進 user_id 或 trace_id，會瞬間拖垮 Prometheus 記憶體並讓 CloudWatch 帳單破表。

TSDB 之所以能毫秒級回答「過去 6 小時每秒請求率」，是因為它為每一組唯一的標籤組合在記憶體中維護一個獨立的 Inverted Index 條目與壓縮 Chunk（例如 Gorilla XOR 壓縮需要同一條時間序列連續寫入許多點，壓縮率才會高）。

當你在程式碼裡寫下一行看似無害的指標打點：

http_request_duration_seconds_bucket{service="checkout", method="POST", status="200", user_id="u_948102"}

總活躍時間序列數（Active Time Series Cardinality）並不是各標籤可能取值數的「相加」，而是笛卡兒積（Cartesian Product）相乘，再乘上實例數與直方圖桶位數：

只要其中一個標籤是無界或高基數欄位（例如 user_id、order_id、ip_address、request_id、或是未歸一化的完整 URL Path /orders/849201），乘積就會從幾千條瞬間暴增到數千萬條。更糟的是，每個 user_id 只出現一兩次就不再產生新樣本，形成大量「只有 1 個數據點的短命序列（Churn）」——TSDB 既無法有效壓縮，索引表還會常駐在記憶體中，最終導致 Prometheus OOM 崩潰，或在按 Custom Metric 條數計費的 AWS CloudWatch（每條每月約 $0.30 USD）產出數十萬美元的天價帳單。

拆解器說明：一行帶有 _bucket 後綴的 Prometheus 指標，在底層會先乘上直方圖桶位數（10 個桶位加上 _sum 與 _count 共 12 條序列）與 Pod 實例數，再依序乘上每個標籤的基數。試著在上方點擊關閉 user_id 標籤，觀察活躍時間序列數如何從上億條瞬間降回數萬條的安全水位。

Prometheus 與 CloudWatch 的推拉取捨，以及高吞吐日誌管線如何做緩衝、削峰與冷熱分層。

Metrics 收集的兩大流派：Pull（拉取）vs Push（推送）

系統設計面試常問：「監控系統應該讓 Server 主動去拉（Pull），還是讓應用程式主動往外推（Push）？」這不是宗教戰爭，而是針對不同執行環境的工程取捨：

現代架構通常採混合模式：Kubernetes 內部常駐服務由 DaemonSet / StatefulSet 的 OTel Collector 就近 Pull，再由 Collector 統一批次透過 OTLP Push 到遠端託管 TSDB（如 Amazon Managed Service for Prometheus 或 GCP Cloud Monitoring）。

高吞吐日誌收集管線（Log Ingestion Pipeline）

與每隔 15 秒才產生一個數字的 Metrics 不同，每次請求都可能寫出數行結構化 JSON 日誌。若業務服務在處理請求的關鍵路徑上，直接同步透過網路呼叫 Elasticsearch 或 CloudWatch Logs API，一旦日誌後端發生 GC 停頓或網路抖動，就會直接阻塞甚至拖垮業務執行緒。

因此，生產級日誌管線必定遵守「本地非同步落盤 + Agent 採集 + 訊息佇列削峰 + 冷熱分層儲存」的四段式架構：

日誌管線的核心設計原則：業務程式永遠不直接連遠端日誌庫；當系統雪崩導致錯誤日誌暴增 50 倍時，Buffer Queue 負責擋下寫入尖峰，保護後端索引叢集不在此時跟著崩潰（佇列分區與保留機制詳見 Kafka 架構篇，倒排索引與分片寫入成本詳見搜尋與分析引擎篇）。

如何用 trace_id 與 Exemplars 把獨立的三座資料孤島串成一條無縫的排障動線。

早期企業最大的痛點是「三套 Agent、三份帳單、三座孤島」：Prometheus SDK 採 Metrics、Fluentd 採 Logs、各雲端廠商專屬的 X-Ray 或 Zipkin SDK 採 Traces。不僅侵入業務程式碼，更嚴重的是當告警響起時，工程師在 Grafana 看到 P99 飆高，卻無法一鍵跳轉到引發該尖峰的那筆 Trace 與對應的 Error Log。

OpenTelemetry（OTel）的解耦設計

CNCF 的 OpenTelemetry 透過將「產生訊號的 API/SDK」與「接收儲存的後端 Vendor」徹底解耦，成為現代雲原生系統的事實標準：

• 統一語意約定（Semantic Conventions）：強制規定 HTTP 狀態碼一律叫 http.response.status_code、服務名一律透過 Resource Attribute service.name 標記，確保三種訊號擁有完全一致的元資料欄位。
• OTel Collector（中樞路由器）：透過 Receivers → Processors → Exporters 管線，應用程式只要以標準 OTLP（OpenTelemetry Protocol，基於 gRPC/Protobuf 或 HTTP）將三種訊號發給本機 Collector，Collector 就能在記憶體中完成批次壓縮、敏感欄位脫敏（Redaction）、過濾高基數標籤，最後一分多路同時導出到 AWS CloudWatch / X-Ray、GCP Cloud Operations 或自建的 Prometheus / Tempo / Loki。

靠 Exemplars 與 trace_id 走完黃金排障閉環

既然我們在第 3 節強調「絕對不能把 trace_id 放進 Metric Label」，那要怎麼從一條聚合後的 Histogram 指標跳轉到具體的某筆慢請求 Trace？答案是 Exemplars（樣本錨點）。

當應用程式記錄一筆耗時 1.8s 的請求進 Histogram 的 le="2.0" 桶位時，OTel SDK 會在該桶位旁順手附帶一個輕量的 Exemplar 抽樣註記：# {trace_id="4bf92f3577b34da6"} 1.82 1730678400。它不會建立新的時間序列（因此零基數爆炸風險），而是在圖表上留下一顆可點擊的取樣星點：

sequenceDiagram
    participant Eng as 值班工程師
    participant TSDB as Metrics (Prometheus/CW)
    participant Trace as Traces (Tempo/X-Ray)
    participant Log as Logs (OpenSearch/Loki)
    TSDB->>Eng: 告警：checkout P99 > 1.5s
    Eng->>TSDB: 點擊 le="2.0" 桶位上的 Exemplar
    TSDB-->>Eng: 取得抽樣 trace_id="4bf92f..."
    Eng->>Trace: 以 trace_id 查詢完整呼叫樹
    Trace-->>Eng: 定位 inventory-db span 耗時 1.6s (status=ERROR)
    Eng->>Log: 以 trace_id + span_id 過濾結構化日誌
    Log-->>Eng: 取得死鎖 SQL 與完整 Stack Trace
  

三大訊號的串聯關鍵：Metrics 透過 Exemplar 夾帶抽樣的 trace_id 跳入 Traces；結構化 Logs 則在每一行 JSON 自動注入當前 Context 的 trace_id 與 span_id，讓最後一步檢索只需精準比對 ID，不必大海撈針（跨進程的 W3C Trace Context 標頭傳播與頭尾採樣策略，由分散式追蹤篇專門深入；而如何用這些指標計算 Error Budget 與多視窗燃燒率告警，則由 SLI/SLO 與告警篇負責）。

系統設計面試中關於可觀測性成本、可靠性與架構取捨的經典追問。

面試深度追問 FAQ