運用另一種遙測資料，透過 AI Agent 加速改善

Profiling 簡介

• Profiler 定義：Profiler 是一種遙測工具，可提供系統效能表現及系統資源用量的相關資訊。
• Profiling 的用途：Profiling 有助於調查程式的資源消耗情況，並提供特定期間內各項資源用量的統計資訊。
• 與 Tracing 的差異：Tracing 會以時間序列追蹤資源消耗情況，Profiling 則提供特定期間內的統計資訊。
• 常見的 Profiling 工具：
• Java：Java Flight Recorder（JFR）
• Python：cProfile（標準函式庫）與 line_profiler（第三方工具）
• Linux：可用於任意執行檔的 perf 命令

Profiling 在效能調查中的重要性

• 練習情境：假設 Web 應用程式發生延遲問題，Client 傳送至 Web Server 的請求回應緩慢。
• 目標：找出效能問題的原因並加以修正。
• 可觀測性：可觀測性通常會讓人聯想到 Log、指標與 Trace，但 Profiling 能提供額外洞察，而這些資訊可能是解決效能問題的必要條件。

Log、指標與分散式 Trace 的限制

• [ 1 ] 指標：
• 定義：指標是最常見的遙測資料類型，可提供 CPU 與記憶體用量等資訊。
• 限制：指標追蹤的是整個執行個體或服務的資源消耗情況（例如執行 Web Server 的容器），無法指出應用程式內是哪個特定函式或實作正在消耗資源。例如，指標可以顯示 Web Server 使用大量 CPU，卻無法識別是哪個函式造成 CPU 使用率偏高。
• [ 2 ] 分散式 Trace：
• 定義：分散式 Trace 可提供系統內部延遲問題的重要資訊。
• 限制：常見的分散式 Tracing 解決方案需要對系統或程式加入檢測機制。若函式未加入檢測，就無法取得該函式的延遲資訊。為每個函式加入檢測不僅耗時，也可能引發效能問題。
• [ 3 ] Log：
• 定義：Log 可提供特定函式在特定時間執行特定動作的資訊。
• 限制：Log 只會顯示程序成功完成或錯誤訊息。如果函式正確處理請求，Log 只會顯示成功訊息，不會指出任何延遲問題。除非發生錯誤，否則 Log 無法提供造成延遲問題的原因。

結論

• 問題：Log、指標與分散式 Trace 雖然實用，卻無法完整說明延遲問題的成因。若要深入掌握資源消耗情況並找出效能瓶頸，就需要使用 Profiling。

現況與理想狀態摘要

• [ 1 ] 目標：
• 使用可觀測性的目標，是找出效能問題的原因並加以修正。
• [ 2 ] 現況：
• 遙測資訊缺口：即使已觀察到延遲、CPU 或記憶體用量驟升、分散式 Trace 中的延遲變化，而且 Log 顯示函式已正常處理請求，仍無法找出延遲問題的確切原因。
• [ 3 ] 理想狀態：
• 精確定位：理想狀態是能找出造成效能問題的確切程式碼行，以便精準修正。

可觀測性的定義

• 控制理論中的可觀測性：可觀測性是衡量能否從系統的外部輸出（遙測資料）推斷其內部狀態的指標。
• 理想的可觀測性：可觀測性的理想狀態，是僅透過遙測資料就能找出問題的確切原因。

Profiling 的角色

• 填補缺口：Profiling 是補足 Log、指標與 Trace 無法填補之資訊缺口的必要手段。
• 最後一哩資訊：Profiling 提供最後一塊關鍵資訊，讓我們能從 Log、指標與 Trace 所提供的資料，進一步找出效能問題的確切原因。

Profiling 的傳統用法

• 檢測：若要使用 Profiling，必須在程式中加入檢測機制以收集遙測資料。
• 分析：分析收集到的遙測資料，以找出並修正效能問題。

在程式中加入 Profiling 檢測

Go

