走完整個系列後，最後一章把視角從工具細節抽高，回顧過去的旅程，並嘗試展望 Observability 接下來可能的走向：從 CNCF 專案版圖、訊號類型的擴張、技術趨勢，到背後的商業景氣。

系列重點回顧#

整個系列大致可拆成這幾條主線：

  • Observability 初探：從整合更多訊號出發，配合 Grafana 這類能打破資料孤島（Data Silo）的單一介面平台，提升整體可觀測性。
  • Metrics：以 Prometheus 為核心，並回顧 Prometheus 之前的 StatsD、Zabbix 等老牌工具。
  • Logs：實作 Fluent Bit、Vector、Promtail 等多款收集器，搭配 Loki 進行儲存。
  • Traces：聚焦在幾乎成為業界標準的 OpenTelemetry 生態，以及 Tempo、Jaeger 等儲存方案。
  • 應用篇：訊號間的協同、Grafana Cloud 使用，以及 Production 環境特別需要關注的議題。

每篇 Lab 不只是「跑得起來」，背後也帶到一些觀念與小知識，例如：物件儲存（Object Storage）能大幅壓低成本、收集工具的流程都離不開「輸入－處理－輸出」三階段、Grafana 與 LGTM 的設計理念深受 Prometheus 與 Cortex 影響等。

一張表看懂工具光譜#

把生成、收集、儲存、使用四個階段攤開，每個 Pillar 對應的工具大致長這樣：

  • 生成
    • Metrics：eBPF、Prometheus Client、Prometheus Exporter、StatsD Client。
    • Logs：Application 自身輸出。
    • Traces：eBPF、OpenTelemetry SDK。
    • Profiles：eBPF、Pyroscope。
  • 收集
    • Metrics：Fluent Bit、Grafana Agent、OpenTelemetry Collector、Prometheus、StatsD、Vector。
    • Logs：Fluent Bit、Grafana Agent、OpenTelemetry Collector、Vector。
    • Traces：Fluent Bit、Grafana Agent、OpenTelemetry Collector、Vector。
    • Profiles：Grafana Agent、Pyroscope。
  • 儲存
    • Metrics：Cortex、Mimir、Prometheus、Thanos。
    • Logs：Loki。
    • Traces：Jaeger、Tempo。
    • Profiles：Pyroscope。
  • 使用
    • Metrics：Grafana、Zabbix。
    • Logs：Grafana。
    • Traces：Grafana、Jaeger。
    • Profiles：Grafana、Pyroscope。

把處理流程簡化下來其實只有四個提問：資料如何產生？要 Pull 還是 Push 收集？該用什麼格式儲存？查詢時又會碰到什麼挑戰？掌握這四題，剩下就像玩樂高，依需求自由堆疊。

CNCF 與 Observability 的未來#

提到 CNCF，很多人第一直覺是 Kubernetes 與容器技術。但 Observability 在 CNCF 中份量同樣不輕：Prometheus 緊接 Kubernetes 成為 CNCF 第二個專案，本系列介紹過的 Jaeger、OpenTelemetry、Thanos、Cortex 等也都是 CNCF 專案。原因不難理解，部署技術固然重要，但服務上線後能否穩定運作、創造價值，同樣關鍵。

加入 CNCF 後，專案需要保持廠商中立，這對使用者選型是一大保障，可避免被特定廠商鎖定（Vendor Lock-in）。

CNCF 把專案分為三個成熟階段，由低到高為：

  • Sandbox（沙箱）
  • Incubating（孵化）
  • Graduated（畢業）

選工具時，能先看一下其 CNCF 階段，作為穩定度的參考。

Observability Signals 的未來#

CNCF 的 Observability Whitepaper 建議把過去的「Three Pillars of Observability：Metrics、Logs、Traces」統稱為 Observability Signals，因為提供 Observability 的資訊不限這三種，例如 Profiles、Dumps 等也都能加入。

Jaeger 創作者 Yuri Shkuro 在 2022 年發表了一篇〈TEMPLE: Six Pillars of Observability〉，把訊號擴充成六種：

  • Traces：分散式追蹤，關注跨服務的呼叫順序與關係。
  • Events：會對系統造成影響的外部變更事件，例如部署、設定變動。
  • Metrics：量化的系統狀態或資源指標。
  • Profiles：程式執行底層資訊，常用於效能分析。
  • Logs：程式執行過程中產生的紀錄。
  • Exceptions：異常事件的紀錄，結構與資訊通常比一般 Log 更豐富。

這些命名雖然分歧，但共識是：不該把 Observability 訊號侷限在 Metrics、Logs、Traces；只要對提升 Observability 有幫助的資料，都可被納入。

引用文中的一句話：「Pillars are what you build upon, not the end goal.」這些柱子只是基礎，目標是利用它們解決問題，而不是把它們當成終點。

技術的未來：Profiles 與 eBPF#

Metrics 與 Logs 在傳統 Monitoring 中已有非常成熟的解法，Traces 經多年發展也匯聚成 OpenTelemetry。下一波的焦點則是 Profiles 與 eBPF。eBPF 已有完整生態與基金會，許多公司大舉投入，在 Observability 領域不只能用於 Profiles，也能產出 Metrics 與 Traces。eBPF 領域的代表專案 Cilium 在 2023 年成為 CNCF 第一個 eBPF 類型的 Graduated Project，也是這條趨勢的具體里程碑。

商業的未來#

評估一個技術領域是否有發展性，看商業公司的投入是最直觀的方式。從 Monitoring 進入 Observability 的時代，許多老牌廠商開始把「Observability」放進產品行銷，或重新定位自己。觀察當時市場上的代表性公司：

  • Grafana Labs：以 Grafana、Loki、Tempo 等開源產品為核心，並提供託管服務的 Grafana Cloud；2021 年估值約 30 億美金。
  • New Relic：APM（Application Performance Management）老牌玩家，曾在 NYSE 上市（NEWR），2023 年宣布以 65 億美金被收購。
  • Datadog：以基礎設施監控、APM、Log 管理整合為主，於 NASDAQ 上市（DDOG）。
  • Splunk：原以 Log 分析起家，後續延伸到 APM 與 AIOps，於 NASDAQ 上市（SPLK）。
  • Elastic：以 Elasticsearch 為基礎，逐步補齊完整 Observability 體系，於 NYSE 上市（ESTC）。
  • Dynatrace：提供 Observability、APM 與基礎設施監控服務，於 NYSE 上市（DT）。

這些公司的規模與動向反過來也說明 Observability 是一塊有真實商業價值的領域，個人在此累積的能力具備明確的職涯回報。

結語#

有人會說 Observability 不過是 Monitoring 的舊瓶新酒。從最高層次看，兩者目標確實都是「確保服務穩定」。但 Observability 更強調資訊背後的 Context，而非單看量化指標與告警。當 Metrics、Logs、Traces 等訊號相互連結，脈絡才會浮現，問題的根源才有機會被快速定位，而不只是知道「現在有事發生」。

收集多大、多多的資料，只能證明資料流設計得漂亮。真正的價值在於：Observability 是否真的縮短了問題處理時間（MTTR），甚至能在問題真正爆發前就先示警，讓事故被預防而不是補救。

訊號、工具、平台都只是基礎，真正讓組織受益的是「拿這些資料解決問題」的能力。希望整個系列能在概念、工具與一些歷史脈絡的層面，給未來想推動 Observability 的讀者一些起點。

原文出處#

  • 原書/iThome：https://ithelp.ithome.com.tw/articles/10339801
Backward Logs 概念總覽 Signal Correlation Forward