本章節從可觀測性（Observability）的定義出發，整理三大訊號（Three Pillars）的演化與資料處理流程，作為理解後續工具篇的共同語言。

軟體中的 Observability#

Observability 一詞最早源自 1960 年代控制理論，核心想法是「透過系統對外的輸出，反推系統內部目前的狀態」，後續才被借用到軟體領域。與 DevOps、Agile 一樣，它在軟體中並沒有單一權威定義；CNCF Glossary V1 Ready 版本的說法大致是：

Observability 是描述應用程式的一種特性，指的是能否從外部輸出去理解系統當下的狀態；CPU 時間、記憶體、磁碟空間、延遲、錯誤率等都是可觀測的維度，系統越「可被觀測」，要看出它的健康狀況就越容易。

理解了系統當下狀態，無論是優化或問題排解都會變得相對輕鬆，這正是 Observability 想帶來的效益。

一句話檢視可觀測性#

作者在介紹 Observability 時喜歡用一句話收斂：

• 透過各種資訊，清楚了解系統狀態。

從這句話可以拉出兩個關鍵字進行自我檢視：

• 「資訊」：手上的資訊夠不夠？是不是缺少某些角度的訊號，導致根本沒有判斷依據？
• 「清楚」：即使有資訊，是不是各自為政，無法被有效串接，導致看到了卻看不懂？

第一個問題對應的是訊號不足，可以參考 CNCF Observability Whitepaper 列出的各種 Observability Signal 來補足，例如 Metrics、Logs、Traces。第二個問題對應的是 Data Silo（資料孤島）：訊號格式各異，要建立關聯並不容易。Whitepaper 也提供了相關討論，其中最直觀的關聯方式是「時間」—— 因為所有訊號終究是某個時刻的系統快照，把同一時間區段的不同訊號擺在一起檢視，就能拼出全貌。Grafana 的 Sync 功能就是把 Metrics 與 Logs 的查詢時間區間連動起來，方便排查時跨訊號比對。

Observability Signals 的演化#

最常被提到的「三本柱」（Three Pillars）— Metrics、Logs、Traces — 並不是一開始就以這個樣貌出現。較早期 Twitter 在 2016 年發表的「Observability at Twitter」中，描述了團隊的 four pillars：

• Monitoring：監控
• Alerting / Visualization：告警與視覺化
• Distributed Systems Tracing Infrastructure：分散式系統鏈路追蹤基礎設施
• Log Aggregation / Analytics：日誌彙整與分析

之後業界逐漸把它收斂為現在熟悉的三本柱：

• Metrics：系統的量化指標，例如 CPU 使用率、API 回應時間。
• Logs：系統中發生事件的紀錄，例如錯誤訊息、Exception。
• Traces：請求在不同服務之間流動的歷程，例如使用第三方 SSO 登入時，跨越前端、Backend、第三方服務、快取等多段呼叫所組成的完整路徑。

但「三本柱」這種講法暗示「缺一不可」，會讓人誤以為任何一根支柱倒了 Observability 就崩塌。實際上每一種訊號都可以獨立帶來價值。因此 CNCF Observability Whitepaper 改稱這些資訊為 Observability Signals，把 Metrics、Logs、Traces 尊稱為 Primary Signals，並列出其他訊號，例如 Profiles、Dumps。

從排查角度看，可以把 Signals 概略分為兩組：

• 徵狀組：以 Metrics 為主，告訴你「現在有狀況」，例如 CPU 飆升或 API 變慢，但通常無法直接告訴你原因。
• 脈絡組：由 Logs、Traces 等組成，補足事件當下的細節；脈絡越完整，越有機會拼出根因。

把 Metrics 視為警報器、把 Logs 與 Traces 視為案發現場的物證，能幫助你從「通靈式 debug」進化到「福爾摩斯式推理」。

訊號的處理流程#

Observability Signals 從產生到產生價值，可以拆成四個階段：

• 生成：訊號需要由某個來源產生，例如應用程式埋點、Agent 採集主機指標。
• 收集：把訊號從生成端蒐集起來，過程中可能加上一些初步處理，例如過濾、轉換。
• 儲存：把處理後的訊號存放起來，方便後續分析與查詢。
• 使用：透過視覺化、查詢、告警等方式真正用到這些訊號，達到提升可觀測性的目的。

[ 生成 ] -> [ 收集 ] -> [ 儲存 ] -> [ 使用 ]

之後章節介紹工具時，會標示它們屬於哪一個或哪幾個階段，這樣不只能看清楚不同工具如何分工，當市場上出現新工具時，也比較容易判斷它想解決的是哪一段的痛點，以及該怎麼調整既有的資料流。

收集 Pattern 與常見名詞#

在進入工具細節前，先建立幾個高頻詞彙的共識會非常有幫助。

常見的資料收集 Pattern：

• Push：訊號產生端主動把資料推送出去，收集端被動接收，常用動詞是 Push 或 Write。
• Pull：產生端把訊號暴露出來等別人來拿，收集端主動拉取，常用動詞是 Collect 或 Scrape。
• Proxy：介於產生端與最終收集端之間，可能主動或被動取得資料後再轉發，常用動詞是 Aggregate。

