作者：涯海

鏈路追蹤的 “第三種玩法”* *

提起鏈路追蹤，大家會很自然的想到使用呼叫鏈排查單次請求的異常，或使用預聚合的鏈路統計指標進行服務監控與告警。其實，鏈路追蹤還有第三種玩法：相比呼叫鏈，它能夠更快的定界問題；相比預聚合的監控圖表，它可以更靈活的實現自定義診斷。那就是基於明細鏈路資料的後聚合分析，簡稱鏈路分析。

鏈路分析是基於已儲存的全量鏈路明細資料，自由組合篩選條件與聚合維度進行實時分析，可以滿足不同場景的自定義診斷需求。 比如，檢視耗時大於 3 秒的慢呼叫時序分佈，檢視錯誤請求在不同機器上的分佈，檢視 VIP 客戶的流量變化等。接下來本文將介紹如何通過鏈路分析快速定位五種經典線上問題，更直觀的瞭解鏈路分析的用法與價值。

鏈路分析 K.O“五大經典問題”

基於後聚合的鏈路分析用法非常靈活，本文僅列舉五種最典型的案例場景，其他場景歡迎大家一起探索分享。

【流量不均】負載均衡配置錯誤，導致大量請求打到少量機器，造成“熱點”影響服務可用性，怎麼辦？

流量不均導致的“熱點選穿”問題，很容易造成服務不可用，在生產環境中出現過多起這樣的案例。比如負載均衡配置錯誤，註冊中心異常導致重啟節點的服務無法上線，DHT 雜湊因子異常等等。

流量不均最大風險在於能否及時發現“熱點”現象，它的問題表象更多是服務響應變慢或報錯，傳統監控無法直觀反映熱點現象，所以大部分同學都不會第一時間考慮這個因素，從而浪費了寶貴的應急處理時間，造成故障影響面不斷擴散。

通過鏈路分析按 IP 分組統計鏈路資料，快速瞭解呼叫請求分佈在哪些機器上，特別是問題發生前後的流量分佈變化，如果大量請求突然集中在一臺或少量機器，很可能是流量不均導致的熱點問題。再結合問題發生點的變更事件，快速定位造成故障的錯誤變更，及時回滾。

【單機故障】網絡卡損壞/CPU 超賣/磁碟打滿等單機故障，導致部分請求失敗或超時，如何排查？

單機故障每時每刻都在頻繁發生，特別是核心叢集由於節點數量比較多，從統計概率來看幾乎是一種“必然”事件。單機故障不會造成服務大面積不可用，但會造成少量使用者請求失敗或超時，持續影響使用者體驗，並造成一定答疑成本，因此需要及時處理這類問題。

單機故障可以分為宿主機故障和容器故障兩類（在 K8s 環境可以分為 Node 和 Pod）。比如 CPU 超賣、硬體故障等都是宿主機級別，會影響所有容器；而磁碟打滿，記憶體溢位等故障僅影響單個容器。因此，在排查單機故障時，可以根據宿主機 IP 和容器 IP 兩個維度分別進行分析。

面對這類問題，可以通過鏈路分析先篩選出異常或超時請求，根據宿主機 IP 或容器 IP 進行聚合分析，快速判斷是否存在單機故障。如果異常請求集中在單臺機器，可以嘗試替換機器進行快速恢復，或者排查該機器的各項系統引數：比如磁碟空間是否已滿、CPU steal time 是否過高等。如果異常請求分散在多臺機器，那大概率可以排除單機故障因素，可以重點分析下游依賴服務或程式邏輯是否異常。

【慢介面治理】新應用上線或大促前效能優化，如何快速梳理慢介面列表，解決效能瓶頸？

新應用上線或大促備戰時通常需要做一次系統性的效能調優。第一步就是分析當前系統存在哪些效能瓶頸，梳理出慢介面的列表和出現頻率。

此時，可以通過鏈路分析篩選出耗時大於一定閾值的呼叫，再根據介面名稱進行分組統計，這樣就可以快速定位慢介面的列表與規律，然後對出現頻率最高的慢介面逐一進行治理。

找到慢介面後，可以結合相關的呼叫鏈、方法棧和執行緒池等資料定位慢呼叫根因，常見原因包括以下幾類：

