作者：涯海

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

提起鏈路追蹤，大家會(huì)很自然的想到使用調(diào)用鏈排查單次請(qǐng)求的異常，或使用預(yù)聚合的鏈路統(tǒng)計(jì)指標(biāo)進(jìn)行服務(wù)監(jiān)控與告警。其實(shí)，鏈路追蹤還有第三種玩法：相比調(diào)用鏈，它能夠更快的定界問(wèn)題；相比預(yù)聚合的監(jiān)控圖表，它可以更靈活的實(shí)現(xiàn)自定義診斷。那就是基于明細(xì)鏈路數(shù)據(jù)的后聚合分析，簡(jiǎn)稱(chēng)鏈路分析。

鏈路分析是基于已存儲(chǔ)的全量鏈路明細(xì)數(shù)據(jù)，自由組合篩選條件與聚合維度進(jìn)行實(shí)時(shí)分析，可以滿足不同場(chǎng)景的自定義診斷需求。 比如，查看耗時(shí)大于 3 秒的慢調(diào)用時(shí)序分布，查看錯(cuò)誤請(qǐng)求在不同機(jī)器上的分布，查看 VIP 客戶的流量變化等。接下來(lái)本文將介紹如何通過(guò)鏈路分析快速定位五種經(jīng)典線上問(wèn)題，更直觀的了解鏈路分析的用法與價(jià)值。

鏈路分析 K.O?“五大經(jīng)典問(wèn)題”

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

【流量不均】負(fù)載均衡配置錯(cuò)誤，導(dǎo)致大量請(qǐng)求打到少量機(jī)器，造成“熱點(diǎn)”影響服務(wù)可用性，怎么辦？

流量不均導(dǎo)致的“熱點(diǎn)擊穿”問(wèn)題，很容易造成服務(wù)不可用，在生產(chǎn)環(huán)境中出現(xiàn)過(guò)多起這樣的案例。比如負(fù)載均衡配置錯(cuò)誤，注冊(cè)中心異常導(dǎo)致重啟節(jié)點(diǎn)的服務(wù)無(wú)法上線，DHT 哈希因子異常等等。

流量不均最大風(fēng)險(xiǎn)在于能否及時(shí)發(fā)現(xiàn)“熱點(diǎn)”現(xiàn)象，它的問(wèn)題表象更多是服務(wù)響應(yīng)變慢或報(bào)錯(cuò)，傳統(tǒng)監(jiān)控?zé)o法直觀反映熱點(diǎn)現(xiàn)象，所以大部分同學(xué)都不會(huì)第一時(shí)間考慮這個(gè)因素，從而浪費(fèi)了寶貴的應(yīng)急處理時(shí)間，造成故障影響面不斷擴(kuò)散。

通過(guò)鏈路分析按 IP 分組統(tǒng)計(jì)鏈路數(shù)據(jù)，快速了解調(diào)用請(qǐng)求分布在哪些機(jī)器上，特別是問(wèn)題發(fā)生前后的流量分布變化，如果大量請(qǐng)求突然集中在一臺(tái)或少量機(jī)器，很可能是流量不均導(dǎo)致的熱點(diǎn)問(wèn)題。再結(jié)合問(wèn)題發(fā)生點(diǎn)的變更事件，快速定位造成故障的錯(cuò)誤變更，及時(shí)回滾。

【單機(jī)故障】網(wǎng)卡損壞/CPU 超賣(mài)/磁盤(pán)打滿等單機(jī)故障，導(dǎo)致部分請(qǐng)求失敗或超時(shí)，如何排查？

單機(jī)故障每時(shí)每刻都在頻繁發(fā)生，特別是核心集群由于節(jié)點(diǎn)數(shù)量比較多，從統(tǒng)計(jì)概率來(lái)看幾乎是一種“必然”事件。單機(jī)故障不會(huì)造成服務(wù)大面積不可用，但會(huì)造成少量用戶請(qǐng)求失敗或超時(shí)，持續(xù)影響用戶體驗(yàn)，并造成一定答疑成本，因此需要及時(shí)處理這類(lèi)問(wèn)題。

單機(jī)故障可以分為宿主機(jī)故障和容器故障兩類(lèi)（在 K8s 環(huán)境可以分為 Node 和 Pod）。比如 CPU 超賣(mài)、硬件故障等都是宿主機(jī)級(jí)別，會(huì)影響所有容器；而磁盤(pán)打滿，內(nèi)存溢出等故障僅影響單個(gè)容器。因此，在排查單機(jī)故障時(shí)，可以根據(jù)宿主機(jī) IP 和容器 IP 兩個(gè)維度分別進(jìn)行分析。

