作者：涯海
鍊路追蹤的 “第三種玩法”
提起鍊路追蹤，大家會很自然的想到使用調用鍊排查單次請求的異常，或使用預聚合的鍊路統計名額進行服務監控與告警。其實，鍊路追蹤還有第三種玩法：相比調用鍊，它能夠更快的定界問題；相比預聚合的監控圖表，它可以更靈活的實作自定義診斷。那就是基于明細鍊路資料的後聚合分析，簡稱鍊路分析。
鍊路分析是基于已存儲的全量鍊路明細資料，自由組合篩選條件與聚合次元進行實時分析，可以滿足不同場景的自定義診斷需求。比如，檢視耗時大于 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 進行分組統計，可以清晰的區分釋出前後或不同版本的流量變化和服務品質。不會出現灰階批次異常被全局監控掩蓋的情況。
鍊路分析的限制條件
鍊路分析雖然使用起來非常靈活，可以滿足不同場景的自定義診斷需求。但是它也有幾點使用限制限制：
- 基于鍊路明細資料進行分析的成本較高。鍊路分析的前提是盡可能完整的上報并存儲鍊路明細資料，如果采樣率比較低導緻明細資料不全，鍊路分析的效果就會大打折扣。為了降低全量存儲成本，可以在使用者叢集内部署邊緣資料節點，進行臨時資料緩存與處理，降低跨網絡上報開銷。或者，在服務端進行冷熱資料分離存儲，熱存儲進行全量鍊路分析，冷存儲進行錯慢鍊路診斷。
- 後聚合分析的查詢性能開銷大，并發小，不适合用于告警。鍊路分析是實時的進行全量資料掃描與統計，查詢性能開銷要遠大于預聚合統計名額，是以不适合進行高并發的告警查詢。需要結合自定義名額功能将後聚合分析語句下推至用戶端進行自定義名額統計，以便支援告警與大盤定制。
- 結合自定義标簽埋點，才能最大化釋放鍊路分析價值。鍊路分析不同于标準的應用監控預聚合名額，很多自定義場景的标簽需要使用者手動埋點打标，這樣才能最有效的區分不同業務場景，實作精準分析。
鍊路分析為 APM 插上“自由的翅膀”
鍊路資料蘊含着豐富的價值，傳統的調用鍊和服務視圖隻是固定模式下的兩種經典用法，基于後聚合的鍊路分析可以充分釋放診斷的靈活性，滿足任意場景、次元的自定義診斷需求。結合自定義名額生成規則，更是可以極大的提升監控告警的精細度，為你的 APM 插上“自由的翅膀”，推薦大家一起來體驗、探索和分享！
點選
此處，了解更多鍊路追蹤資訊！