常見元件名稱：

• Collector：負責蒐集訊號，或扮演 Proxy 把訊號轉發出去的服務。
• Sink：原意接近「水槽」或接收器，部分工具會用這個詞稱呼最終收集端。
• Agent：跑在主機（Host）上的程式，負責採集機器層級的訊號送回後端，叢集中的每台機器通常會部署同樣的 Agent。

監控 vs 可觀測性的本質差異#

「監控」（Monitoring）與「可觀測性」（Observability）常被混用，但兩者解決的問題層級並不相同。理解差異的最佳切入點，是 Donald Rumsfeld 那組著名的知識分類：

• 已知的已知（Known Knowns）：你知道它會壞，也知道壞了長什麼樣。例如「磁碟會滿」，於是預先設一條 disk_usage > 90% 的告警。
• 已知的未知（Known Unknowns）：你知道某個維度值得觀察，但不知道它何時、為何異常。例如「P99 延遲可能會升高」，於是畫一張延遲圖表盯著。
• 未知的未知（Unknown Unknowns）：你事前完全沒想到的故障模式。例如「某個特定 region 的某個 API 版本，只在快取失效且請求帶特定 Header 時才會超時」。

監控擅長前兩者，可觀測性才解得了第三者。

• 監控（Monitoring）：建立在「預定義」之上。你事先決定要收哪些指標、設哪些告警、畫哪些儀表板。它回答的是「我事先問過的問題」——系統是否健康、有沒有踩到我設好的紅線。
• 可觀測性（Observability）：建立在「事後自由探索」之上。當系統吐出足夠豐富、可任意切片的訊號時，你可以在事故當下，臨時組合出事前從未想過的查詢，去逼近一個全新故障的根因。它回答的是「我事先沒想到、現在才冒出來的問題」。

一個實務上的判斷標準很犀利：

在不部署任何新程式碼、不新增任何埋點的前提下，你能否查出一個全新問題的根因？ 如果可以，代表你的系統具備可觀測性；如果每遇到新問題都得先補一段 log、重新發版才查得下去，那你擁有的只是監控。

為什麼分散式系統讓「單體思維」失效#

在單體（Monolithic）時代，故障模式相對有限：機器、行程、那幾個關鍵端點。把它們全部列舉並設好告警，幾乎就涵蓋了大部分情況——這正是監控的舒適圈。

但分散式系統把可能的狀態空間炸開了：數十個服務、各自多個版本、跨 region 部署、彼此以非線性方式互相影響。故障往往來自「特定組合條件」下的湧現行為（Emergent Behavior），而這些組合的數量遠超任何人能事先列舉的告警清單。當「未知的未知」成為常態，靠窮舉告警的單體思維就必然失效，你需要的是事後能任意切片、下鑽到單筆請求的探索能力。

Alert ➡️ Metrics ➡️ Logs ➡️ Traces 的排查路徑#

承接前面「徵狀組 vs 脈絡組」的分類，多數事故的排查會沿著一條由粗到細、由徵狀到脈絡的路徑收斂：

flowchart TD
    A["Alert 告警觸發<br/>(知道「出事了」)"] --> B["Metrics 指標<br/>鎖定異常的時間區間與服務"]
    B --> C["Logs 日誌<br/>讀取該時段的錯誤訊息與例外"]
    C --> D["Traces 鏈路追蹤<br/>定位是哪一段呼叫、哪個下游拖垮整條請求"]
    D --> E["Root Cause 根因"]
    B -. "用 Exemplar 直接跳轉" .-> D

• Alert：告訴你「現在有狀況」，但通常不告訴你原因。
• Metrics：把範圍從「整個系統」縮小到「哪個服務、哪段時間」。
• Logs：在縮小後的時窗內，提供事件當下的具體細節與錯誤訊息。
• Traces：把一筆請求跨服務的完整歷程攤開，指出是哪一段、哪個下游造成問題。

這條路徑不是死板的瀑布——成熟的工具鏈允許你從 Metrics 上的 Exemplar 直接跳到對應的 Trace，少走中間的彎路（這正是第 05 章 Signal Correlation 要談的主題）。

排查路徑談的是「訊號之間如何接力」，而把這條路徑制度化為「事故何時該升級、Error Budget 還剩多少」的，是 SRE 的 SLO 與事故文化，屬於另一個層面的議題，詳見 SLO 與錯誤預算。本章聚焦在訊號本身與其資料模型。

小結#

本章把 Observability 從歷史脈絡、定義、訊號分類、處理流程、收集模式，到監控與可觀測性的本質差異整理成一條線，作為後續工具章節的共同語言。下一章開始將從已成為視覺化標配的 Grafana 切入，逐步走過 Metrics、Logs、Traces 等具體工具。

原文出處#

• 原書/iThome：https://ithelp.ithome.com.tw/articles/10319113