面對(duì)這類(lèi)問(wèn)題，可以通過(guò)鏈路分析先篩選出異常或超時(shí)請(qǐng)求，根據(jù)宿主機(jī) IP 或容器 IP 進(jìn)行聚合分析，快速判斷是否存在單機(jī)故障。如果異常請(qǐng)求集中在單臺(tái)機(jī)器，可以嘗試替換機(jī)器進(jìn)行快速恢復(fù)，或者排查該機(jī)器的各項(xiàng)系統(tǒng)參數(shù)：比如磁盤(pán)空間是否已滿、CPU steal time 是否過(guò)高等。如果異常請(qǐng)求分散在多臺(tái)機(jī)器，那大概率可以排除單機(jī)故障因素，可以重點(diǎn)分析下游依賴服務(wù)或程序邏輯是否異常。

【慢接口治理】新應(yīng)用上線或大促前性能優(yōu)化，如何快速梳理慢接口列表，解決性能瓶頸？

新應(yīng)用上線或大促備戰(zhàn)時(shí)通常需要做一次系統(tǒng)性的性能調(diào)優(yōu)。第一步就是分析當(dāng)前系統(tǒng)存在哪些性能瓶頸，梳理出慢接口的列表和出現(xiàn)頻率。

此時(shí)，可以通過(guò)鏈路分析篩選出耗時(shí)大于一定閾值的調(diào)用，再根據(jù)接口名稱(chēng)進(jìn)行分組統(tǒng)計(jì)，這樣就可以快速定位慢接口的列表與規(guī)律，然后對(duì)出現(xiàn)頻率最高的慢接口逐一進(jìn)行治理。

找到慢接口后，可以結(jié)合相關(guān)的調(diào)用鏈、方法棧和線程池等數(shù)據(jù)定位慢調(diào)用根因，常見(jiàn)原因包括以下幾類(lèi)：

• 數(shù)據(jù)庫(kù)/微服務(wù)連接池過(guò)小， 大量請(qǐng)求處于獲取連接狀態(tài)，可以調(diào)大連接池最大線程數(shù)解決。
• N+1 問(wèn)題， 比如一次外部請(qǐng)求內(nèi)部調(diào)用了上百次的數(shù)據(jù)庫(kù)調(diào)用，可以將碎片化的請(qǐng)求進(jìn)行合并，降低網(wǎng)絡(luò)傳輸耗時(shí)。
• 單次請(qǐng)求數(shù)據(jù)過(guò)大， 導(dǎo)致網(wǎng)絡(luò)傳輸和反序列化時(shí)間過(guò)長(zhǎng)且容易導(dǎo)致 FGC。可以將全量查詢改為分頁(yè)查詢，避免一次請(qǐng)求過(guò)多數(shù)據(jù)。
• 日志框架“熱鎖”， 可以將日志同步輸出改為異步輸出。

【業(yè)務(wù)流量統(tǒng)計(jì)】如何分析重保客戶/渠道的流量變化和服務(wù)質(zhì)量？

在實(shí)際生產(chǎn)環(huán)境中，服務(wù)通常是標(biāo)準(zhǔn)化的，但業(yè)務(wù)卻需要分類(lèi)分級(jí)。同樣的訂單服務(wù)，我們需要按照類(lèi)目、渠道、用戶等維度進(jìn)行分類(lèi)統(tǒng)計(jì)，實(shí)現(xiàn)精細(xì)化運(yùn)營(yíng)。比如，對(duì)于線下零售渠道而言，每一筆訂單、每一個(gè) POS 機(jī)的穩(wěn)定性都可能會(huì)觸發(fā)輿情，線下渠道的 SLA 要求要遠(yuǎn)高于線上渠道。那么，我們?nèi)绾卧谕ㄓ玫碾娚谭?wù)體系中，精準(zhǔn)的監(jiān)控線下零售鏈路的流量狀態(tài)和服務(wù)質(zhì)量呢？

在這里，可以使用鏈路分析的自定義 Attributes 過(guò)濾和統(tǒng)計(jì)實(shí)現(xiàn)低成本的業(yè)務(wù)鏈路分析。比如，我們?cè)谌肟诜?wù)針對(duì)線下訂單打上一個(gè) {“attributes.channel”: “offline”} 的標(biāo)簽，然后再針對(duì)不同門(mén)店、用戶客群和商品類(lèi)目分別打標(biāo)。最后，通過(guò)對(duì) attributes.channel = offline 進(jìn)行過(guò)濾，再對(duì)不同的業(yè)務(wù)標(biāo)簽進(jìn)行 group by 分組統(tǒng)計(jì)調(diào)用次數(shù)、耗時(shí)或錯(cuò)誤率等指標(biāo)，就可以快速的分析出每一類(lèi)業(yè)務(wù)場(chǎng)景的流量趨勢(shì)與服務(wù)質(zhì)量。

【灰度發(fā)布監(jiān)控】500臺(tái)機(jī)器分10批發(fā)布，如何在第一批灰度發(fā)布后，就能快速判斷是否有異常？

