跳轉到

6.3 監控、日誌與可觀測性#

上線之後：看不見的問題#

軟體部署上線（6.1、6.2 節）只是開始。真正的考驗在於——系統跑起來之後，你「看不看得見」它發生什麼事。 許多最棘手的問題（效能退化、間歇性錯誤、使用者悄悄流失）都發生在「你沒在看的角落」。

可觀測性（Observability） 就是「讓系統的內部狀態可以被外部觀察與理解」的能力。它建立在三大支柱之上：指標（Metrics）、日誌（Logs）、追蹤（Traces）——常被稱為「觀測的三大支柱」。

三大支柱#

1. 指標（Metrics）：數值化的健康狀態#

指標是「一段時間內可彙總的數值」，用來回答「系統現在健康嗎」：

  • 吞吐量（Throughput）：每秒請求數（RPS）
  • 延遲（Latency）：回應時間的分佈（p50、p95、p99）
  • 錯誤率（Error Rate）：失敗請求的比例
  • 資源使用：CPU、記憶體、磁碟、網路
  • 業務指標：訂單數、活躍使用者、轉換率

指標的特點是「聚合成數字、能連續監控」——你能用儀表板（Dashboard）即時觀看數字變化，並設定「超出閾值就警報」的規則。例如「p99 延遲超過 1 秒就警報」。

2. 日誌（Logs）：逐筆事件的紀錄#

日誌是「逐筆事件的文字/結構化紀錄」，用來回答「出了什麼事、那時刻發生什麼」：

2026-09-09 10:00:01 ERROR order=12345 "資料庫連線逾時"
2026-09-09 10:00:02 WARN  order=12346 "重試付款 (第 2 次)"

好的日誌應該：結構化（JSON）、有上下文（訂單 ID、使用者 ID）、有層級（DEBUG/INFO/WARN/ERROR）、不含敏感資料（見 13 章）。日誌是「事後調查」的主要工具——錯誤發生後，靠日誌還原現場。

3. 追蹤（Traces）：一次請求的完整旅程#

當系統是分散式（多服務、多容器）時，一次請求會跨越很多服務。追蹤把「同一次請求」流經的所有服務串起來，形成一條「旅程」記錄，回答「這次請求卡在哪裡、花了多少時間在哪個環節」。

[GET /orders/12345] 整體 340ms
 ├─ API Gateway      15ms
 ├─ 訂位服務         120ms  ← 這裡最慢
 │　　 └─ 資料庫查詢  90ms
 └─ 會員服務         180ms

追蹤的目的是定位分散式系統的瓶頸與錯誤——沒有追蹤，一次跨服務請求出問題，你根本不知道該查哪個服務（呼應 3.2 節「分散式系統難以知道哪裡壞了」）。

三者如何分工#

支柱 問的問題 使用時機
指標 系統現在健康嗎？你在惡化嗎？ 即時監控、趨勢、警報
日誌 出界時那一刻發生什麼？ 事後調查、除錯
追蹤 這次請求卡在哪個服務？ 分散式瓶頸與錯誤定位

一個實用的串聯：指標告訴你「p99 開始飆升（有問題）」，追蹤帶你找到「會員服務變慢了」，日誌讓你看「會員服務的資料庫查詢為何逾時」。三者互補，構成完整的「看得見」能力。

儀表板、警報與 SLO#

有了三大支柱的資料，還需要「人看得懂、且會被動地通知」的機制：

  • 儀表板（Dashboard）：把指標視覺化成圖表，讓團隊一眼掌握健康狀態
  • 警報（Alerting）：指標/條件達成時，自動通知相關人員（1 週 7 天 24 小時都有人在處理）
  • SLO / SLI：SLI（服務水準指標，如可用性 99.9%）、SLO（服務水準目標，如「每月可用性 ≥ 99.9%」）。有了量化的 SLO，團隊能判斷「服務是否達到我們承諾的使用者體驗」，並決定該投入多少心力在可靠性。

為什麼 SLO 重要：它把「可靠性」從模糊的「要穩定一點」變成「明確的數字目標」。沒有目標，你無法判斷「現在這樣夠不夠好」，也無法理性取捨「該加功能還是該修可靠性」。

從監控到可觀測性#

「監控（Monitoring）」與「可觀測性（Observability）」常被混用，但其實略有不同：

  • 監控：對「已知的、我們懷疑可能出問題的」指標持續量測與警報
  • 可觀測性：更廣的能力——能對「事先不知道、沒預期到的」問題進行探查，靠的是豐富的日誌、追蹤與上下文，讓你能「事後提出任意問題」

成熟系統兩者都要：用監控盯住已知風險，用可觀測性探索未知問題。尤其在 AI 時代，系統行為更複雜、更難預測，「能不能探查未知問題」的能力更加重要。

AI 時代的可觀測性#

AI 對可觀測性的影響也是雙向的：

AI 增加了觀測的難度：AI 系統的行為非確定且複雜（第二篇、第 11 章），除了傳統的指標，還需要觀測 Agent 的決策軌跡——它看了什麼上下文、呼叫了哪些工具、每一步的輸出為何。沒有「軌跡（Trace，Agent 層級）」的 AI 系統，出錯時根本無法調查（呼應 3.5 節「可評估性」）。

AI 提升了觀測的能力： - AI 協助分析日誌：海量日誌透過 AI 快速摘要、找出異常模式 - AI 自動偵測與自癒：這是下一節（6.4 節）的主題——AI 不只「看」，還能「自動反應」

本章小結#

  • 可觀測性讓系統狀態可以被外部觀察與理解
  • 三大支柱：指標（Metrics）、日誌（Logs）、追蹤（Traces）
  • 指標：健康狀態與趨勢、警報
  • 日誌：事後調查
  • 追蹤：分散式瓶頸定位
  • 搭配儀表板、警報、SLO/SLI形成完整的觀測機制
  • 監控盯已知風險，可觀測性探索未知問題
  • AI 時代：Agent 需要決策軌跡觀測；AI 也能協助分析與自動化觀測（下節）

想一想#

  1. 指標、日誌、追蹤三者各適合回答什麼問題？舉一個三者串聯調查的真實場景。
  2. 為什麼「SLO」能把可靠性的討論從「感受」變成「決策」？
  3. 你覺得「觀測一個 AI Agent 的行為」需要哪些不同於傳統系統的資料？（提示：決策軌跡）