• 資料庫/微服務連線池過小， 大量請求處於獲取連線狀態，可以調大連線池最大執行緒數解決。
• N+1 問題， 比如一次外部請求內部呼叫了上百次的資料庫呼叫，可以將碎片化的請求進行合併，降低網路傳輸耗時。
• 單次請求資料過大， 導致網路傳輸和反序列化時間過長且容易導致 FGC。可以將全量查詢改為分頁查詢，避免一次請求過多資料。
• 日誌框架“熱鎖”， 可以將日誌同步輸出改為非同步輸出。

【業務流量統計】如何分析重保客戶/渠道的流量變化和服務質量？

在實際生產環境中，服務通常是標準化的，但業務卻需要分類分級。同樣的訂單服務，我們需要按照類目、渠道、使用者等維度進行分類統計，實現精細化運營。比如，對於線下零售渠道而言，每一筆訂單、每一個 POS 機的穩定性都可能會觸發輿情，線下渠道的 SLA 要求要遠高於線上渠道。那麼，我們如何在通用的電商服務體系中，精準的監控線下零售鏈路的流量狀態和服務質量呢？

在這裡，可以使用鏈路分析的自定義 Attributes 過濾和統計實現低成本的業務鏈路分析。比如，我們在入口服務針對線下訂單打上一個 {"attributes.channel": "offline"} 的標籤，然後再針對不同門店、使用者客群和商品類目分別打標。最後，通過對 attributes.channel = offline 進行過濾，再對不同的業務標籤進行 group by 分組統計呼叫次數、耗時或錯誤率等指標，就可以快速的分析出每一類業務場景的流量趨勢與服務質量。

【灰度釋出監控】500臺機器分10批發布，如何在第一批灰度釋出後，就能快速判斷是否有異常？

變更三板斧“可灰度、可監控、可回滾”，是保障線上穩定性的重要準則。其中，分批次灰度變更是降低線上風險，控制爆炸半徑的關鍵手段。一旦發現灰度批次的服務狀態異常，應及時進行回滾，而不是繼續釋出。然而，生產環境很多故障的發生都是由於缺乏有效的灰度監控導致的。

例如，當微服務註冊中心異常時，重啟發布的機器無法進行服務註冊上線。由於缺乏灰度監控，前幾批重啟機器雖然全部註冊失敗，導致所有流量都集中路由到最後一批機器，但是應用監控的總體流量和耗時沒有顯著變化，直至最後一批機器也重啟註冊失敗後，整個應用進入完全不可用狀態，最終釀成了嚴重的線上故障。

在上述案例中，如果對不同機器流量進行版本打標 {"attributes.version": "v1.0.x"} ，通過鏈路分析對attributes.version 進行分組統計，可以清晰的區分發布前後或不同版本的流量變化和服務質量。不會出現灰度批次異常被全域性監控掩蓋的情況。

鏈路分析的約束條件

鏈路分析雖然使用起來非常靈活，可以滿足不同場景的自定義診斷需求。但是它也有幾點使用約束限制：

1. 基於鏈路明細資料進行分析的成本較高。 鏈路分析的前提是儘可能完整的上報並存儲鏈路明細資料，如果取樣率比較低導致明細資料不全，鏈路分析的效果就會大打折扣。為了降低全量儲存成本，可以在使用者叢集內部署邊緣資料節點，進行臨時資料快取與處理，降低跨網路上報開銷。或者，在服務端進行冷熱資料分離儲存，熱儲存進行全量鏈路分析，冷儲存進行錯慢鏈路診斷。

2. 後聚合分析的查詢效能開銷大，併發小，不適合用於告警。 鏈路分析是實時的進行全量資料掃描與統計，查詢效能開銷要遠大於預聚合統計指標，所以不適合進行高併發的告警查詢。需要結合自定義指標功能將後聚合分析語句下推至客戶端進行自定義指標統計，以便支援告警與大盤定製。

3. 結合自定義標籤埋點，才能最大化釋放鏈路分析價值。 鏈路分析不同於標準的應用監控預聚合指標，很多自定義場景的標籤需要使用者手動埋點打標，這樣才能最有效的區分不同業務場景，實現精準分析。

鏈路分析為 APM 插上“自由的翅膀”

鏈路資料蘊含著豐富的價值，傳統的呼叫鏈和服務檢視只是固定模式下的兩種經典用法，基於後聚合的鏈路分析可以充分釋放診斷的靈活性，滿足任意場景、維度的自定義診斷需求。結合自定義指標生成規則，更是可以極大的提升監控告警的精細度，為你的 APM 插上“自由的翅膀”，推薦大家一起來體驗、探索和分享！

點選​​此處​​，瞭解更多鏈路追蹤資訊！