可觀測性的過去與現在

可觀測性要解決的問題#

在單體架構的年代，排查問題的流程相對直覺：SSH 進伺服器、翻 log、看 CPU 和記憶體用量，大多數問題都能在一台機器上找到答案。但當系統演變為數十甚至數百個微服務，一個使用者請求可能經過 API Gateway、認證服務、訂單服務、庫存服務、支付服務……任何一個環節變慢或出錯，都可能導致最終的失敗。

這時候，傳統的做法就碰壁了：

你不知道該看哪台機器的 log── 請求經過的路徑是動態的
你不知道「慢」發生在哪裡── 每個服務各自回報正常，但端到端的延遲卻在攀升
你不知道問題的因果關係──A 服務的錯誤可能是 B 服務逾時造成的，而 B 服務逾時是因為資料庫連線池耗盡

可觀測性（Observability） 的目標就是讓你能從系統的外部輸出，推論出系統內部的狀態。這個概念源自控制理論：一個系統是「可觀測的」，意味著你可以僅透過觀察它的輸出，來判斷它內部發生了什麼事。

「可觀測性」這個詞最早來自 1960 年代匈牙利數學家 Rudolf Kálmán 的控制理論。在軟體工程中，它被重新定義為：在不修改系統的情況下，透過系統產生的遙測資料（Telemetry）來理解系統行為的能力。

Monitoring 與 Observability 的差異#

這兩個詞經常被混用，但它們的思維模式有根本性的不同：

Monitoring（監控） 是「已知的已知」── 你預先定義好要監控的指標和告警條件，當指標超過閾值就通知你。它回答的是：「我事先想到的那些問題，現在有沒有發生？」
Observability（可觀測性） 涵蓋「未知的未知」── 你不需要預先知道會出什麼問題，而是讓系統產生足夠豐富的資訊，讓你在問題發生後能夠自由探索和追查。它回答的是：「系統現在到底怎麼了？為什麼會這樣？」

Monitoring 是 Observability 的子集。一個具備良好可觀測性的系統，自然也能做好監控；但一個只有監控的系統，面對從未預料到的故障模式時就會束手無策。

判斷你的系統是否具備可觀測性的簡單標準：當一個你從未見過的問題發生時，你能不能在不部署新程式碼的情況下找出根因？如果可以，你的系統就是可觀測的。

可觀測性資訊 ── 三大支柱#

可觀測性的資訊來源通常被歸納為三大支柱（Three Pillars），每一種資訊類型各有其擅長回答的問題：

Metrics（指標）#

Metrics 是數值型的時間序列資料，用來回答「系統現在的狀態如何？」和「趨勢是什麼？」

例如：CPU 使用率 72%、每秒請求數 1,200、P99 延遲 320ms、錯誤率 0.5%
優勢：儲存成本低、查詢速度快、天然適合聚合與告警
限制：只告訴你「什麼東西變了」，不告訴你「為什麼」
典型場景：容量規劃、SLO 追蹤、健康狀態總覽、觸發告警

Metrics 就像汽車儀表板上的轉速表和油量表 ── 你一眼就能知道車子的整體狀態，但如果引擎出了問題，你需要打開引擎蓋才能找到原因。

Logs（日誌）#

Logs 是離散的事件紀錄，用來回答「在某個時間點，某個元件發生了什麼具體的事？」

例如：2024-01-15 10:23:45 ERROR [order-service] Failed to process order #12345: payment timeout after 5000ms
優勢：資訊最豐富、可以攜帶任意結構化或非結構化的上下文
限制：資料量大、儲存成本高、跨服務關聯困難
典型場景：除錯特定錯誤、稽核紀錄、了解業務邏輯的執行細節

結構化日誌（Structured Logging） 是現代可觀測性的基礎實踐。以 JSON 格式輸出日誌（包含 timestamp、level、service、trace_id 等欄位），比起純文字日誌，在查詢和關聯分析上有數量級的效率提升。

Traces（追蹤）#

Traces 是一個請求從頭到尾經過所有服務的完整路徑紀錄，用來回答「這個請求經過了哪些服務？每一段花了多久？瓶頸在哪裡？」

一個 Trace 由多個 Span 組成，每個 Span 代表一個操作（例如一次 HTTP 呼叫、一次資料庫查詢）
優勢：唯一能呈現跨服務因果關係的資訊類型
限制：實作成本較高、通常需要取樣（Sampling）來控制資料量
典型場景：診斷跨服務延遲、理解請求流程、發現服務依賴關係

Traces 就像物流追蹤系統 ── 你可以看到一個包裹從出貨、經過哪些轉運站、到最終送達的每一個環節和時間。

三大支柱的協作#

三種資訊類型不是互相替代，而是互相補充：

