Profiles 與 eBPF#

Metrics 告訴你「CPU 使用率是 90%」，但沒有告訴你「是哪個函數佔了 90%」。Traces 告訴你「這個請求花了 3 秒」，但沒有告訴你「3 秒之中，時間花在哪些程式碼路徑上」。要回答這類問題，你需要 Profiling。而 eBPF 則把觀測能力推向更深的層級——直接在 Kernel 中收集資料，不需要修改任何應用程式。

Profiles#

Continuous Profiling 的概念#

Profiling 是一種分析應用程式在執行期間資源使用情況的技術。它回答的是「程式的時間和資源花在哪裡」這個問題。

傳統的 Profiling 是一次性的——開發者在本地跑一個 Profiler、產生一份報告、分析完就結束。Continuous Profiling 則將這個行為變成持續性的：在生產環境中以低開銷不斷取樣，長期儲存，需要時隨時查詢。

Continuous Profiling 通常收集以下維度的資料：

  • CPU Profile：程式的 CPU 時間花在哪些函數上
  • Memory（Heap）Profile：記憶體分配在哪些物件和函數上
  • Goroutine / Thread Profile：並行單元的狀態分佈
  • Mutex / Block Profile：鎖競爭和阻塞的熱點

Continuous Profiling 有時被稱為可觀測性的「第四個信號」（在 Metrics、Logs、Traces 之後）。它填補了其他三個信號留下的「為什麼慢」這個關鍵問題。

Profiling 與 Metrics 的差異#

兩者容易混淆，但定位完全不同：

  • Metrics 回答「整體狀況如何」——CPU 使用率、記憶體用量、請求延遲。它是聚合過的、面向儀表板和告警
  • Profiling 回答「具體哪裡有問題」——哪個函數佔用最多 CPU、哪段程式碼分配最多記憶體。它是細粒度的、面向除錯和效能調優

打個比方：Metrics 像是車子的儀表板，告訴你引擎溫度過高；Profiling 像是打開引擎蓋，看到是哪個零件在過熱。

Grafana Pyroscope#

Grafana Pyroscope 是一個開源的 Continuous Profiling 平台。它負責接收、儲存和查詢 Profile 資料，並提供視覺化介面（經典的 Flame Graph）。

Pyroscope 在 Grafana 生態系中的定位，類似 Prometheus 之於 Metrics、Loki 之於 Logs、Tempo 之於 Traces——它是第四根柱子。在 Grafana 的介面中，你可以從 Trace 的某個 Span 跳轉到對應的 Profile，看到那段時間內該服務的 CPU 或記憶體使用熱點。

Flame Graph 的閱讀方式：橫軸代表 CPU 時間佔比，縱軸代表呼叫堆疊深度。越寬的方塊代表佔用越多資源的函數。找到最寬的「平頂」，那就是你的效能瓶頸所在。

eBPF#

eBPF 的革命性#

eBPF（Extended Berkeley Packet Filter）是 Linux Kernel 提供的一項技術，允許在 Kernel 空間中安全地執行自定義程式碼，而不需要修改 Kernel 原始碼或載入 Kernel Module。

對可觀測性而言，eBPF 的革命性在於：

  • 零侵入性：不需要修改應用程式的程式碼，不需要加入 SDK，不需要重啟服務
  • 極低開銷：eBPF 程式在 Kernel 中執行，經過 JIT 編譯和安全性驗證，效能損耗極小
  • 全層級觀測：可以觀測網路封包、檔案系統操作、系統調用、甚至應用程式函數調用

eBPF 需要較新的 Linux Kernel 版本（通常建議 5.x 以上）。如果你的環境運行在較舊的 Kernel 上，部分 eBPF 功能可能無法使用。

為什麼是可觀測性的未來#

傳統的 Instrumentation 都需要「侵入」應用程式——不管是加 SDK、加 Sidecar、還是用 Java Agent。這帶來幾個問題：

  • 需要開發團隊的配合和程式碼變更
  • 不同語言需要不同的 SDK
  • 對第三方或遺留系統無能為力

eBPF 繞過了所有這些障礙。它在作業系統層級工作，對任何運行在該 Kernel 上的程式都有效，不分語言、不需源碼。

Grafana Beyla#

Grafana Beyla 是 Grafana Labs 基於 eBPF 打造的自動 Instrumentation 工具。它的承諾很簡單：部署 Beyla，不需要修改任何應用程式，就能自動獲得 HTTP/gRPC 請求的 Metrics 和 Traces。

Beyla 的工作原理：

  • 利用 eBPF 在 Kernel 層級攔截網路相關的系統調用
  • 自動識別 HTTP 和 gRPC 協議
  • 從攔截到的資料中提取出請求路徑、狀態碼、延遲等資訊
  • 產出 RED Metrics 和基本的 Distributed Trace

Beyla 產出的觀測資料相較於完整的 SDK Instrumentation 會比較粗略。它能捕捉「服務之間的 HTTP 調用」，但無法深入到「應用程式內部的函數調用」或「業務邏輯層級的 Span」。它更適合作為「零成本的基礎覆蓋」，而非取代精細的 Instrumentation。

適用場景#

Continuous Profiling（Pyroscope）適合：

  • 生產環境的效能調優：「系統變慢了，但 Metrics 看不出原因」
  • 持續性的效能回歸偵測：比對不同版本的 Profile，找出效能退化的函數
  • 記憶體洩漏除錯：觀察 Heap Profile 隨時間的變化

eBPF / Beyla 適合：

  • 想要零侵入式的觀測覆蓋：不需要開發團隊的配合就能開始收集資料
  • 遺留系統或第三方服務：無法修改源碼的情境
  • 快速建立基線：在全面的 Instrumentation 之前，先用 eBPF 獲得基本的可見度
  • 網路層級的觀測：流量分析、Service Map 生成

eBPF 和傳統 Instrumentation 不是互斥的。一個務實的策略是：用 Beyla 快速覆蓋所有服務的基礎觀測，然後對關鍵服務再加上精細的 SDK Instrumentation。兩層觀測互補，成本效益最佳。