作者：圖楊
工程師小 A 剛剛接手他們公司最核心的電商系統的運維工作，小 A 發現，在生產環境中，系統明明執行得非常穩定，但是總會出現一些“詭異”的情況。比如：
- 偶爾會一些錯誤呼叫，但是，還沒來得及修，系統又莫名奇妙地恢復正常。
- 應用的平均響應時間很短，但是總會有一些響應時間非常長的離群呼叫，每次花很多時間來分析這些離群點，但是每次分析出來的結果都不一樣，有時候是資料庫問題，有時候是訊息佇列的問題，原因千奇百怪，很難逐一排查。
如果是經驗豐富的工程師，對系統非常非常熟悉，也許能夠依靠經驗來解決這些“詭異”的問題。但是，對於一個大型公司來說，他們的系統已經迭代了十幾年，幾百個人貢獻過程式碼，很難再出現對系統非常熟悉的工程師了。所以，每次系統出現問題，小 A 都需要用多種工具，花費大量時間來排查，還要面對客戶時不時的投訴；每一次 618 和雙十一前夕，大家都戰戰兢兢，求神拜佛，祈禱千萬不要在關鍵時刻發生異常。
那麼，除了專家經驗和對好幾十種可能性逐一排查之外，有沒有更優雅的，快速定位錯/慢 Trace 產生原因的工具？
答案是有的，阿里雲應用實時監控服務 ARMS 最近推出了錯/慢 Trace 分析功能（Trace 是呼叫鏈，指從使用者發起服務請求到結束，按順序記錄整個請求鏈路的相關資料，關於 Trace 的介紹可以看 [ 1] ）。我們會對錯/慢 Trace 和正常 Trace 在每一個維度進行對比分析，從而幫助使用者挖掘錯/慢 Trace 的的共有特徵。
該功能不需要任何專家經驗，即使小 A 對系統不那麼熟悉，他也可以利用這個功能，在大促前夕梳理一下經常出錯，或者響應時間遠高於平均值的介面和機器，有針對性的對系統進行最佳化。在這篇文章中，我們將介紹：
- ARMS 錯/慢 Trace 分析功能基本原理；
- 該功能能夠覆蓋哪些異常 Trace 根因；
- 最後會介紹一些最佳實踐案例。
該功能已正式釋出，產品文件 [ 2] 和最佳實踐案例 [ 3] 均已上線，文章的最後有免登入 demo 的體驗連結，歡迎大家來體驗。
ARMS 錯/慢 Trace 分析功能基本原理
在生產環境下，影響呼叫時延以及引發錯誤的因素有很多，流量不均、單機故障、程式異常、依賴元件瓶頸等。友商和學術界常用的方式是利用 ML、LLM 對大量 Trace 進行訓練，再來對新來的異常 Trace 進行分類，以此來定位根因。但是在實際生產環境中，不同系統的 Trace 特徵完全不同，而且隨著系統的更新，Trace 的特徵以及引發錯/慢 Trace 的根因也會不斷改變。因此，對於商業可觀測產品而言，這種基於歷史資料對新資料進行判斷的方法，基於我們淺薄的認知，現有的演算法可能還不夠成熟。
為了避免應用間的差異對錯/慢 Trace 根因定位準確率的影響，我們的方案是：
“將錯/慢 Trace 和同一系統中，正常 Trace 從各個維度進行對比，識別出錯/慢 Trace 的特徵，引導使用者不斷探索，最終定位異常根因。”
舉個例子，當使用者收到了大量介面報錯的告警，但是不知道引發異常的根因是什麼。在這種情況下，ARMS 錯/慢呼叫分析功能，會對一個系統中 1000 條錯 Trace 樣本和 1000 條正常 Trace 樣本從各個維度進行比較，發現幾乎所有的錯 Trace 都集中在應用 "mall-gateway"、主機 “10.0.0.47” 和介面 "components/api/v1/mall/product" 上，並且經過它們的，基本沒有正常 Trace，那麼和應用名 ="mall-gateway"、主機 Ip=“10.0.0.47” 和介面名 ="components/api/v1/mall/product" 的 Trace 值得進一步排查，因為很有可能就是部署在這臺主機上的這個介面出現了問題。
並且，ARMS 支援使用者自定義要分析和對比的 Trace，只需要在呼叫鏈分析的篩選框修改條件即可，比如可以把 serviceName="mall-gateway" 放到篩選框中，對該應用的錯 Trace 進行進一步分析。
您可以不斷地重複這個過程，直到您定位到系統的異常。
ARMS 錯/慢 Trace 分析功能能夠覆蓋哪些異常 Trace 根因？
我們定位根因的邏輯是，對批次錯/慢 Trace 和批次正常 Trace 在各個維度上進行比較，所以理論上，只要是呼叫鏈上擁有的維度能表徵的資訊，我們都能定位出來，包括但不限於：
- 主機異常
- 介面異常
- 慢 SQL
- 訊息佇列異常等等
最佳實踐
如何透過錯 Trace 分析功能，排查錯呼叫根因？
Step 1：發現 13：21 到 13：28，應用 "mall-gateway" 出現了一些 Http 錯誤的呼叫
Step 2：修改時間視窗到批次 Http 錯誤發生的時間段，開始排查問題
Step 3：進入錯 Trace 分析頁面
發現：錯呼叫集中在 3 個維度：介面名 = "/components/api/v1/mall/product",IP=“10.0.0.47” 以及 IP=“10.0.0.37”，下面依次進行排查。
Step 3.1：排查 spanName="/components/api/v1/mall/product"
發現：介面 "/components/api/v1/mall/product" 的錯呼叫幾種在 3 個 Ip 中，並且，路過這些 IP 的，全部都是錯誤呼叫。
這說明這三個 Ip 對應的主機很可能出現了異常，下面進行進一步排查。
Step 3.1.1：
serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.47"
發現該篩選條件下，每一次呼叫都是錯誤呼叫，這說明主機 "10.0.0.47" 中，應用 "mall-gateway" 的介面 "/components/api/v1/mall/product"。在該時段確實出現了異常。
可以回到呼叫鏈列表頁面進一步確認。
可以點選任意一條 Trace 檢視詳情。
Step 3.1.2：
排查 serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.50"
類似地，發現該篩選條件下，每一次呼叫都是錯誤呼叫。
Step 3.1.3：
排查 serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.37"
......
Step 3.2：排查 Ip ="10.0.0.50" 和 Ip = "10.0.0.37"
其實聰明的讀者應該已經發現了問題，剛剛我們在排查介面 "/components/api/v1/mall/product" 時就已經發現了這兩臺主機有問題。但是我們還是可以繼續排查。
發現：對 Ip ="10.0.0.47" 或 Ip = "10.0.0.37" 的錯呼叫開始下鑽分析，也指向了介面 "/components/api/v1/mall/product"，並且這些錯誤都是 500 錯誤。
這和上一步的排查指向了同樣的根因，這說明部署在主機 "10.0.0.47" 以及 "10.0.0.37" 上，介面 "/components/api/v1/mall/product" 相關的程式出現了錯誤，建議查一下相關程式碼近期的變更。
如何透過慢 Trace 分析功能，梳理慢介面？
Step 1：發現應用 serviceName="mall-user-server" 中，在 13：40 到 13：49 存在許多 5s 以上的慢呼叫
Step 2：先關注 15：40 到 15：49，5s+ 的 Trace，將【耗時對比臨界值】改成 5s
發現耗時大於 5s 的 Trace 集中在介面 "/components/api/v1/local/success"、"/components/api/v1/http/success" 和 Ip="10.0.0.44" 的主機中。
Step 3：依次排查 2 個介面和一個 Ip 地址
Step 3.1：排查 serviceName="mall-user-server" AND spanName="/components/api/v1/local/success"
發現：該篩選條件下，每一次呼叫耗時都大於 5s，它是一個慢介面，已經定位到根因。
回 Trace 詳情頁面進一步確認，發現該篩查條件下，平均耗時就大於 5s。
Step 3.2：排查 serviceName="mall-user-server" AND spanName="/components/api/v1/http/success"
發現：該篩選條件下，每一次呼叫耗時都大於 5s，它是一個慢介面。
Step 3.3：排查 serviceName="mall-user-server" AND ip="10.0.0.44"
發現：該篩選條件下，慢 Trace 的也指向了介面 "/components/api/v1/http/success"，和 Step 3.2 重合了，可以推斷介面 "/components/api/v1/http/success" 部署在主機 "10.0.0.44" 上，它出現了一些異常。
當然使用者還可以進一步往下探索。
Demo 體驗連結
https://www.aliyun.com/product/arms?spm=5176.26798190.J_8765075780.1.7b673fd69umBcT
Step 1：切換成新版控制檯
Step 2：點選呼叫鏈分析按鈕
總結
在這篇文章中，我們試圖幫助小 A 排查系統中，“詭異”的錯/慢呼叫產生原因。我們給出了一種，比專家經驗更優雅的，排查問題的工具—— ARMS 錯/慢 Trace 分析，並給出了最佳實踐教程。
透過使用 ARMS 錯/慢 Trace 分析功能，系統發生故障的時候，小 A 可以不再依靠“直覺”來排查問題；在大促前夕，也可以梳理出慢呼叫介面、容易引發錯誤的主機等，這樣工程師們能夠更優針對性地對系統進行最佳化。
這樣，工程們在排查問題上花的時間少一點，專注在業務程式碼上的時間多一點，把核心業務做大做強。
歡迎加入我們的 AIOps 客戶交流釘釘群（群號：25125004458）：
相關連結：
[1] 基礎篇丨鏈路追蹤（Tracing）其實很簡單
[2] 檢視應用的呼叫鏈資訊_應用實時監控服務(ARMS)-阿里雲幫助中心
https://help.aliyun.com/zh/arms/application-monitoring/user-guide/call-chain-analysis
[3] 透過錯/慢呼叫鏈排查應用產生異常的原因_應用實時監控服務(ARMS)-阿里雲幫助中心
https://help.aliyun.com/zh/arms/application-monitoring/use-cases/troubleshooting-application-anomalies-through-error-slow-trace-analysis