走到這裡，你已經從可觀測性的基本概念出發，經歷了三大支柱的原理、OpenTelemetry 的架構、各種後端工具的選型、到生產環境的實戰考量。最後，讓我們把視野拉遠一些，看看這個領域正在往哪裡走——以及你可以如何準備。

CNCF 可觀測性專案全景#

**Cloud Native Computing Foundation（CNCF）**是雲原生生態系的核心推手，其孵化的專案很大程度上定義了可觀測性的技術走向。

OpenTelemetry：事實標準#

OpenTelemetry 已經成為 Telemetry 資料收集的事實標準。它不是最早的、也不是唯一的，但它做到了前輩們沒做到的事——統一了 Metrics、Logs、Traces 三大信號的 API、SDK 和資料格式。

幾乎所有主流的可觀測性後端（無論開源或商業）都已經支援 OTLP 協定。選擇 OpenTelemetry 意味著你不會被鎖定在任何一個後端供應商上。

Prometheus：Metrics 的代名詞#

Prometheus 持續主導著 Metrics 領域。即使在 OpenTelemetry 的時代，PromQL 仍然是最廣泛使用的 Metrics 查詢語言，Prometheus 的資料模型也深刻影響了後續的每一個 Metrics 系統。

其他重要專案#

  • Jaeger / Zipkin：分散式追蹤的先驅，但隨著 OpenTelemetry 的崛起，它們的角色逐漸轉向純後端
  • Fluentd / Fluent Bit：Log 收集領域的老將，在 OpenTelemetry Collector 的 Log 支援成熟之前，它們仍然是可靠的選擇
  • Thanos / Cortex / Mimir：Prometheus 的長期儲存與高可用擴展方案

CNCF 專案有不同的成熟度等級：Sandbox（沙箱）、Incubating（孵化中）、Graduated（畢業）。在選型時，優先考慮 Graduated 或至少 Incubating 等級的專案，它們的社群活躍度和穩定性更有保障。

可觀測性資訊的未來#

從三大支柱到統一信號#

過去我們習慣把 Metrics、Logs、Traces 當作三個獨立的世界——用不同的工具收集、不同的後端儲存、不同的介面查詢。OpenTelemetry 正在改變這一切。

統一收集已經實現：一個 OTel SDK 就能產生三種信號，一個 OTel Collector 就能處理和轉發所有類型的 Telemetry 資料。下一步是信號之間的關聯（Correlation）——從一個異常 Metric 跳到相關的 Traces，再從 Trace 跳到對應的 Logs，形成無縫的排查體驗。

Profiling 成為第四支柱#

**Continuous Profiling（持續性能剖析）**正在成為可觀測性的第四大信號。它回答的問題是：「我的程式把 CPU 時間和記憶體花在哪裡？」

OpenTelemetry 已經將 Profiling 納入其規範中。與傳統的按需 Profiling 不同，Continuous Profiling 是持續在背景運行的，開銷極低，但能在問題發生時提供精確的效能熱點資訊。

從 Telemetry 到 Observability#

一個正在發生的思維轉變是：收集資料（Telemetry）只是手段，獲得洞察（Observability）才是目的。

擁有 PB 級的日誌和數十億條 Trace 並不代表你有可觀測性。真正的可觀測性是：當一個你從未見過的問題發生時，你能夠僅靠現有的資料，在合理的時間內理解發生了什麼。這需要的不只是更多資料，還有更好的關聯、上下文和查詢工具。

可觀測性技術的未來#

eBPF：零侵入式觀測#

**eBPF（Extended Berkeley Packet Filter）**是 Linux Kernel 中的一項技術，允許在不修改應用程式碼的情況下，從 Kernel 層面收集 Telemetry 資料。

這代表什麼？你可以在完全不修改任何一行程式碼、不引入任何 SDK的情況下，獲得：

  • 網路層面的請求追蹤（HTTP、gRPC、SQL）
  • 系統層面的效能指標（CPU、記憶體、I/O）
  • 安全層面的行為監控（系統呼叫、檔案存取）

eBPF 特別適合那些無法修改程式碼的場景——第三方服務、Legacy 系統、或者對效能極度敏感的環境。

