在現代的微服務架構中，我們習慣於使用指標 Metrics（告訴我們 CPU 飆高）、日誌 Logs（告訴我們發生了什麼錯誤）以及追蹤 Traces（告訴我們請求在哪個服務卡住）。然而，當你發現 CPU 占用率過高時，這三者往往無法直接告訴你「到底是程式碼的哪一行在浪費資源」。這就是持續分析 Continuous Profiling 的價值所在。
簡單來說，Profiling 是一種分析技術，能讓我們在程式執行時，精確地找出哪個函數、哪一行程式碼消耗了最多的 CPU 週期或記憶體。而持續分析則是將這個過程自動化，讓系統在背景不斷採集效能數據，而非僅在發生問題時才手動啟動除錯工具。
Grafana 最近發布的 Pyroscope 2.0 針對原有的架構進行了徹底的重構，旨在解決在大規模部署時面臨的儲存成本、查詢效能與維運複雜度問題。
解決儲存成本的關鍵：消除冗餘與去重複化
對於初學者來說，最容易被忽略的是 Profiling 數據的體積。一個 Profile 檔案可能高達數十 MB，如果採取傳統的副本機制，儲存壓力會迅速增加。
在 Pyroscope 1.0 中，系統基於舊有的 Cortex 架構，每筆數據會被寫入三次以確保可用性，這導致了 3 倍的儲存放大效應。Pyroscope 2.0 改變了策略，將物件儲存 Object Storage（如 AWS S3 或 GCS）視為唯一的真實數據源 Single Source of Truth，每筆 Profile 僅寫入一次，直接砍掉不必要的重複寫入成本。
此外，Pyroscope 2.0 導入了數據共置 Co-location 技術。由於同一個服務的多次採集結果中，函數名稱、來源路徑與堆疊追蹤 Symbolic Information 等資訊高度重複，系統現在會將這些資訊去重複化。在 Grafana 的實務測試中，這項優化讓符號儲存空間減少了高達 95%。
從有狀態到無狀態：應對爆發式查詢
Profiling 的查詢模式非常有意思，它不像指標數據有穩定的基準流量，而是在平時幾乎沒人看，一旦發生事故時，大量工程師會同時湧入查詢。
舊版 Pyroscope 的查詢處理發生在有狀態的組件中，這意味著你必須根據峰值流量來預留硬體資源，導致平時有大量資源被閒置。Pyroscope 2.0 將讀取路徑完全無狀態化 Stateless，任何一個查詢器 Querier 都能處理任何請求。
這種設計帶來兩個好處：第一是彈性擴展，系統可以根據需求動態增加查詢器數量；第二是適應 AI 時代，現在許多 LLM 驅動的 AI Agent 會自動查詢 Profiling 數據來協助排錯，這種不可預測的流量激增在無狀態架構下能被更優雅地處理。
維運簡化與新功能的誕生
架構的簡化直接反應在維運效率上。由於移除了複雜的 Store-gateway 組件且 Segment Writer 不再依賴本地磁碟，部署時間從原先的 8 到 12 小時縮短至幾分鐘內。
更重要的是，乾淨的數據模型讓原本難以實現的功能變成了可能。例如，現在可以從 Profile 數據中衍生出指標 Metrics，讓工程師能快速比較整個服務集群的效能趨勢，而不需要逐一查詢每個實例。此外，系統還支援了熱圖 Heatmap 查詢，讓開發者能視覺化觀察效能分佈隨時間的變化。
擁抱標準與生態系
目前的觀測趨勢是走向標準化。OpenTelemetry 已將持續分析納入核心信號，而 Pyroscope 2.0 原生支持 OTLP 協議。這意味著團隊可以使用統一的 OpenTelemetry 管線來傳輸數據，不再被單一工具鎖定。
在實務應用上，如 Monzo 等金融科技公司已將 Pyroscope 整合進部署流程，一旦新版本部署後效能下滑，系統會立即觸發警報。而 Uber 則將其用於 PGO Profile-guided Optimisation（利用分析數據來優化編譯器的產出），進一步壓榨程式碼的執行效能。
總結與建議
對於想要導入持續分析的團隊，Pyroscope 2.0 提供了一個低成本且可擴展的方案。如果你是自行部署 Self-hosted，請注意升級至 2.0 版本後，必須配置物件儲存（Object Storage），因為它是新架構中數據存取的核心。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。