Splunk APM 新增功能擴展了程式碼分析能力
發布日期：2022/09/28
今天很高興和您分享新的 Splunk 功能，這些功能能幫助您評估程式碼效能對服務造成的影響。Splunk APM 的 AlwaysOn Profiling 功能現在支援可分析 CPU 的 .NET 和 Node.js 應用程式，以及分析記憶體的 Java 應用程式。AlwaysOn Profiling 可持續分析服務效能，為應用程式開發人員和服務所有者提供程式碼層級的可見度，讓他們可以在最不影響效能的前提下了解資源瓶頸。無論是重構單體式 (monolithic) 應用程式，還是使用微服務和雲端原生技術，工程師都可以輕鬆識別 .NET、Node.js 和 Java 應用程式中的 CPU 和記憶體瓶頸，並與追蹤資料產生關聯。連同 Splunk Synthetic Monitoring、Splunk RUM、Splunk Infrastructure Monitoring、Splunk Log Observer 和 Splunk On-Call 一起使用後，AlwaysOn Profiling 有助於更快地偵測、排除故障和隔離問題。
順道一提，我們初始正式版本公開部落格文章公告中還提供了一個排除 CPU 故障的完整演練。在記憶體分析方面，這裡有一則概述如何識別問題和解決瓶頸問題的文章。如需記憶體分析的更多資訊，請參閱我們關於記憶體分析的文件，或是觀看這一則詳細的演練影片。
工作流程：配置太多記憶體導致回應時間緩慢
服務所有者收到登入 Splunk APM 速度很慢的警示，而從服務延遲指標可以得知在一次新部署後回應時間出現了峰值。我們知道潛在的瓶頸有以下幾種：
- 程式碼問題 (例如緩慢的演算法或緩慢的 I/O 呼叫)
- 執行階段問題 (例如記憶體回收的額外負荷)
- 設定問題 (例如資料庫連接集區太小)
- 作業系統層級的問題 (例如有問題的應用程式占用 CPU 或執行序耗盡)
由於程式碼問題是導致緩慢的常見原因，我們首先分析程式碼效能。我們查看了一些執行序緩慢的情況，以及在我們的追蹤中的 CPU 分析數據，然後檢查所有服務的瓶頸 (如我們在初始正式版本公開部落格文章中所述)。
如果找不到任何程式碼瓶頸，下一步就是檢查執行階段指標。Splunk APM 的執行階段儀表板顯示了大量的執行階段指標，所有指標均由我們的執行階段檢測代理程式自動收集。
從這些圖表中，我們可以看到 JVM 指標，並注意到記憶體回收中的異常情況。
當我們檢視「GC 活動」圖表時，看到每一分鐘中記憶體回收程序就耗時超過 20 秒。這可能代表 JVM 用了太多時間來進行記憶體回收，而不是服務傳入的請求。
透過查看 CPU 使用率，我們證實了這一項懷疑。JVM 的記憶體收集會產生大量的額外負荷 (20% 到 40% 的 CPU 資源)，只留下 60% 到 80% 的 CPU 資源用於實際工作 (即服務傳入的請求)。
記憶體回收活動過多，最明顯的情況是程式碼分配了太多記憶體，或者建立了太多必須回收記憶體的物件。為了將程式碼瓶頸視覺化，我們使用火焰圖 (如需更多詳細資訊，請參閱使用火焰圖)。下面的火焰圖顯示，當我們的程式碼配置記憶體時，從 JVM 使用的 457k+ 次呼叫堆疊。堆疊框架的寬度 (在圖表上以條形表示) 告訴我們每個堆疊框架被分配了多少記憶體 (按百分比)。
火焰圖的下半部分指向我們自己的程式碼，這意味著我們有機會重新設計程式碼以配置更少的記憶體。
接著我們可以切換到我們的整合式開發環境 (IDE)，並手動操作到堆疊框架指示的正確類別和方法，或者按一下特定框架來在火焰圖下顯示詳細資訊。
如果我們按一下 [Copy Stack Trace]，就會將包含框架的整個堆疊追蹤放入剪貼簿。然後，我們可以切換到我們的 IDE，將其複製到「Analyze Stack Trace」/「Java Stack Trace Console」或類似的視窗對話方塊，IDE 會將我們指向正確檔案中的位置。
當修復並重新部署來源程式碼後，我們再次觀看火焰圖來查看特定堆疊追蹤，發現已經不再占用記憶體，並驗證記憶體回收的額外負荷 (和服務回應時間) 已經減少。
為什麼用 Splunk 進行程式碼分析？
與專用的程式碼分析解決方案不同，Splunk 的 AlwaysOn Profiler 會將收集到的呼叫堆疊連結到在呼叫堆疊收集時執行的範圍。這有助於區分開後台執行序與服務傳入請求的執行序的資料，大大減少工程師分析資料所需的時間。
此外，使用 Splunk AlwaysOn Profiler 時，所有資料都是自動收集的，造成的額外負荷很低。使用者無需在建立事件期間打開分析器，只需部署支援 Splunk 的 OpenTelemetry 代理程式，它就會開始在後台持續收集資料。
若需了解更多資訊，請在我們的 AlwaysOn 分析文件中找到更詳細的說明。
還不是 APM 用戶？請立即註冊試用。
作者
Mat Ball
Mat Ball 負責 Splunk 數位操作監控 (DEM) 產品的市場行銷，目的是為數位化的團隊進行網路效能最佳化的培訓，特別是評估和改善網路和行動使用者操作的藝術和科學。自 2013 年以來，他一直從事和 Web 效能相關的工作，過去曾負責過 New Relic 的 DEM 套件產品行銷。