本章節從可觀測性（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。

小結#

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

原文出處#

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