Metrics 告訴你「有問題了」── 錯誤率突然上升
Logs 告訴你「發生了什麼」── 某個特定錯誤訊息大量出現
Traces 告訴你「為什麼」── 錯誤源自下游某個服務的逾時

一個成熟的可觀測性系統，會讓你能夠從 Metrics 的告警出發，關聯到相關的 Logs，再追蹤到具體的 Trace，形成完整的排查鏈路。

可觀測性資訊的處理與使用#

從資料產生到最終被人或系統使用，可觀測性資訊會經過幾個階段：

產生（Instrumentation）：應用程式或基礎設施產生遙測資料。可以是自動的（例如 auto-instrumentation 框架）或手動的（在程式碼中明確埋點）
收集（Collection）：透過 Agent 或 Collector 將資料從來源蒐集起來
處理（Processing）：對資料進行過濾、轉換、聚合、取樣等操作，控制資料量並提升品質
儲存（Storage）：將處理後的資料寫入專門的後端儲存（時序資料庫、日誌儲存、Trace 儲存）
查詢與視覺化（Query & Visualization）：透過 Grafana 等工具查詢資料、建立 Dashboard、設定告警

在設計可觀測性架構時，處理階段往往是最容易被忽略卻最影響成本的環節。未經過濾的原始資料直接送進儲存，不僅浪費儲存空間，也會拖慢查詢速度。

資料收集 Pattern#

可觀測性資料的收集方式，大致分為兩種模式：

Push Model（推送模式）#

應用程式主動將資料傳送到收集端。

運作方式：應用程式內建 SDK 或 Library，定期將資料推送到指定的 Collector 或 Backend
優勢：應用程式可以控制何時送出資料、適合事件驅動型的資料（如 Logs、Traces）、適合短生命週期的任務（Batch Job、Serverless Function）
考量：需要在應用端設定目標位址、當收集端不可用時需要處理資料暫存或丟棄

Pull Model（拉取模式）#

收集端定期主動向應用程式抓取資料。

運作方式：應用程式暴露一個端點（例如 /metrics），收集端定期來拉取最新的資料
優勢：收集端完全掌控抓取頻率與對象、應用端不需要知道收集端在哪裡、容易做服務發現（Service Discovery）
考量：不適合短生命週期的任務（還沒被拉取就結束了）、應用端需要維護狀態直到被拉取

Prometheus 是 Pull Model 最具代表性的實作，而 OpenTelemetry 則以 Push Model 為主要設計。兩種模式沒有絕對優劣，許多實際架構會混合使用 ── 用 Pull 收集 Metrics，用 Push 收集 Logs 和 Traces。

常見元件名稱#

可觀測性生態系中有許多工具和元件，它們的名稱經常讓初學者困惑。以下是最常見的角色分類：

Agent：部署在應用程式旁邊（Sidecar）或主機上的輕量程式，負責收集本地的遙測資料並轉發。例如：Grafana Alloy、Promtail、Fluent Bit
Collector：集中接收來自多個 Agent 或應用程式的資料，進行處理（過濾、轉換、路由）後送往後端儲存。例如：OpenTelemetry Collector、Grafana Alloy
Exporter：將資料從一種格式或系統轉換並輸出到另一種格式或系統的元件。在 Prometheus 生態中，Exporter 特指將非 Prometheus 格式的指標轉換為 Prometheus 可抓取格式的程式。例如：Node Exporter、MySQL Exporter
Backend / Storage：專門儲存遙測資料的系統，通常針對特定資料類型最佳化。例如：Prometheus / Mimir（Metrics）、Loki（Logs）、Tempo（Traces）
Visualization：將儲存的資料以圖表、表格等形式呈現的前端工具。例如：Grafana

同一個工具可能同時扮演多個角色。例如 Grafana Alloy 既是 Agent 也是 Collector；Prometheus 既是 Collector（Pull Model）也是 Backend（內建時序資料庫）。理解角色比記住工具名稱更重要。

為什麼現代架構特別需要可觀測性#

最後，讓我們整理一下為什麼可觀測性在今天變得不可或缺：

微服務架構：服務數量爆增，單一請求的路徑變得複雜且動態，沒有 Traces 就無法理解端到端的行為
容器化與 Kubernetes：容器隨時被建立和銷毀，傳統的「SSH 進去看」完全行不通，必須依賴集中化的遙測資料
持續部署（CD）：部署頻率提高意味著問題更容易被引入，需要快速偵測和回溯變更影響
使用者期望：使用者對延遲和錯誤的容忍度越來越低，SLO（Service Level Objective）成為團隊的北極星指標
成本管理：雲端環境中，效能問題直接等於金錢問題，需要精確的資料來驅動最佳化決策

可觀測性不只是「運維團隊的事」，它是整個工程團隊理解和改善系統的基礎能力。在後續的章節中，我們會逐一深入每個支柱的工具與實踐。