• 標準套件：使用 Go 內建的 pprof 套件。
• 步驟：
• 匯入 pprof 套件。
• 建立 Profiler 執行個體。
• 啟動 Profiler。
• 定義停止 Profiler 測量的位置。

Python

• Line Profiler：使用 line_profiler 套件。
• 步驟：
• 匯入 line_profiler 套件。
• 啟用 Profiler。
• 編寫要進行 Profiling 的特定處理程序。
• 停用 Profiler。

永續運作系統的持續 Profiling

• [ 1 ] 差異：
• 單次 Profiler：測量單次執行的時間（啟動及停止計時器）。
• 持續 Profiler：按照設定的時間間隔定期取得 Profile 資料（例如連續 5 分鐘，每 10 秒一次），並儲存至外部位置（例如 Amazon S3）。
• [ 2 ] 使用案例：
• 適合 Daemon 或 Web Server 等持續運作的系統，尤其適用於流量驟增期間。
• [ 3 ] 解決方案：
• AWS：使用 CodeGuru，或搭配 Pyroscope 管理 Grafana。
• 開放原始碼：Pyroscope，目前已納入 Grafana 解決方案。

Profile 資料分析

• 螢幕截圖範例：安裝 Pyroscope Plugin 的 Amazon Managed Grafana，顯示每個 Stack 的資源用量統計。
• 下一步：資料收集完成後，進入分析階段，以找出並修正效能問題。

使用 Flame Graph 將 Profile 資料視覺化

• Flame Graph：將 Profile 資料視覺化的知名方式。
• 挑戰：若要瞭解如何閱讀 Flame Graph，必須熟悉原始碼、視覺化圖表的含義，以及電腦科學的基本概念。

閱讀 Flame Graph

• [ 1 ] 圖表範例：
• 將整個程式 Stack 的 CPU 用量視覺化。
• [ 2 ] 解讀：
• 長條：表示資源消耗量較高。
• sys.call.read：用於讀取資料的 System Call，會消耗大量 CPU。
• os.file.read：用於讀取實體檔案的 Go 標準函式庫函式，理應已有完善實作並具備良好效能。
• [ 3 ] 結論：問題可能在於自訂函式（模擬 GNU Cut 命令的 Cut 函式）以低效率的方式呼叫 os.file.read。

函式實作範例

• cut 函式：模擬 GNU Cut 命令行為的函式。
• 下一步：檢視 Cut 函式的實作，找出呼叫 os.file.read 時可能存在的低效率問題。

示範

檔案讀取效率不佳

• 找到的問題：程式每次只讀取檔案的一個 Byte，效率相當低，因為每讀取一個 Byte 就會觸發一次 System Call。
• 所需知識：若要理解這種方式效率不佳的原因，需要具備 User Space、Kernel Space 及電腦科學原理等知識。

AI 助理在 Profiling 中的角色

• AI 輔助：AI 助理，尤其是大型語言模型（LLM），可協助解讀 Profile 資料。
• 適用於維運：相較於開發，LLM 更適合應用於維運，因為維運的輸出較少且較具確定性（例如找出問題），同時擁有豐富的脈絡資訊（系統規格、遙測資料、Log）。
• 開發與維運的比較：開發需要產生大量原始碼，且輸出較不確定，因此較不適合 LLM。

使用 AI 助理分析 Profile 資料

• 示範：AWS 員工使用 AI 助理分析 Profile 資料與原始碼，以找出效能問題。
• 流程：
• [ 1 ] 要求 AI 助理分析 Profile 資料與原始碼。
• [ 2 ] 助理判斷需要使用工具將 Profile 資料視覺化。
• [ 3 ] 取得核准後，助理依函式將 CPU 用量視覺化，並找出造成問題的確切函式。
• [ 4 ] 助理提供逐行的 CPU 用量資訊，並提出改善建議。

摘要

• Profile 資料：將效能問題連結至實際程式碼改善的關鍵。
• 傳統分析：需要深入的系統與電腦科學知識。
• AI 輔助：運用 Profile 資料協助使用者瞭解其使用方式，並加速開發。