什麼是可觀測性？定義、三大訊號與入門路徑
可觀測性(Observability)是什麼?一文講清定義、與傳統監控的分別、logs/metrics/traces 三種訊號,以及由單機到微服務的入門路徑。
可觀測性(Observability)是指單靠系統對外輸出的數據——主要是 logs(日誌)、metrics(指標)與 traces(追蹤)——就能推斷系統內部狀態、回答「為什麼會這樣」的能力。 這個概念源自控制理論(control theory):不拆開機器,只看儀錶讀數,能否知道機器內部發生什麼事。套用到 IT 系統上,可觀測性高的系統,工程師遇到從未見過的故障,也能靠數據一步步查出根因,而不必靠估。
可觀測性在 IT 系統中的角色
現代系統有兩個特點,令「觀測」變成剛需:
- 分散。 一個請求會穿過負載均衡器、API gateway、多個微服務(microservices)、訊息佇列(message queue)與資料庫。故障點可以在任何一環。
- 多變。 容器與 auto-scaling 令基礎設施每分鐘都在變,昨日畫好的「系統架構圖」今日已過期。
在這種環境下,事前定義好的告警規則永遠追不上真實故障的形狀。可觀測性要解決的正是「未知的未知」(公開資料未有說明 unknowns):故障發生前,沒人知道要告警什麼;故障發生後,數據必須足夠詳細,讓人可以臨時追問系統任何問題。
與傳統監控的分別
| 維度 | 傳統監控(Monitoring) | 可觀測性(Observability) |
|---|---|---|
| 回答的問題 | 系統有沒有事?(is it up?) | 為什麼會有事?(why is it broken?) |
| 故障類型 | 已知的已知(預先定義告警) | 未知的未知(事後自由追查) |
| 數據形態 | 以聚合指標為主,數量少 | 保留原始事件細節,支援高基數(high cardinality)查詢 |
| 典型動作 | 看 dashboard、收告警 | 由一個用戶投訴出發,逐層下鑽(drill down)到根因 |
兩者不是取代關係。監控是可觀測性的一部分:metrics 告警負責「第一時間知道有事」,logs 與 traces 負責「知道之後查出原因」。
延伸閱讀APM 應用程式效能監控完整指南：從 Trace 到告警→
三種訊號:Logs、Metrics、Traces
Metrics(指標) — 以固定間隔採樣的數值,例如 CPU 使用率、每秒請求數、p99 延遲。體積小、易聚合,適合告警與長期趨勢,但經過聚合,細節有限。
Logs(日誌) — 系統運行時逐條記錄的事件,例如錯誤堆疊(stack trace)、請求明細。細節最豐富,但數量大、格式不一,需要集中收集、索引與保留策略,否則查障時大海撈針。
Traces(追蹤) — 一個請求橫跨多個服務的完整路徑,逐段記錄耗時與狀態。微服務環境下「慢在哪一環」幾乎只能靠 trace 回答。深入介紹可參考 APM 應用程式效能監控指南。
三者互相關聯才是完整答案:metric 告警觸發 → trace 定位慢在哪個服務 → log 給出該服務當刻的錯誤細節。
由訊號到平台:Observability Platform 是什麼
單獨收集三種訊號並不難,難在關聯(correlation):同一個 trace ID 要能在日誌裏搜到,同一台主機的 metrics 要能與其上運行的服務對應。可觀測性平台(observability platform)的價值正在於此——統一數據模型、統一查詢介面,把 RUM(真實用戶監控)、synthetic monitoring(合成監控)、基礎設施指標也納入同一視圖。選型時要留意平台與單點工具的界線:工具解決單一訊號,平台解決訊號之間的關聯。
入門路徑(由簡到深)
- 第 1 步 — Metrics 告警:先把主機與核心服務的 RED 指標(rate、errors、duration)接入 dashboard,設定基本告警。
- 第 2 步 — 集中日誌:把分散在各機的日誌集中到一處,支援全文搜尋與結構化欄位。
- 第 3 步 — 分散式追蹤:以 OpenTelemetry(開源標準,避免供應商鎖定)為核心交易鏈路加入 trace。
- 第 4 步 — 關聯與 SLO:把三種訊號用共同標籤(tags)串連,並以 SLO(Service Level Objective)與 error budget 管理告警優先級。
想深入了解概念背後的工程取捨(三支柱批判、基數、burn-rate 計算),可讀英文版 Observability Fundamentals Guide。
延伸閱讀Datadog 替代方案 7 選（2026）：成本、功能與選型比較→
常見問題
Q. 可觀測性是否等於買一套工具?
不是。可觀測性首先是系統的屬性與團隊的實踐:程式要輸出足夠的訊號、標籤要統一、runbook 要齊。工具只是讓這些訊號可查、可用。沒有實踐配合,再貴的平台也只是昂貴的 dashboard。
Q. 小公司需要可觀測性嗎?
單體應用(monolith)加幾台虛擬機,基本 metrics 加集中日誌已足夠。可觀測性的價值隨服務數量與故障成本上升:微服務化、有 SLA 承諾、on-call 輪值的團隊,越早建立越着數。
Q. OpenTelemetry 與可觀測性有什麼關係?
OpenTelemetry(OTel)是採集三種訊號的開源標準,負責「數據怎樣產生與運送」;可觀測性平台負責「數據怎樣儲存、關聯與查詢」。用 OTel 採集、把數據送到任何相容平台,是現時避免供應商鎖定(vendor lock-in)的主流做法。
Q. 可觀測性數據會不會很貴?
會,如果不加管理的話。成本主要來自高基數指標、全量日誌索引與全量 trace 保留。常見控制手段:指標降基數、日誌分級保留、trace 採樣(sampling)。技術細節見 Observability Fundamentals Guide 的 cardinality 一節。
Q. 可觀測性與 APM 有什麼分別?
APM(應用程式效能監控)聚焦應用層的 trace 與效能;可觀測性是更大的概念,涵蓋基礎設施、日誌、用戶端體驗等全部訊號。可以這樣記:APM 是可觀測性在應用層的子集。詳見 APM 應用程式效能監控指南。
下一步
- APM 應用程式效能監控完整指南— trace、RED 指標與選型
- What is Observability(英文版)— 同主題英文深入版
- Observability Fundamentals Guide(英文)— SLO、基數與成熟度路線圖