eBPF 不是 OpenTelemetry 的替代品，而是互補。eBPF 提供系統層面的觀測，OpenTelemetry 提供應用層面的觀測。兩者結合可以覆蓋更完整的觀測維度。

AI/ML 輔助的異常檢測與根因分析#

AIOps 這個詞已經被過度行銷了，但 AI/ML 在可觀測性中確實有一些實際的應用場景：

  • 異常檢測（Anomaly Detection）：靜態閾值無法適應所有情境（工作日 vs 週末、尖峰 vs 離峰）。ML 模型可以學習正常的行為模式，自動標記異常
  • 根因分析（Root Cause Analysis）：當數百個告警同時觸發時，ML 可以幫助判斷哪個是根因、哪些是連鎖反應
  • 預測性警報（Predictive Alerting）：在問題實際發生前，根據趨勢預測可能的故障

AI/ML 在可觀測性中仍然處於早期階段。目前它更適合作為輔助工具——幫助人類更快發現問題，而非完全取代人類的判斷。對那些號稱「全自動根因分析」的產品，保持健康的懷疑態度。

列式儲存與新一代查詢引擎#

可觀測性資料的查詢模式（時間範圍掃描、聚合計算、按 Label 過濾）天然適合列式儲存（Columnar Storage）。Apache Parquet 格式和基於列式儲存的查詢引擎正在改變可觀測性後端的架構：

  • 更高的壓縮率：同一個 Column 的資料類型相同，壓縮效果遠好於行式儲存
  • 更快的聚合查詢：只讀取需要的 Column，大幅減少 I/O
  • 標準化的格式：Parquet 是一個開放標準，不會被特定供應商鎖定

可觀測性商業的未來#

開源與商業的平衡#

可觀測性領域有一個有趣的商業模式演變：

  • Grafana Labs：核心工具（Grafana、Loki、Tempo、Mimir）保持 AGPLv3 開源，透過 Grafana Cloud 託管服務獲利。這種模式讓社群受益，同時建立了可持續的商業模式
  • Elastic：從完全開源（Apache 2.0）轉向 SSPL/Elastic License，限制雲端供應商直接提供託管服務。這引發了社群的爭議，也催生了 OpenSearch 等分支
  • Datadog / New Relic / Splunk：純商業 SaaS 模式，提供一站式解決方案，但成本隨資料量增長而快速攀升

開源不等於免費。自建可觀測性系統需要投入人力運維，這個成本容易被低估。選擇自建還是使用託管服務，核心考量是：你的團隊有沒有足夠的人力和專業知識來運維這些系統？

成本持續是企業關注焦點#

隨著系統規模增長，可觀測性的費用往往成為雲端帳單中增長最快的項目之一。這推動了幾個趨勢：

  • 成本意識的工具選擇：越來越多團隊從商業 SaaS 遷移到開源自建，或採用混合策略
  • FinOps for Observability：像管理雲端資源一樣管理可觀測性成本——追蹤、分配、優化
  • 資料分層與智慧取樣：不是所有資料都需要即時查詢能力，分層儲存和智慧取樣是控制成本的關鍵手段

給讀者的行動建議#

讀完這本書，你可能會覺得可觀測性的世界很複雜。確實如此，但你不需要一次到位。以下是一條務實的行動路徑：

  • 從 OpenTelemetry 開始：無論你選擇什麼後端，從 OTel 開始都不會錯。它是目前最安全的投資，因為你隨時可以切換後端而不需要修改應用程式碼
  • 選擇適合團隊規模的方案：3-5 人的團隊用 Grafana Cloud 或 Datadog 就好，不要自建；20 人以上的平台團隊才值得考慮自建 Grafana Stack
  • 先求有，再求好：先把基本的 Metrics 和告警建起來，能在問題發生時收到通知。然後逐步加入 Traces 和結構化 Logs
  • 建立可觀測性文化：工具只是一半，另一半是團隊的習慣。開發者在寫程式時就應該思考「這段程式碼如何被觀測」
  • 持續迭代：每次事故復盤後，問自己「如果有什麼觀測資料，我們可以更快發現這個問題？」然後把它加上去

可觀測性不是一個專案，而是一種持續的實踐。最好的可觀測性系統不是一次設計出來的，而是在每一次事故中學習、在每一次迭代中進化而成的。