變更三板斧“可灰度、可監(jiān)控、可回滾”，是保障線上穩(wěn)定性的重要準(zhǔn)則。其中，分批次灰度變更是降低線上風(fēng)險(xiǎn)，控制爆炸半徑的關(guān)鍵手段。一旦發(fā)現(xiàn)灰度批次的服務(wù)狀態(tài)異常，應(yīng)及時(shí)進(jìn)行回滾，而不是繼續(xù)發(fā)布。然而，生產(chǎn)環(huán)境很多故障的發(fā)生都是由于缺乏有效的灰度監(jiān)控導(dǎo)致的。

例如，當(dāng)微服務(wù)注冊(cè)中心異常時(shí)，重啟發(fā)布的機(jī)器無(wú)法進(jìn)行服務(wù)注冊(cè)上線。由于缺乏灰度監(jiān)控，前幾批重啟機(jī)器雖然全部注冊(cè)失敗，導(dǎo)致所有流量都集中路由到最后一批機(jī)器，但是應(yīng)用監(jiān)控的總體流量和耗時(shí)沒(méi)有顯著變化，直至最后一批機(jī)器也重啟注冊(cè)失敗后，整個(gè)應(yīng)用進(jìn)入完全不可用狀態(tài)，最終釀成了嚴(yán)重的線上故障。

在上述案例中，如果對(duì)不同機(jī)器流量進(jìn)行版本打標(biāo) {“attributes.version”: “v1.0.x”} ，通過(guò)鏈路分析對(duì)attributes.version 進(jìn)行分組統(tǒng)計(jì)，可以清晰的區(qū)分發(fā)布前后或不同版本的流量變化和服務(wù)質(zhì)量。不會(huì)出現(xiàn)灰度批次異常被全局監(jiān)控掩蓋的情況。

鏈路分析的約束條件

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

基于鏈路明細(xì)數(shù)據(jù)進(jìn)行分析的成本較高。 鏈路分析的前提是盡可能完整的上報(bào)并存儲(chǔ)鏈路明細(xì)數(shù)據(jù)，如果采樣率比較低導(dǎo)致明細(xì)數(shù)據(jù)不全，鏈路分析的效果就會(huì)大打折扣。為了降低全量存儲(chǔ)成本，可以在用戶集群內(nèi)部署邊緣數(shù)據(jù)節(jié)點(diǎn)，進(jìn)行臨時(shí)數(shù)據(jù)緩存與處理，降低跨網(wǎng)絡(luò)上報(bào)開(kāi)銷(xiāo)。或者，在服務(wù)端進(jìn)行冷熱數(shù)據(jù)分離存儲(chǔ)，熱存儲(chǔ)進(jìn)行全量鏈路分析，冷存儲(chǔ)進(jìn)行錯(cuò)慢鏈路診斷。

后聚合分析的查詢性能開(kāi)銷(xiāo)大，并發(fā)小，不適合用于告警。 鏈路分析是實(shí)時(shí)的進(jìn)行全量數(shù)據(jù)掃描與統(tǒng)計(jì)，查詢性能開(kāi)銷(xiāo)要遠(yuǎn)大于預(yù)聚合統(tǒng)計(jì)指標(biāo)，所以不適合進(jìn)行高并發(fā)的告警查詢。需要結(jié)合自定義指標(biāo)功能將后聚合分析語(yǔ)句下推至客戶端進(jìn)行自定義指標(biāo)統(tǒng)計(jì)，以便支持告警與大盤(pán)定制。

結(jié)合自定義標(biāo)簽埋點(diǎn)，才能最大化釋放鏈路分析價(jià)值。 鏈路分析不同于標(biāo)準(zhǔn)的應(yīng)用監(jiān)控預(yù)聚合指標(biāo)，很多自定義場(chǎng)景的標(biāo)簽需要用戶手動(dòng)埋點(diǎn)打標(biāo)，這樣才能最有效的區(qū)分不同業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)精準(zhǔn)分析。

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

鏈路數(shù)據(jù)蘊(yùn)含著豐富的價(jià)值，傳統(tǒng)的調(diào)用鏈和服務(wù)視圖只是固定模式下的兩種經(jīng)典用法，基于后聚合的鏈路分析可以充分釋放診斷的靈活性，滿足任意場(chǎng)景、維度的自定義診斷需求。結(jié)合自定義指標(biāo)生成規(guī)則，更是可以極大的提升監(jiān)控告警的精細(xì)度，為你的 APM 插上“自由的翅膀”，推薦大家一起來(lái)體驗(yàn)、探索和分享！

點(diǎn)擊??此處??，了解更多鏈路追蹤信息！

總結(jié)

以上是生活随笔為你收集整理的链路分析 K.O “五大经典问题”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。