如何利用鏈路追蹤快速定位問題

“中浩弧烤,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洞見

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末算墨,一起剝皮案震驚了整個(gè)濱河市宵荒,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌净嘀,老刑警劉巖报咳,帶你破解...
    沈念sama閱讀 206,013評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異挖藏,居然都是意外死亡暑刃,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,205評論 2 382
  • 文/潘曉璐 我一進(jìn)店門膜眠,熙熙樓的掌柜王于貴愁眉苦臉地迎上來岩臣,“玉大人,你說我怎么就攤上這事宵膨〖芑眩” “怎么了?”我有些...
    開封第一講書人閱讀 152,370評論 0 342
  • 文/不壞的土叔 我叫張陵柄驻,是天一觀的道長狐树。 經(jīng)常有香客問我,道長鸿脓,這世上最難降的妖魔是什么抑钟? 我笑而不...
    開封第一講書人閱讀 55,168評論 1 278
  • 正文 為了忘掉前任涯曲,我火速辦了婚禮,結(jié)果婚禮上在塔,老公的妹妹穿的比我還像新娘幻件。我一直安慰自己,他們只是感情好蛔溃,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,153評論 5 371
  • 文/花漫 我一把揭開白布绰沥。 她就那樣靜靜地躺著,像睡著了一般贺待。 火紅的嫁衣襯著肌膚如雪徽曲。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 48,954評論 1 283
  • 那天麸塞,我揣著相機(jī)與錄音秃臣,去河邊找鬼。 笑死哪工,一個(gè)胖子當(dāng)著我的面吹牛奥此,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播雁比,決...
    沈念sama閱讀 38,271評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼稚虎,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了偎捎?” 一聲冷哼從身側(cè)響起蠢终,我...
    開封第一講書人閱讀 36,916評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎茴她,沒想到半個(gè)月后蜕径,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,382評論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡败京,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,877評論 2 323
  • 正文 我和宋清朗相戀三年兜喻,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片赡麦。...
    茶點(diǎn)故事閱讀 37,989評論 1 333
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡朴皆,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出泛粹,到底是詐尸還是另有隱情遂铡,我是刑警寧澤,帶...
    沈念sama閱讀 33,624評論 4 322
  • 正文 年R本政府宣布晶姊,位于F島的核電站扒接,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜钾怔,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,209評論 3 307
  • 文/蒙蒙 一碱呼、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧宗侦,春花似錦愚臀、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,199評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至男旗,卻和暖如春舶斧,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背察皇。 一陣腳步聲響...
    開封第一講書人閱讀 31,418評論 1 260
  • 我被黑心中介騙來泰國打工捧毛, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人让网。 一個(gè)月前我還...
    沈念sama閱讀 45,401評論 2 352
  • 正文 我出身青樓,卻偏偏與公主長得像师痕,于是被迫代替她去往敵國和親溃睹。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,700評論 2 345

推薦閱讀更多精彩內(nèi)容

  • 隨著微服務(wù)架構(gòu)的流行胰坟,服務(wù)按照不同的維度進(jìn)行拆分因篇,一次請求往往需要涉及到多個(gè)服務(wù)”屎幔互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集...
    哈嘍沃德先生閱讀 415評論 0 3
  • 分布式系統(tǒng)為什么需要鏈路追蹤竞滓? 隨著互聯(lián)網(wǎng)業(yè)務(wù)快速擴(kuò)展,軟件架構(gòu)也日益變得復(fù)雜吹缔,為了適應(yīng)海量用戶高并發(fā)請求商佑,系統(tǒng)中...
    Java李太白閱讀 571評論 0 1
  • 分布式鏈路追蹤(Distributed Tracing),也叫 分布式鏈路跟蹤厢塘,分布式跟蹤茶没,分布式追蹤 等等。 本...
    Daniel_adu閱讀 33,690評論 0 20
  • 一晚碾、0xcc開篇 2020年3月抓半,得物技術(shù)團(tuán)隊(duì)在三個(gè)月的時(shí)間內(nèi)完成了整個(gè)交易體系的重構(gòu),交付了五彩石項(xiàng)目格嘁,業(yè)務(wù)系統(tǒng)...
    得物技術(shù)閱讀 437評論 0 1
  • 背景 隨著互聯(lián)網(wǎng)架構(gòu)的擴(kuò)張笛求,分布式系統(tǒng)變得日趨復(fù)雜,越來越多的組件開始走向分布式化,如微服務(wù)探入、消息收發(fā)狡孔、分布式數(shù)據(jù)...
    Mccree_166a閱讀 375評論 0 0