“中浩弧烤,xxx接口報(bào)錯(cuò)了你看一下咋回事”
“稍等一下哈涧黄,我看一下漓帚。Xxx組的xxx接口報(bào)錯(cuò)了,我們這邊直接拋錯(cuò)了”
“具體啥問題啊母债,你看下日志,我去找xxx組的人問一下尝抖,現(xiàn)在阻塞流程了啊”
“呃毡们。。昧辽。對這個(gè)接口的請求日志好難找啊衙熔,這個(gè)接口請求很頻繁,不知道報(bào)錯(cuò)的是哪一條搅荞。红氯】蛄”
“中浩,xxx接口太慢了痢甘,你看下是什么原因?qū)е碌摹?/em>
“這個(gè)接口我們掉了很多外部接口啊喇嘱,不知道具體是哪個(gè)接口太慢了”
不知道身在項(xiàng)目的小伙伴對上面這樣的對話熟不熟悉。在項(xiàng)目初期塞栅,每次收到QA這樣的詢問者铜,作為開發(fā)的我都覺得很頭大。(因?yàn)橛行┤罩疚沂钦娴恼也坏剑┗跇I(yè)務(wù)的復(fù)雜放椰,項(xiàng)目中接入了大量的外部接口作烟。服務(wù)與服務(wù)鏈路之間的調(diào)用關(guān)系也變得錯(cuò)綜復(fù)雜。此時(shí)庄敛,在我們遇上問題排查的時(shí)候俗壹,追溯到了某個(gè)接口之后線索就斷了,非常難再往下定位問題藻烤。
此時(shí)我們自然而然地就會(huì)想:難道就沒有一種方法能夠把請求的整個(gè)調(diào)用鏈路記錄下來绷雏,并通過某個(gè)唯一id標(biāo)記,同時(shí)對每個(gè)節(jié)點(diǎn)都進(jìn)行記錄嘛怖亭?這樣我們就能通過標(biāo)記在請求鏈路上的這個(gè)唯一id來快速定位問題涎显,從而大量節(jié)省我們排查問題和統(tǒng)計(jì)分析的時(shí)間。其實(shí)上述的只是我們在微服務(wù)中最常遇上的兩個(gè)問題兴猩。隨著微服務(wù)應(yīng)用數(shù)量的極速增加期吓,服務(wù)與服務(wù)鏈路之間的調(diào)用關(guān)系也變得錯(cuò)綜復(fù)雜。此時(shí)倾芝,我們也會(huì)碰到其他各種難題讨勤。
- 系統(tǒng)出現(xiàn)問題后,由于服務(wù)鏈路過長或過于復(fù)雜晨另,無法快速準(zhǔn)確定位問題潭千。客戶端(如瀏覽器)或者移動(dòng)端應(yīng)用報(bào)出異辰枘颍或者錯(cuò)誤刨晴,也無法確定是哪個(gè)服務(wù)拋出的異常。
- 某個(gè)業(yè)務(wù)請求非常慢路翻,且總是超時(shí)狈癞,無法確定系統(tǒng)哪個(gè)環(huán)節(jié)存在性能的問題。
- 修改成:如何快速發(fā)現(xiàn)問題并可以通過調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯(cuò)誤信息茂契?
- 如何判斷故障影響范圍蝶桶,并將各個(gè)階段鏈路耗時(shí)、服務(wù)依賴關(guān)系可以通過可視化界面展現(xiàn)出來掉冶,從而直觀地審視故障的影響范圍真竖?
- 如何梳理服務(wù)依賴以及依賴的合理性儡蔓?如何分析鏈路性能問題以及實(shí)時(shí)容量規(guī)劃?通過分析鏈路耗時(shí)疼邀、服務(wù)間的依賴關(guān)系,就可以得到用戶的行為路徑召锈,匯總分析出具體出問題的場景旁振。
這個(gè)時(shí)候,鏈路追蹤能夠幫助我們解決這些實(shí)際問題涨岁。
圖片來源:《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010
假設(shè)現(xiàn)在有一個(gè)如上圖所示的請求拐袜,我們應(yīng)該怎樣對這個(gè)請求進(jìn)行記錄呢?
鏈路追蹤的重要概念:
現(xiàn)在市面上絕大部分的鏈路追蹤系統(tǒng)都是以谷歌公開論文中提到的Dapper為基礎(chǔ)構(gòu)建而成梢薪,所以我們先來一起看看調(diào)用鏈監(jiān)控中的幾個(gè)重要概念蹬铺。
Trace
在之前的描述中我們已經(jīng)想到,能不能通過一個(gè)唯一id來標(biāo)記我們的請求秉撇,從而將整個(gè)請求從頭到尾串聯(lián)起來甜攀。在鏈路追蹤中,trace是請求在分布式系統(tǒng)中的整個(gè)鏈路視圖琐馆。我們可以把trace看作一棵二叉樹规阀,從中我們能直觀地看到請求經(jīng)過所有服務(wù)的路徑。從請求到服務(wù)器開始瘦麸,到服務(wù)器返回響應(yīng)數(shù)據(jù)結(jié)束谁撼,跟蹤每次RPC調(diào)用的耗時(shí),并使用唯一標(biāo)識trace id滋饲。在整個(gè)請求的調(diào)用鏈中厉碟,請求會(huì)一直攜帶 trace id 往下游服務(wù)傳遞,且在整個(gè)調(diào)用鏈中始終保持不變屠缭,所以在日志中可以通過 trace id 查詢到整個(gè)請求期間系統(tǒng)記錄下來的所有日志箍鼓。
Span
在建立了一個(gè)完整的標(biāo)識之后,我們還希望對每個(gè)節(jié)點(diǎn)都進(jìn)行記錄勿她。不然我們只知道一個(gè)請求調(diào)用了那些服務(wù)袄秩,但是卻不清楚各個(gè)服務(wù)之間的上下游以及調(diào)用關(guān)系。span 是代表整個(gè)鏈路中不同服務(wù)內(nèi)部的視圖逢并。如果我們將trace看作 一棵樹的話之剧,那么span就是這棵樹上的不同節(jié)點(diǎn)。
每個(gè) span 都記錄著 parent id 和 trace id砍聊,表明其所屬父節(jié)點(diǎn)和調(diào)用鏈背稼,其中沒有 parent id 的 span 稱為 root span,root span 的 id 就是 trace id玻蝌。請求到達(dá)每個(gè)服務(wù)后蟹肘,服務(wù)都會(huì)為請求生成span id词疼,而隨請求一起從上游傳過來的上游服務(wù)的 span id 會(huì)被記錄成parent-span id。
當(dāng)前服務(wù)生成的 span id 隨著請求一起再傳到下游服務(wù)時(shí)帘腹,這個(gè)span id 又會(huì)被下游服務(wù)當(dāng)做 parent-span id記錄贰盗。通過span的ID我們可以輕松了解服務(wù)的父服務(wù)是誰,再結(jié)合trace id就可以將一條完整的請求調(diào)用鏈串聯(lián)起來阳欲。
圖片來源:《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010
針對以上請求舵盈,整個(gè)調(diào)用的鏈路就如圖所示非常清晰了。
Annotation
在上述遇到的問題中球化,我們除了希望得到整個(gè)請求的鏈路秽晚。還希望能夠?qū)ζ渲械哪硞€(gè)服務(wù)進(jìn)行調(diào)優(yōu)。這個(gè)時(shí)候我們就需要對單個(gè)服務(wù)筒愚,或者說是span赴蝇,記錄更多的信息。這個(gè)時(shí)候就需要Annotation的概念了.
圖片來源:《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 -- Google Technical Report dapper-2010-1, April 2010
- Client Start:表示客戶端發(fā)起請求巢掺;
- Server Received:表示服務(wù)端收到請求句伶;
- Server Send:表示服務(wù)端完成處理,并將結(jié)果發(fā)送給客戶端址遇;
- Client Received:表示客戶端獲取到服務(wù)端返回的響應(yīng)數(shù)據(jù)熄阻。
結(jié)合上圖我們,我們可以利用Annotation里的信息來計(jì)算一次調(diào)用的耗時(shí)倔约,只需將客戶端結(jié)束的時(shí)間點(diǎn)減去客戶端開始請求的時(shí)間點(diǎn)秃殉。如果要計(jì)算客戶端發(fā)送網(wǎng)絡(luò)耗時(shí),即客戶端接收請求的時(shí)間點(diǎn)減去客戶端發(fā)送請求的時(shí)間點(diǎn)浸剩。
Zipkin實(shí)例
遵循以上三點(diǎn)鏈路追蹤的核心思路钾军,我們來看一看現(xiàn)在市面上主流的鏈路追蹤款框架都是怎么實(shí)現(xiàn)的,這里我們以Zipkin為例绢要。
可以看到吏恭,我們的請求到達(dá)服務(wù)器之后被攔截下來:
在這個(gè)filter中,框架首先會(huì)查詢我們請求(request)是否存在鏈路信息重罪。圖中可以看到樱哼,我們的初次請求是沒有trace的內(nèi)容的:
同時(shí)由于是首次請求,所以請求中也不會(huì)有parent-span的信息剿配。在圖中也已看到搅幅,這個(gè)時(shí)候框架會(huì)給請求生成一個(gè)span信息和trace信息:
由于是初次請求,span id就作為鏈路的trace id:
最后框架將生成的span信息和trace信息呼胚,設(shè)置到我們請求的attribute當(dāng)中并傳遞下去:
通過我們的代碼茄唐,我們能夠很清晰的看到zipkin是如何給我們的請求加上trace信息和span信息,并將其傳遞下去的蝇更。此時(shí)我們就能夠通過trace中的trace id沪编,快速地發(fā)現(xiàn)和定位問題呼盆。
小結(jié)
本文介紹鏈路追蹤的關(guān)鍵概念和實(shí)現(xiàn),讓讀者初步了解鏈路追蹤的作用蚁廓。實(shí)際上访圃,鏈路追蹤最大的價(jià)值在于“關(guān)聯(lián)”。我們可以從數(shù)據(jù)層面關(guān)聯(lián)應(yīng)用日志(Logs)相嵌、關(guān)鍵事件(Events)挽荠、性能指標(biāo)(Metrics)或診斷工具(Profiling),也可以從系統(tǒng)層面關(guān)聯(lián)用戶終端平绩、網(wǎng)關(guān)、應(yīng)用漠另、中間件捏雌、容器與基礎(chǔ)設(shè)施。通過鏈路追蹤笆搓,我們可以構(gòu)建一張軌跡拓?fù)浯髨D性湿。這張拓?fù)鋱D覆蓋的范圍越廣,鏈路追蹤就能發(fā)揮的價(jià)值就越大满败。全鏈路追蹤是覆蓋全部關(guān)聯(lián) IT 系統(tǒng)的最佳實(shí)踐方案肤频,能夠完整記錄用戶行為在系統(tǒng)間的調(diào)用路徑與狀態(tài)。
文/Thoughtworks 尹中浩
原文鏈接:如何使用鏈路追蹤快速定位問題-Thoughtworks洞見