作者：程璞、易波。
從 Google 發布的第一篇文章《Dapper， A Large-Scale Distributed Systems Tracing Infrastructure》開始，在指標、追蹤、日誌三個方向上相輔相成的可觀測性解決方案，逐漸被業界接受，成為事實上的標準。
基於上述全棧可觀測性解決方案技術，診斷問題從不知道從哪裡開始，或者只依靠日誌，變成了以下步驟：
1.通過Metrics Logs提供的各種預置告警，發現異常資訊，利用異常資訊判斷異常模組。
2.查詢分析異常模組及關聯日誌，查詢核心錯誤資訊。
3.通過詳細跟蹤找到導致問題的 ** 片段。
基於上述一套可觀察的解決方案，不僅可以在問題發生後及時快速定位和緩解，而且在許多情況下，甚至可以在重大故障發生之前提前發現、解決和修復問題。
基於上述一組可觀察的解決方案，是否有可能一勞永逸地解決任何線上監控問題？其實不是，尤其是在追蹤方面，因為它一般都是基於J**A代理SDK技術方案，對HTTP服務、RPC服務、資料庫、分布式訊息MQ等主流軟體開發框架進行掩埋呼叫鏈監控資料的採集，然後通過後續的呼叫鏈資料恢復處理邏輯，將監控資訊與具體請求關聯， 這樣，當請求異常時，可以通過採集到的監控資料檢視相關的呼叫資訊。除了提供請求通過的核心鏈路方式外，呼叫鏈的另乙個核心功能是幫助排查呼叫鏈中耗時慢的位置，並幫助優化。 故障排除過程可用於使用跟蹤的詳細資訊來診斷跟蹤中耗時的瓶頸邏輯，如下圖所示
如上圖所示，乙個呼叫鏈就是乙個 trace，並且有乙個唯一的 traceId，它包含多個 span，它們表示多個被呼叫的下游服務，每個服務都有對應的 spanid 資訊。 從上圖中可以知道請求經過的多個服務所經歷的耗時情況（假設下游服務對應乙個跨度，部分鏈路追蹤系統可能不同），從而定位應用耗時瓶頸，優化相應的效能。
然而，在分布式微服務領域，由於呼叫鏈路的複雜性，涉及跨機甚至跨機房，因為一般的鏈路追蹤系統只能將核心方法埋在主流的開源軟體框架中，當耗時的位置出現在使用者業務邏輯中缺少追蹤埋點時， 最終的呼叫鏈中會有很長的時間，無法對應具體的執行方式，導致無法準確判斷業務邏輯的耗時情況。
具體案例如下**
public string demo() throws sqlexception private void take1000ms(long time) catch (interruptedexception e) }追蹤呼叫鏈中對應的最終顯示形式可能如下圖所示，通過追蹤呼叫鏈，只能知道第一層的外部介面時間以及其中包含的知名軟體框架的執行邏輯，其中灰色陰影部分是未被追蹤系統埋點覆蓋的使用者業務邏輯**部分， 作為監控盲區，其實際耗時未知，給線上效能排查造成諸多障礙
以上問題在企業使用者中非常普遍，很多時候只能感嘆無奈！
針對上述追蹤系統漏跟蹤點情況下慢呼叫鏈的診斷問題，據筆者了解，目前業界相關解決方案較少，熟悉Arthas的同學可能會提到其中的追蹤命令確實，在一定程度上，它可以在一些可以穩定復現的簡單場景中，手動檢查相關慢呼叫鏈的具體耗時位置。 但它的侷限性也比較明顯：
作用範圍有限穩定場景恢復僅支援慢呼叫診斷，在觸發垃圾**、資源爭用、網路問題等難以恢復的場景下，很難排查慢呼叫問題。 使用門檻高在實際生產場景中，呼叫鏈可能非常複雜，如果不熟悉業務方法的執行或者一些複雜的非同步呼叫場景，就需要在特定的業務方法上手動執行trace命令來監控請求時間消耗。 故障排除成本很高該工具確實可以用於排查單跳簡單業務場景下呼叫慢的問題，但在跨應用多跳複雜業務場景中，排查過程變得繁瑣。 不僅需要使用一些APM工具來定位特定慢呼叫所在的應用例項，而且在業務呼叫方法棧很深的場景下，需要逐層執行相關命令，並逐步監控，找到問題的根源。 綜上所述，arthas的trace命令可以在一些簡單的慢呼叫場景中使用，但在複雜場景下還不足以排除慢呼叫鏈的故障
為此，阿里雲ARMS團隊和阿里巴巴龍井團隊可以通過連續分析技術，幫助使用者更好地恢復呼叫鏈方法棧資訊，從而更好地解決這類鏈路追蹤監控盲點問題。
ARMS持續效能分析能力
作為國內知名的APM工具，ARMS不僅為鏈路追蹤、指標和日誌相關業務提供主流的可觀測性解決方案，還提供開箱即用的持續分析（CP）解決方案。 持續分析是動態實時收集有關資源請求（如 CPU 記憶體）的堆疊資訊，以幫助監控和定位應用程式效能瓶頸。 ARMS目前提供的持續效能分析能力架構如下圖所示：
在裝置端，J**a Agent 技術以非侵入式方式提供連續分析資料收集功能以及其他可觀測性功能。 然後，在伺服器端對採集到的資料進行分析和處理，最後控制台為使用者提供開箱即用的功能，包括：CPU診斷、記憶體診斷和熱點功能。
CPU 和記憶體診斷
火焰圖對於很多困擾過應用效能問題的讀者來說當然並不陌生，可以通過觀察火焰圖中是否有寬頂來定位應用的效能問題。 對於很多研發人員來說，上面提到的火焰圖一般是指CPU熱點火焰圖。 它表示方法在一段時間內在應用中執行 CPU 所需的時間。 ARMS 提供的 CPU 和記憶體診斷功能繼續在開源中剖析非同步分析器在低開銷的條件下受支援規範化收集CPU & 記憶體應用棧資訊可用於簡單高效地監控生產場景中的 CPU & 記憶體應用，杜絕了使用開源工具難以定期開啟、容易遺漏和重現問題場景的情況。
熱點
說完CPU&記憶體診斷，可能會有讀者問，CPU診斷對應的方法棧火焰圖能不能幫助解決跟蹤系統監控中的盲區問題，幫助排查慢呼叫鏈？答案是否定的！這是因為 CPU 診斷是乙個方法堆疊，它定期抓取在 CPU 上執行的執行執行緒，然後將其轉換為火焰圖。
除了在 CPU 上執行的執行狀態（也稱為 on-cpu）外，還有其他狀態，例如阻塞和等待（統稱為 off-cpu），並且由於多個執行緒狀態的疊加，慢呼叫鏈通常呈現時間較長。 因此，CPU 火焰圖在慢速呼叫鏈場景中的用途有限。
有沒有一種火焰圖技術不僅可以用於描述CPU上的內容，還可以用於描述CPU外的內容？然後我們不得不提到掛鐘。 實現原理並不複雜，即在應用的所有執行緒中以固定頻率選擇一組執行緒，採集當前時刻的方法棧資訊，通過聚合處理繪製出對應的火焰圖。 非同步探查器等功能也提供了相關功能。
本文的主題基於開源非同步探查器掛鐘功能通過關聯呼叫鏈中的 traceId 和 spanid 資訊，提供呼叫鏈級別的 On & Off-CPU 火焰圖可以有效還原鏈路追蹤盲區的細節，幫助使用者診斷各種常見的慢呼叫鏈問題。 具體過程如下圖所示，通過**程式建立span開始時間和結束時間來關聯或取消traceid&spanid資訊，使最終生成的掛鐘方法棧快照樣本包含相關資訊，然後通過最終的連續分析資料處理，還原掛鐘火焰圖中對應的呼叫鏈，幫助定位呼叫鏈慢的問題
核心功能：
與其他慢呼叫鏈診斷工具或開源持續分析工具相比，ARMS提供的持續分析能力具有以下特點：
低開銷通過基於Trace過程的自動取樣和掛鐘效能分析的關聯取樣率等措施，ARMS提供的連續效能分析產品能力的CPU開銷為5%，堆外記憶體開銷約為50M。 粒徑細除了應用級的CPU和記憶體熱點外，它還通過關聯traceid和spanid資訊，為呼叫鏈級別提供方法棧資訊，可以有效地幫助診斷慢呼叫鏈問題。 安全可靠，簡單高效一些開源的持續分析技術，例如使用Arthas生成CPU火焰圖（底層也依賴於Async Profiler），即使存在技術風險也不容易找到。 在產品研發過程中，我們還是發現了很多開源技術，比如非同步分析器，不斷分析流程使用的風險。 例如，記憶體分析可能會導致應用程式崩潰，掛鐘火焰圖會導致執行緒長時間堵塞等。 通過解決這些問題，我們的產品功能更加安全可靠。 除了安全性之外，ARMS提供的持續分析能力在資料定時開啟後會自動儲存7天，讓使用者不會錯過每乙個慢呼叫鏈的診斷站點。 開啟熱點
1.登入ARMS控制台，在左側導航欄選擇應用監控>應用列表。
2.在應用清單在頁面頂部，選擇地域，單擊應用名稱。
3.在左側導航欄，單擊應用設定，然後單擊自定義配置標籤。
4.開CPU 和記憶體熱點主開關後，開機熱點切換並配置待開啟應用例項的IP位址或例項組的網段。
5.點選頁面底部救
您可以呼叫API檢視熱點資料
1.登入ARMS控制台，在左側導航欄選擇應用監控>應用列表。
2.在應用清單在頁面頂部，選擇地域，單擊應用名稱。
3.在左側導航欄，單擊API 呼叫，選擇頁面右側的目標介面，然後單擊跟蹤查詢標籤。
4.在跟蹤查詢選項卡上，單擊 traceid 鏈結。
5.在詳點選欄中的放大鏡圖示，首先可以點選方法棧選項卡，看一下追蹤工具展示的方法棧資訊，可以看到它只包含了 MariaDB 相關的執行邏輯，沒有記錄前面的業務時間。
6.接下來，單擊熱點選項卡，在右側的火焰圖中可以看到，除了 MariaDB 相關的方法棧（對應下圖右側火焰圖中右側最尖銳的火焰）之外，還包括 j**a.lang.thread.sleep（） 相關的 990ms（由於連續分析以獲得基於取樣的執行緒堆疊，可能會有輕微的偏差）。
圖左邊是呼叫中涉及的所有方法所花費的時間列表，右邊是對應方法的所有方法棧的火焰圖。 self 列顯示方法本身所需的時間。 作為具體的熱點邏輯，可以通過聚焦自列或者直接看右邊火焰圖底部較寬的火焰來定位耗時的業務方式，這是上層耗時高的根本原因，一般是系統效能的瓶頸，如上圖中的j**a.lang.thread.sleep（） 方法。 有關更多詳細資訊，請參閱此功能的使用者文件
相關鏈結：
1] trace 命令。
2] async profiler
#694/issues/694
#769/issues/769
5] 使用者文件。