轉(zhuǎn)載:Dapper韵卤，大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)

當(dāng)代的互聯(lián)網(wǎng)的服務(wù)骗污，通常都是用復(fù)雜的、大規(guī)模分布式集群來(lái)實(shí)現(xiàn)的沈条∩肀ぃ互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上，這些軟件模塊拍鲤，有可能是由不同的團(tuán)隊(duì)開(kāi)發(fā)、可能使用不同的編程語(yǔ)言來(lái)實(shí)現(xiàn)汞扎、有可能布在了幾千臺(tái)服務(wù)器季稳，橫跨多個(gè)不同的數(shù)據(jù)中心。因此澈魄，就需要一些可以幫助理解系統(tǒng)行為景鼠、用于分析性能問(wèn)題的工具。

原文作者：Benjamin H. Sigelman, Luiz Andr′e Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan Shanbhag

翻譯：bigbully

地址：http://bigbully.github.io/Dapper-translation/

概述

Dapper--Google生產(chǎn)環(huán)境下的分布式跟蹤系統(tǒng)痹扇，應(yīng)運(yùn)而生铛漓。那么我們就來(lái)介紹一個(gè)大規(guī)模集群的跟蹤系統(tǒng)，它是如何滿足一個(gè)低損耗鲫构、應(yīng)用透明的浓恶、大范圍部署這三個(gè)需求的。當(dāng)然Dapper設(shè)計(jì)之初结笨，參考了一些其他分布式系統(tǒng)的理念包晰，尤其是Magpie和X-Trace湿镀，但是我們之所以能成功應(yīng)用在生產(chǎn)環(huán)境上，還需要一些畫(huà)龍點(diǎn)睛之筆伐憾，例如采樣率的使用以及把代碼植入限制在一小部分公共庫(kù)的改造上勉痴。

自從Dapper發(fā)展成為一流的監(jiān)控系統(tǒng)之后，給其他應(yīng)用的開(kāi)發(fā)者和運(yùn)維團(tuán)隊(duì)幫了大忙树肃，所以我們今天才發(fā)表這篇論文蒸矛，來(lái)匯報(bào)一下這兩年來(lái)，Dapper是怎么構(gòu)建和部署的胸嘴。Dapper最初只是作為一個(gè)自給自足的監(jiān)控工具起步的雏掠，但最終進(jìn)化成一個(gè)監(jiān)控平臺(tái)，這個(gè)監(jiān)控平臺(tái)促生出多種多樣的監(jiān)控工具筛谚，有些甚至已經(jīng)不是由Dapper團(tuán)隊(duì)開(kāi)發(fā)的了磁玉。下面我們會(huì)介紹一些使用Dapper搭建的分析工具，分享一下這些工具在google內(nèi)部使用的統(tǒng)計(jì)數(shù)據(jù)驾讲，展現(xiàn)一些使用場(chǎng)景蚊伞，最后會(huì)討論一下我們迄今為止從Dapper收獲了些什么。

1. 介紹

我們開(kāi)發(fā)Dapper是為了收集更多的復(fù)雜分布式系統(tǒng)的行為信息吮铭，然后呈現(xiàn)給Google的開(kāi)發(fā)者們时迫。這樣的分布式系統(tǒng)有一個(gè)特殊的好處，因?yàn)槟切┐笠?guī)模的低端服務(wù)器谓晌，作為互聯(lián)網(wǎng)服務(wù)的載體掠拳，是一個(gè)特殊的經(jīng)濟(jì)劃算的平臺(tái)。想要在這個(gè)上下文中理解分布式系統(tǒng)的行為纸肉，就需要監(jiān)控那些橫跨了不同的應(yīng)用溺欧、不同的服務(wù)器之間的關(guān)聯(lián)動(dòng)作。

下面舉一個(gè)跟搜索相關(guān)的例子柏肪，這個(gè)例子闡述了Dapper可以應(yīng)對(duì)哪些挑戰(zhàn)姐刁。比如一個(gè)前端服務(wù)可能對(duì)上百臺(tái)查詢服務(wù)器發(fā)起了一個(gè)Web查詢，每一個(gè)查詢都有自己的Index烦味。這個(gè)查詢可能會(huì)被發(fā)送到多個(gè)的子系統(tǒng)聂使，這些子系統(tǒng)分別用來(lái)處理廣告、進(jìn)行拼寫(xiě)檢查或是查找一些像圖片谬俄、視頻或新聞這樣的特殊結(jié)果柏靶。根據(jù)每個(gè)子系統(tǒng)的查詢結(jié)果進(jìn)行篩選，得到最終結(jié)果溃论，最后匯總到頁(yè)面上屎蜓。我們把這種搜索模型稱為“全局搜索”（universal search）≡垦總的來(lái)說(shuō)梆靖，這一次全局搜索有可能調(diào)用上千臺(tái)服務(wù)器控汉，涉及各種服務(wù)。而且返吻，用戶對(duì)搜索的耗時(shí)是很敏感的姑子，而任何一個(gè)子系統(tǒng)的低效都導(dǎo)致導(dǎo)致最終的搜索耗時(shí)。如果一個(gè)工程師只能知道這個(gè)查詢耗時(shí)不正常测僵，但是他無(wú)從知曉這個(gè)問(wèn)題到底是由哪個(gè)服務(wù)調(diào)用造成的街佑，或者為什么這個(gè)調(diào)用性能差強(qiáng)人意。首先捍靠，這個(gè)工程師可能無(wú)法準(zhǔn)確的定位到這次全局搜索是調(diào)用了哪些服務(wù)沐旨，因?yàn)樾碌姆?wù)、乃至服務(wù)上的某個(gè)片段榨婆，都有可能在任何時(shí)間上過(guò)線或修改過(guò)磁携，有可能是面向用戶功能，也有可能是一些例如針對(duì)性能或安全認(rèn)證方面的功能改進(jìn)良风。其次谊迄，你不能苛求這個(gè)工程師對(duì)所有參與這次全局搜索的服務(wù)都了如指掌，每一個(gè)服務(wù)都有可能是由不同的團(tuán)隊(duì)開(kāi)發(fā)或維護(hù)的烟央。再次统诺，這些暴露出來(lái)的服務(wù)或服務(wù)器有可能同時(shí)還被其他客戶端使用著，所以這次全局搜索的性能問(wèn)題甚至有可能是由其他應(yīng)用造成的疑俭。舉個(gè)例子粮呢，一個(gè)后臺(tái)服務(wù)可能要應(yīng)付各種各樣的請(qǐng)求類型，而一個(gè)使用效率很高的存儲(chǔ)系統(tǒng)钞艇，比如Bigtable啄寡，有可能正被反復(fù)讀寫(xiě)著，因?yàn)樯厦媾苤鞣N各樣的應(yīng)用哩照。

上面這個(gè)案例中我們可以看到挺物，對(duì)Dapper我們只有兩點(diǎn)要求：無(wú)所不在的部署，持續(xù)的監(jiān)控葡秒。無(wú)所不在的重要性不言而喻，因?yàn)樵谑褂酶櫹到y(tǒng)的進(jìn)行監(jiān)控時(shí)嵌溢，即便只有一小部分沒(méi)被監(jiān)控到，那么人們對(duì)這個(gè)系統(tǒng)是不是值得信任都會(huì)產(chǎn)生巨大的質(zhì)疑。另外晕换，監(jiān)控應(yīng)該是7x24小時(shí)的乡翅，畢竟，系統(tǒng)異逞砥铮或是那些重要的系統(tǒng)行為有可能出現(xiàn)過(guò)一次版确，就很難甚至不太可能重現(xiàn)扣囊。那么，根據(jù)這兩個(gè)明確的需求绒疗，我們可以直接推出三個(gè)具體的設(shè)計(jì)目標(biāo)：

1.低消耗：跟蹤系統(tǒng)對(duì)在線服務(wù)的影響應(yīng)該做到足夠小侵歇。在一些高度優(yōu)化過(guò)的服務(wù)，即使一點(diǎn)點(diǎn)損耗也會(huì)很容易察覺(jué)到吓蘑，而且有可能迫使在線服務(wù)的部署團(tuán)隊(duì)不得不將跟蹤系統(tǒng)關(guān)停惕虑。

2.應(yīng)用級(jí)的透明：對(duì)于應(yīng)用的程序員來(lái)說(shuō)，是不需要知道有跟蹤系統(tǒng)這回事的磨镶。如果一個(gè)跟蹤系統(tǒng)想生效溃蔫，就必須需要依賴應(yīng)用的開(kāi)發(fā)者主動(dòng)配合，那么這個(gè)跟蹤系統(tǒng)也太脆弱了琳猫，往往由于跟蹤系統(tǒng)在應(yīng)用中植入代碼的bug或疏忽導(dǎo)致應(yīng)用出問(wèn)題伟叛，這樣才是無(wú)法滿足對(duì)跟蹤系統(tǒng)“無(wú)所不在的部署”這個(gè)需求。面對(duì)當(dāng)下想Google這樣的快節(jié)奏的開(kāi)發(fā)環(huán)境來(lái)說(shuō)脐嫂，尤其重要统刮。

3.延展性：Google至少在未來(lái)幾年的服務(wù)和集群的規(guī)模，監(jiān)控系統(tǒng)都應(yīng)該能完全把控住雹锣。

一個(gè)額外的設(shè)計(jì)目標(biāo)是為跟蹤數(shù)據(jù)產(chǎn)生之后网沾，進(jìn)行分析的速度要快，理想情況是數(shù)據(jù)存入跟蹤倉(cāng)庫(kù)后一分鐘內(nèi)就能統(tǒng)計(jì)出來(lái)蕊爵。盡管跟蹤系統(tǒng)對(duì)一小時(shí)前的舊數(shù)據(jù)進(jìn)行統(tǒng)計(jì)也是相當(dāng)有價(jià)值的辉哥，但如果跟蹤系統(tǒng)能提供足夠快的信息反饋，就可以對(duì)生產(chǎn)環(huán)境下的異常狀況做出快速反應(yīng)攒射。

做到真正的應(yīng)用級(jí)別的透明醋旦，這應(yīng)該是當(dāng)下面臨的最挑戰(zhàn)性的設(shè)計(jì)目標(biāo)，我們把核心跟蹤代碼做的很輕巧会放，然后把它植入到那些無(wú)所不在的公共組件種饲齐，比如線程調(diào)用、控制流以及RPC庫(kù)咧最。使用自適應(yīng)的采樣率可以使跟蹤系統(tǒng)變得可伸縮捂人，并降低性能損耗，這些內(nèi)容將在第4.4節(jié)中提及矢沿。結(jié)果展示的相關(guān)系統(tǒng)也需要包含一些用來(lái)收集跟蹤數(shù)據(jù)的代碼滥搭，用來(lái)圖形化的工具，以及用來(lái)分析大規(guī)模跟蹤數(shù)據(jù)的庫(kù)和API捣鲸。雖然單獨(dú)使用Dapper有時(shí)就足夠讓開(kāi)發(fā)人員查明異常的來(lái)源瑟匆，但是Dapper的初衷不是要取代所有其他監(jiān)控的工具。我們發(fā)現(xiàn)栽惶，Dapper的數(shù)據(jù)往往側(cè)重性能方面的調(diào)查愁溜，所以其他監(jiān)控工具也有他們各自的用處疾嗅。

1.1 文獻(xiàn)的總結(jié)

分布式系統(tǒng)跟蹤工具的設(shè)計(jì)空間已經(jīng)被一些優(yōu)秀文章探索過(guò)了，其中的Pinpoint9冕象、Magpie3和X-Trace12和Dapper最為相近代承。這些系統(tǒng)在其發(fā)展過(guò)程的早期傾向于寫(xiě)入研究報(bào)告中，即便他們還沒(méi)來(lái)得及清楚地評(píng)估系統(tǒng)當(dāng)中一些設(shè)計(jì)的重要性交惯。相比之下次泽，由于Dapper已經(jīng)在大規(guī)模生產(chǎn)環(huán)境中摸爬滾打了多年，經(jīng)過(guò)這么多生產(chǎn)環(huán)境的驗(yàn)證之后席爽，我們認(rèn)為這篇論文最適合重點(diǎn)闡述在部署Dapper的過(guò)程中我們有那些收獲意荤，我們的設(shè)計(jì)思想是如何決定的，以及以什么樣的方式實(shí)現(xiàn)它才會(huì)最有用只锻。Dappe作為一個(gè)平臺(tái)玖像，承載基于Dapper開(kāi)發(fā)的性能分析工具，以及Dapper自身的監(jiān)測(cè)工具齐饮，它的價(jià)值在于我們可以在回顧評(píng)估中找出一些意想不到的結(jié)果捐寥。

雖然Dapper在許多高階的設(shè)計(jì)思想上吸取了Pinpoint和Magpie的研究成果，但在分布式跟蹤這個(gè)領(lǐng)域中祖驱，Dapper的實(shí)現(xiàn)包含了許多新的貢獻(xiàn)握恳。例如，我們想實(shí)現(xiàn)低損耗的話捺僻，特別是在高度優(yōu)化的而且趨于極端延遲敏感的Web服務(wù)中乡洼，采樣率是很必要的∝芭鳎或許更令人驚訝的是束昵，我們發(fā)現(xiàn)即便是1/1000的采樣率，對(duì)于跟蹤數(shù)據(jù)的通用使用層面上葛峻，也可以提供足夠多的信息锹雏。

我們的系統(tǒng)的另一個(gè)重要的特征，就是我們能實(shí)現(xiàn)的應(yīng)用級(jí)的透明术奖。我們的組件對(duì)應(yīng)用的侵入被先限制在足夠低的水平上礁遵，即使想Google網(wǎng)頁(yè)搜索這么大規(guī)模的分布式系統(tǒng)，也可以直接進(jìn)行跟蹤而無(wú)需加入額外的標(biāo)注(Annotation)采记。雖然由于我們的部署系統(tǒng)有幸是一定程度的同質(zhì)化的佣耐，所以更容易做到對(duì)應(yīng)用層的透明這點(diǎn)，但是我們證明了這是實(shí)現(xiàn)這種程度的透明性的充分條件挺庞。

2. Dapper的分布式跟蹤

圖1：這個(gè)路徑由用戶的X請(qǐng)求發(fā)起晰赞，穿過(guò)一個(gè)簡(jiǎn)單的服務(wù)系統(tǒng)稼病。用字母標(biāo)識(shí)的節(jié)點(diǎn)代表分布式系統(tǒng)中的不同處理過(guò)程选侨。

分布式服務(wù)的跟蹤系統(tǒng)需要記錄在一次特定的請(qǐng)求后系統(tǒng)中完成的所有工作的信息掖鱼。舉個(gè)例子，圖1展現(xiàn)的是一個(gè)和5臺(tái)服務(wù)器相關(guān)的一個(gè)服務(wù)援制，包括：前端（A）戏挡，兩個(gè)中間層（B和C），以及兩個(gè)后端（D和E）晨仑。當(dāng)一個(gè)用戶（這個(gè)用例的發(fā)起人）發(fā)起一個(gè)請(qǐng)求時(shí)褐墅，首先到達(dá)前端，然后發(fā)送兩個(gè)RPC到服務(wù)器B和C洪己。B會(huì)馬上做出反應(yīng)妥凳，但是C需要和后端的D和E交互之后再返還給A，由A來(lái)響應(yīng)最初的請(qǐng)求答捕。對(duì)于這樣一個(gè)請(qǐng)求逝钥，簡(jiǎn)單實(shí)用的分布式跟蹤的實(shí)現(xiàn)，就是為服務(wù)器上每一次你發(fā)送和接收動(dòng)作來(lái)收集跟蹤標(biāo)識(shí)符(message identifiers)和時(shí)間戳(timestamped events)拱镐。

為了將所有記錄條目與一個(gè)給定的發(fā)起者（例如艘款，圖1中的RequestX）關(guān)聯(lián)上并記錄所有信息，現(xiàn)在有兩種解決方案沃琅，黑盒(black-box)和基于標(biāo)注(annotation-based)的監(jiān)控方案哗咆。黑盒方案[1，15益眉，2]假定需要跟蹤的除了上述信息之外沒(méi)有額外的信息晌柬，這樣使用統(tǒng)計(jì)回歸技術(shù)來(lái)推斷兩者之間的關(guān)系∥亟校基于標(biāo)注的方案[3空繁，12，9朱庆，16]依賴于應(yīng)用程序或中間件明確地標(biāo)記一個(gè)全局ID盛泡，從而連接每一條記錄和發(fā)起者的請(qǐng)求。雖然黑盒方案比標(biāo)注方案更輕便娱颊，他們需要更多的數(shù)據(jù)傲诵，以獲得足夠的精度，因?yàn)樗麄円蕾囉诮y(tǒng)計(jì)推論箱硕∷┲瘢基于標(biāo)注的方案最主要的缺點(diǎn)是，很明顯剧罩，需要代碼植入栓拜。在我們的生產(chǎn)環(huán)境中，因?yàn)樗械膽?yīng)用程序都使用相同的線程模型，控制流和RPC系統(tǒng)幕与，我們發(fā)現(xiàn)挑势，可以把代碼植入限制在一個(gè)很小的通用組件庫(kù)中，從而實(shí)現(xiàn)了監(jiān)測(cè)系統(tǒng)的應(yīng)用對(duì)開(kāi)發(fā)人員是有效地透明啦鸣。

我們傾向于認(rèn)為潮饱，Dapper的跟蹤架構(gòu)像是內(nèi)嵌在RPC調(diào)用的樹(shù)形結(jié)構(gòu)。然而诫给，我們的核心數(shù)據(jù)模型不只局限于我們的特定的RPC框架香拉，我們還能跟蹤其他行為，例如Gmail的SMTP會(huì)話中狂，外界的HTTP請(qǐng)求凫碌，和外部對(duì)SQL服務(wù)器的查詢等。從形式上看胃榕，我們的Dapper跟蹤模型使用的樹(shù)形結(jié)構(gòu)证鸥，Span以及Annotation。

2.1 跟蹤樹(shù)和span

在Dapper跟蹤樹(shù)結(jié)構(gòu)中勤晚，樹(shù)節(jié)點(diǎn)是整個(gè)架構(gòu)的基本單元枉层，而每一個(gè)節(jié)點(diǎn)又是對(duì)span的引用。節(jié)點(diǎn)之間的連線表示的span和它的父span直接的關(guān)系赐写。雖然span在日志文件中只是簡(jiǎn)單的代表span的開(kāi)始和結(jié)束時(shí)間鸟蜡，他們?cè)谡麄€(gè)樹(shù)形結(jié)構(gòu)中卻是相對(duì)獨(dú)立的，任何RPC相關(guān)的時(shí)間數(shù)據(jù)挺邀、零個(gè)或多個(gè)特定應(yīng)用程序的Annotation的相關(guān)內(nèi)容會(huì)在2.3節(jié)中討論揉忘。

圖2：5個(gè)span在Dapper跟蹤樹(shù)種短暫的關(guān)聯(lián)關(guān)系

在圖2中說(shuō)明了span在一個(gè)大的跟蹤過(guò)程中是什么樣的。Dapper記錄了span名稱端铛，以及每個(gè)span的ID和父ID泣矛，以重建在一次追蹤過(guò)程中不同span之間的關(guān)系。如果一個(gè)span沒(méi)有父ID被稱為root span禾蚕。所有span都掛在一個(gè)特定的跟蹤上您朽，也共用一個(gè)跟蹤id（在圖中未示出）。所有這些ID用全局唯一的64位整數(shù)標(biāo)示换淆。在一個(gè)典型的Dapper跟蹤中哗总，我們希望為每一個(gè)RPC對(duì)應(yīng)到一個(gè)單一的span上，而且每一個(gè)額外的組件層都對(duì)應(yīng)一個(gè)跟蹤樹(shù)型結(jié)構(gòu)的層級(jí)倍试。

圖3給出了一個(gè)更詳細(xì)的典型的Dapper跟蹤span的記錄點(diǎn)的視圖讯屈。在圖2中這種某個(gè)span表述了兩個(gè)“Helper.Call”的RPC(分別為server端和client端)。span的開(kāi)始時(shí)間和結(jié)束時(shí)間县习，以及任何RPC的時(shí)間信息都通過(guò)Dapper在RPC組件庫(kù)的植入記錄下來(lái)涮母。如果應(yīng)用程序開(kāi)發(fā)者選擇在跟蹤中增加他們自己的注釋（如圖中“foo”的注釋）(業(yè)務(wù)數(shù)據(jù))谆趾，這些信息也會(huì)和其他span信息一樣記錄下來(lái)。

記住叛本，任何一個(gè)span可以包含來(lái)自不同的主機(jī)信息棺妓，這些也要記錄下來(lái)。事實(shí)上炮赦，每一個(gè)RPC span可以包含客戶端和服務(wù)器兩個(gè)過(guò)程的注釋，使得鏈接兩個(gè)主機(jī)的span會(huì)成為模型中所說(shuō)的span样勃。由于客戶端和服務(wù)器上的時(shí)間戳來(lái)自不同的主機(jī)吠勘，我們必須考慮到時(shí)間偏差。在我們的分析工具峡眶，我們利用了這個(gè)事實(shí)：RPC客戶端發(fā)送一個(gè)請(qǐng)求之后剧防，服務(wù)器端才能接收到，對(duì)于響應(yīng)也是一樣的（服務(wù)器先響應(yīng)辫樱，然后客戶端才能接收到這個(gè)響應(yīng)）峭拘。這樣一來(lái)，服務(wù)器端的RPC就有一個(gè)時(shí)間戳的一個(gè)上限和下限狮暑。

2.2 植入點(diǎn)

Dapper可以以對(duì)應(yīng)用開(kāi)發(fā)者近乎零浸入的成本對(duì)分布式控制路徑進(jìn)行跟蹤鸡挠，幾乎完全依賴于基于少量通用組件庫(kù)的改造。如下：

當(dāng)一個(gè)線程在處理跟蹤控制路徑的過(guò)程中搬男，Dapper把這次跟蹤的上下文的在ThreadLocal中進(jìn)行存儲(chǔ)拣展。追蹤上下文是一個(gè)小而且容易復(fù)制的容器，其中承載了Scan的屬性比如跟蹤ID和span ID缔逛。

當(dāng)計(jì)算過(guò)程是延遲調(diào)用的或是異步的备埃，大多數(shù)Google開(kāi)發(fā)者通過(guò)線程池或其他執(zhí)行器，使用一個(gè)通用的控制流庫(kù)來(lái)回調(diào)褐奴。Dapper確保所有這樣的回調(diào)可以存儲(chǔ)這次跟蹤的上下文按脚，而當(dāng)回調(diào)函數(shù)被觸發(fā)時(shí)，這次跟蹤的上下文會(huì)與適當(dāng)?shù)木€程關(guān)聯(lián)上敦冬。在這種方式下辅搬，Dapper可以使用trace ID和span ID來(lái)輔助構(gòu)建異步調(diào)用的路徑。

幾乎所有的Google的進(jìn)程間通信是建立在一個(gè)用C++和Java開(kāi)發(fā)的RPC框架上脖旱。我們把跟蹤植入該框架來(lái)定義RPC中所有的span伞辛。span的ID和跟蹤的ID會(huì)從客戶端發(fā)送到服務(wù)端。像那樣的基于RPC的系統(tǒng)被廣泛使用在Google中夯缺，這是一個(gè)重要的植入點(diǎn)蚤氏。當(dāng)那些非RPC通信框架發(fā)展成熟并找到了自己的用戶群之后，我們會(huì)計(jì)劃對(duì)RPC通信框架進(jìn)行植入踊兜。

Dapper的跟蹤數(shù)據(jù)是獨(dú)立于語(yǔ)言的竿滨，很多在生產(chǎn)環(huán)境中的跟蹤結(jié)合了用C++和Java寫(xiě)的進(jìn)程的數(shù)據(jù)。在3.2節(jié)中，我們討論應(yīng)用程序的透明度時(shí)我們會(huì)把這些理論的是如何實(shí)踐的進(jìn)行討論于游。

2.3 Annotation

上述植入點(diǎn)足夠推導(dǎo)出復(fù)雜的分布式系統(tǒng)的跟蹤細(xì)節(jié)毁葱，使得Dapper的核心功能在不改動(dòng)Google應(yīng)用的情況下可用。然而贰剥，Dapper還允許應(yīng)用程序開(kāi)發(fā)人員在Dapper跟蹤的過(guò)程中添加額外的信息倾剿，以監(jiān)控更高級(jí)別的系統(tǒng)行為，或幫助調(diào)試問(wèn)題蚌成。我們?cè)试S用戶通過(guò)一個(gè)簡(jiǎn)單的API定義帶時(shí)間戳的Annotation前痘，核心的示例代碼入圖4所示。這些Annotation可以添加任意內(nèi)容担忧。為了保護(hù)Dapper的用戶意外的過(guò)分熱衷于日志的記錄芹缔，每一個(gè)跟蹤span有一個(gè)可配置的總Annotation量的上限。但是瓶盛，應(yīng)用程序級(jí)的Annotation是不能替代用于表示span結(jié)構(gòu)的信息和記錄著RPC相關(guān)的信息最欠。

除了簡(jiǎn)單的文本Annotation，Dapper也支持的key-value映射的 Annotation惩猫，提供給開(kāi)發(fā)人員更強(qiáng)的跟蹤能力芝硬，如持續(xù)的計(jì)數(shù)器，二進(jìn)制消息記錄和在一個(gè)進(jìn)程上跑著的任意的用戶數(shù)據(jù)轧房。鍵值對(duì)的Annotation方式用來(lái)在分布式追蹤的上下文中定義某個(gè)特定應(yīng)用程序的相關(guān)類型吵取。

2.4 采樣率

低損耗的是Dapper的一個(gè)關(guān)鍵的設(shè)計(jì)目標(biāo)，因?yàn)槿绻@個(gè)工具價(jià)值未被證實(shí)但又對(duì)性能有影響的話锯厢，你可以理解服務(wù)運(yùn)營(yíng)人員為什么不愿意部署它皮官。況且，我們想讓開(kāi)發(fā)人員使用Annotation的API实辑，而不用擔(dān)心額外的開(kāi)銷捺氢。我們還發(fā)現(xiàn)，某些類型的Web服務(wù)對(duì)植入帶來(lái)的性能損耗確實(shí)非常敏感剪撬。因此摄乒，除了把Dapper的收集工作對(duì)基本組件的性能損耗限制的盡可能小之外，我們還有進(jìn)一步控制損耗的辦法残黑，那就是遇到大量請(qǐng)求時(shí)只記錄其中的一小部分馍佑。我們將在4.4節(jié)中討論跟蹤的采樣率方案的更多細(xì)節(jié)。

2.5 跟蹤的收集

Dapper的跟蹤記錄和收集管道的過(guò)程分為三個(gè)階段（參見(jiàn)圖5）梨水。首先拭荤，span數(shù)據(jù)寫(xiě)入（1）本地日志文件中。然后Dapper的守護(hù)進(jìn)程和收集組件把這些數(shù)據(jù)從生產(chǎn)環(huán)境的主機(jī)中拉出來(lái)（2）疫诽，最終寫(xiě)到（3）Dapper的Bigtable倉(cāng)庫(kù)中舅世。一次跟蹤被設(shè)計(jì)成Bigtable中的一行旦委，每一列相當(dāng)于一個(gè)span。Bigtable的支持稀疏表格布局正適合這種情況雏亚，因?yàn)槊恳淮胃櫩梢杂腥我舛鄠€(gè)span缨硝。跟蹤數(shù)據(jù)收集（即從應(yīng)用中的二進(jìn)制數(shù)據(jù)傳輸?shù)街醒雮}(cāng)庫(kù)所花費(fèi)的時(shí)間）的延遲中位數(shù)少于15秒。第98百分位的延遲(The 98th percentile latency)往往隨著時(shí)間的推移呈現(xiàn)雙峰型;大約75%的時(shí)間罢低，第98百分位的延遲時(shí)間小于2分鐘查辩，但是另外大約25%的時(shí)間，它可以增漲到幾個(gè)小時(shí)网持。

Dapper還提供了一個(gè)API來(lái)簡(jiǎn)化訪問(wèn)我們倉(cāng)庫(kù)中的跟蹤數(shù)據(jù)宜岛。 Google的開(kāi)發(fā)人員用這個(gè)API，以構(gòu)建通用和特定應(yīng)用程序的分析工具翎碑。第5.1節(jié)包含更多如何使用它的信息。

2.5.1 帶外數(shù)據(jù)跟蹤收集

tip1:帶外數(shù)據(jù):傳輸層協(xié)議使用帶外數(shù)據(jù)(out-of-band之斯，OOB)來(lái)發(fā)送一些重要的數(shù)據(jù),如果通信一方有重要的數(shù)據(jù)需要通知對(duì)方時(shí),協(xié)議能夠?qū)⑦@些數(shù)據(jù)快速地發(fā)送到對(duì)方日杈。為了發(fā)送這些數(shù)據(jù)，協(xié)議一般不使用與普通數(shù)據(jù)相同的通道,而是使用另外的通道佑刷。

tip2:這里指的in-band策略是把跟蹤數(shù)據(jù)隨著調(diào)用鏈進(jìn)行傳送莉擒，out-of-band是通過(guò)其他的鏈路進(jìn)行跟蹤數(shù)據(jù)的收集，Dapper的寫(xiě)日志然后進(jìn)行日志采集的方式就屬于out-of-band策略

Dapper系統(tǒng)請(qǐng)求樹(shù)樹(shù)自身進(jìn)行跟蹤記錄和收集帶外數(shù)據(jù)瘫絮。這樣做是為兩個(gè)不相關(guān)的原因涨冀。首先，帶內(nèi)收集方案--這里跟蹤數(shù)據(jù)會(huì)以RPC響應(yīng)頭的形式被返回--會(huì)影響應(yīng)用程序網(wǎng)絡(luò)動(dòng)態(tài)麦萤。在Google里的許多規(guī)模較大的系統(tǒng)中鹿鳖，一次跟蹤成千上萬(wàn)的span并不少見(jiàn)。然而壮莹，RPC回應(yīng)大小--甚至是接近大型分布式的跟蹤的根節(jié)點(diǎn)的這種情況下-- 仍然是比較小的：通常小于10K翅帜。在這種情況下，帶內(nèi)Dapper的跟蹤數(shù)據(jù)會(huì)讓?xiě)?yīng)用程序數(shù)據(jù)和傾向于使用后續(xù)分析結(jié)果的數(shù)據(jù)量相形見(jiàn)絀命满。其次涝滴，帶內(nèi)收集方案假定所有的RPC是完美嵌套的。我們發(fā)現(xiàn)胶台，在所有的后端的系統(tǒng)返回的最終結(jié)果之前歼疮，有許多中間件會(huì)把結(jié)果返回給他們的調(diào)用者。帶內(nèi)收集系統(tǒng)是無(wú)法解釋這種非嵌套的分布式執(zhí)行模式的诈唬。

2.6 安全和隱私考慮

記錄一定量的RPC有效負(fù)載信息將豐富Dapper的跟蹤能力韩脏，因?yàn)榉治龉ぞ吣軌蛟谟行лd荷數(shù)據(jù)（方法傳遞的參數(shù)）中找到相關(guān)的樣例，這些樣例可以解釋被監(jiān)控系統(tǒng)的為何表現(xiàn)異常铸磅。然而骤素，有些情況下匙睹，有效載荷數(shù)據(jù)可能包含的一些不應(yīng)該透露給未經(jīng)授權(quán)用戶(包括正在debug的工程師)的內(nèi)部信息。

由于安全和隱私問(wèn)題是不可忽略的济竹，dapper中的雖然存儲(chǔ)RPC方法的名稱痕檬，但在這個(gè)時(shí)候不記錄任何有效載荷數(shù)據(jù)。相反送浊，應(yīng)用程序級(jí)別的Annotation提供了一個(gè)方便的可選機(jī)制：應(yīng)用程序開(kāi)發(fā)人員可以在span中選擇關(guān)聯(lián)那些為以后分析提供價(jià)值的數(shù)據(jù)梦谜。

Dapper還提供了一些安全上的便利，是它的設(shè)計(jì)者事先沒(méi)有預(yù)料到的袭景。通過(guò)跟蹤公開(kāi)的安全協(xié)議參數(shù)唁桩，Dapper可以通過(guò)相應(yīng)級(jí)別的認(rèn)證或加密，來(lái)監(jiān)視應(yīng)用程序是否滿足安全策略耸棒。例如荒澡。Dapper還可以提供信息，以基于策略的的隔離系統(tǒng)按預(yù)期執(zhí)行与殃，例如支撐敏感數(shù)據(jù)的應(yīng)用程序不與未經(jīng)授權(quán)的系統(tǒng)組件進(jìn)行了交互单山。這樣的測(cè)算提供了比源碼審核更強(qiáng)大的保障。

3. Dapper部署狀況

Dapper作為我們生產(chǎn)環(huán)境下的跟蹤系統(tǒng)已經(jīng)超過(guò)兩年幅疼。在本節(jié)中米奸，我們會(huì)匯報(bào)系統(tǒng)狀態(tài)，把重點(diǎn)放在Dapper如何滿足了我們的目標(biāo)——無(wú)處不在的部署和應(yīng)用級(jí)的透明爽篷。

3.1 Dapper運(yùn)行庫(kù)

也許Dapper代碼中中最關(guān)鍵的部分悴晰，就是對(duì)基礎(chǔ)RPC、線程控制和流程控制的組件庫(kù)的植入逐工，其中包括span的創(chuàng)建铡溪，采樣率的設(shè)置，以及把日志寫(xiě)入本地磁盤(pán)泪喊。除了做到輕量級(jí)佃却，植入的代碼更需要穩(wěn)定和健壯，因?yàn)樗c海量的應(yīng)用對(duì)接窘俺，維護(hù)和bug修復(fù)變得困難饲帅。植入的核心代碼是由未超過(guò)1000行的C++和不超過(guò)800行Java代碼組成。為了支持鍵值對(duì)的Annotation還添加了額外的500行代碼瘤泪。

3.2 生產(chǎn)環(huán)境下的涵蓋面

Dapper的滲透可以總結(jié)為兩個(gè)方面：一方面是可以創(chuàng)建Dapper跟蹤的過(guò)程(與Dapper植入的組件庫(kù)相關(guān))灶泵，和生產(chǎn)環(huán)境下的服務(wù)器上在運(yùn)行Dapper跟蹤收集守護(hù)進(jìn)程。Dapper的守護(hù)進(jìn)程的分布相當(dāng)于我們服務(wù)器的簡(jiǎn)單的拓?fù)鋱D对途，它存在于Google幾乎所有的服務(wù)器上赦邻。這很難確定精確的Dapper-ready進(jìn)程部分，因?yàn)檫^(guò)程即便不產(chǎn)生跟蹤信息Dapper也是無(wú)從知曉的实檀。盡管如此惶洲，考慮到無(wú)處不在Dapper組件的植入庫(kù)按声，我們估計(jì)幾乎每一個(gè)Google的生產(chǎn)進(jìn)程都是支持跟蹤的。

在某些情況下Dapper的是不能正確的跟蹤控制路徑的恬吕。這些通常源于使用非標(biāo)準(zhǔn)的控制流签则，或是Dapper的錯(cuò)誤的把路徑關(guān)聯(lián)歸到不相關(guān)的事件上。Dapper提供了一個(gè)簡(jiǎn)單的庫(kù)來(lái)幫助開(kāi)發(fā)者手動(dòng)控制跟蹤傳播作為一種變通方法铐料。目前有40個(gè)C++應(yīng)用程序和33個(gè)Java應(yīng)用程序需要一些手動(dòng)控制的追蹤傳播渐裂，不過(guò)這只是上千個(gè)的跟蹤中的一小部分。也有非常小的一部分程序使用的非組件性質(zhì)的通信庫(kù)（比如原生的TCP Socket或SOAP RPC）钠惩，因此不能直接支持Dapper的跟蹤柒凉。但是這些應(yīng)用可以單獨(dú)接入到Dapper中，如果需要的話篓跛。

考慮到生產(chǎn)環(huán)境的安全膝捞，Dapper的跟蹤也可以關(guān)閉。事實(shí)上愧沟，它在部署的早起就是默認(rèn)關(guān)閉的蔬咬，直到我們對(duì)Dapper的穩(wěn)定性和低損耗有了足夠的信心之后才把它開(kāi)啟。Dapper的團(tuán)隊(duì)偶爾會(huì)執(zhí)行審查尋找跟蹤配置的變化央渣，來(lái)看看那些服務(wù)關(guān)閉了Dapper的跟蹤计盒。但這種情況不多見(jiàn)渴频，而且通常是源于對(duì)監(jiān)控對(duì)性能消耗的擔(dān)憂芽丹。經(jīng)過(guò)了對(duì)實(shí)際性能消耗的進(jìn)一步調(diào)查和測(cè)量，所有這些關(guān)閉Dapper跟蹤都已經(jīng)恢復(fù)開(kāi)啟了卜朗，不過(guò)這些已經(jīng)不重要了拔第。

3.3 跟蹤Annotation的使用

程序員傾向于使用特定應(yīng)用程序的Annotation，無(wú)論是作為一種分布式調(diào)試日志文件场钉，還是通過(guò)一些應(yīng)用程序特定的功能對(duì)跟蹤進(jìn)行分類蚊俺。例如，所有的Bigtable的請(qǐng)求會(huì)把被訪問(wèn)的表名也記錄到Annotation中逛万。目前泳猬，70％的Dapper span和90％的所有Dapper跟蹤都至少有一個(gè)特殊應(yīng)用的Annotation。

41個(gè)Java應(yīng)用和68個(gè)C++應(yīng)用中都添加自定義的Annotation為了更好地理解應(yīng)用程序中的span在他們的服務(wù)中的行為宇植。值得注意的是得封，迄今為止我們的Java開(kāi)發(fā)者比C++開(kāi)發(fā)者更多的在每一個(gè)跟蹤span上采用Annotation的API。這可能是因?yàn)槲覀兊腏ava應(yīng)用的作用域往往是更接近最終用戶(C++偏底層);這些類型的應(yīng)用程序經(jīng)常處理更廣泛的請(qǐng)求組合指郁，因此具有比較復(fù)雜的控制路徑忙上。

4. 處理跟蹤損耗

跟蹤系統(tǒng)的成本由兩部分組成：1.正在被監(jiān)控的系統(tǒng)在生成追蹤和收集追蹤數(shù)據(jù)的消耗導(dǎo)致系統(tǒng)性能下降，2闲坎。需要使用一部分資源來(lái)存儲(chǔ)和分析跟蹤數(shù)據(jù)疫粥。雖然你可以說(shuō)一個(gè)有價(jià)值的組件植入跟蹤帶來(lái)一部分性能損耗是值得的茬斧，我們相信如果基本損耗能達(dá)到可以忽略的程度，那么對(duì)跟蹤系統(tǒng)最初的推廣會(huì)有極大的幫助梗逮。

在本節(jié)中项秉，我們會(huì)展現(xiàn)一下三個(gè)方面：Dapper組件操作的消耗，跟蹤收集的消耗库糠，以及Dapper對(duì)生產(chǎn)環(huán)境負(fù)載的影響伙狐。我們還介紹了Dapper可調(diào)節(jié)的采樣率機(jī)制如何幫我們處理低損耗和跟蹤代表性之間的平衡和取舍。

4.1 生成跟蹤的損耗

生成跟蹤的開(kāi)銷是Dapper性能影響中最關(guān)鍵的部分瞬欧，因?yàn)槭占头治隹梢愿菀自诰o急情況下被關(guān)閉贷屎。Dapper運(yùn)行庫(kù)中最重要的跟蹤生成消耗在于創(chuàng)建和銷毀span和annotation，并記錄到本地磁盤(pán)供后續(xù)的收集艘虎。根span的創(chuàng)建和銷毀需要損耗平均204納秒的時(shí)間唉侄，而同樣的操作在其他span上需要消耗176納秒十绑。時(shí)間上的差別主要在于需要在跟span上給這次跟蹤分配一個(gè)全局唯一的ID崭庸。

如果一個(gè)span沒(méi)有被采樣的話，那么這個(gè)額外的span下創(chuàng)建annotation的成本幾乎可以忽略不計(jì)斤讥，他由在Dapper運(yùn)行期對(duì)ThreadLocal查找操作構(gòu)成候生，這平均只消耗9納秒同眯。如果這個(gè)span被計(jì)入采樣的話，會(huì)用一個(gè)用字符串進(jìn)行標(biāo)注--在圖4中有展現(xiàn)--平均需要消耗40納秒唯鸭。這些數(shù)據(jù)都是在2.2GHz的x86服務(wù)器上采集的须蜗。

在Dapper運(yùn)行期寫(xiě)入到本地磁盤(pán)是最昂貴的操作，但是他們的可見(jiàn)損耗大大減少目溉，因?yàn)閷?xiě)入日志文件和操作相對(duì)于被跟蹤的應(yīng)用系統(tǒng)來(lái)說(shuō)都是異步的明肮。不過(guò)，日志寫(xiě)入的操作如果在大流量的情況缭付，尤其是每一個(gè)請(qǐng)求都被跟蹤的情況下就會(huì)變得可以察覺(jué)到柿估。我們記錄了在4.3節(jié)展示了一次Web搜索的負(fù)載下的性能消耗。

4.2 跟蹤收集的消耗

讀出跟蹤數(shù)據(jù)也會(huì)對(duì)正在被監(jiān)控的負(fù)載產(chǎn)生干擾陷猫。表1展示的是最壞情況下秫舌，Dapper收集日志的守護(hù)進(jìn)程在高于實(shí)際情況的負(fù)載基準(zhǔn)下進(jìn)行測(cè)試時(shí)的cpu使用率。在生產(chǎn)環(huán)境下绣檬，跟蹤數(shù)據(jù)處理中足陨，這個(gè)守護(hù)進(jìn)程從來(lái)沒(méi)有超過(guò)0.3%的單核cpu使用率，而且只有很少量的內(nèi)存使用（以及堆碎片的噪音）河咽。我們還限制了Dapper守護(hù)進(jìn)程為內(nèi)核scheduler最低的優(yōu)先級(jí)钠右，以防在一臺(tái)高負(fù)載的服務(wù)器上發(fā)生cpu競(jìng)爭(zhēng)。

Dapper也是一個(gè)帶寬資源的輕量級(jí)的消費(fèi)者忘蟹，每一個(gè)span在我們的倉(cāng)庫(kù)中傳輸只占用了平均426的byte飒房。作為網(wǎng)絡(luò)行為中的極小部分搁凸，Dapper的數(shù)據(jù)收集在Google的生產(chǎn)環(huán)境中的只占用了0.01%的網(wǎng)絡(luò)資源。

4.3 在生產(chǎn)環(huán)境下對(duì)負(fù)載的影響

每個(gè)請(qǐng)求都會(huì)利用到大量的服務(wù)器的高吞吐量的線上服務(wù)狠毯，這是對(duì)有效跟蹤最主要的需求之一护糖；這種情況需要生成大量的跟蹤數(shù)據(jù)，并且他們對(duì)性能的影響是最敏感的嚼松。在表2中我們用集群下的網(wǎng)絡(luò)搜索服務(wù)作為例子嫡良，我們通過(guò)調(diào)整采樣率，來(lái)衡量Dapper在延遲和吞吐量方面對(duì)性能的影響献酗。

我們看到寝受，雖然對(duì)吞吐量的影響不是很明顯，但為了避免明顯的延遲罕偎，跟蹤的采樣還是必要的很澄。然而，延遲和吞吐量的帶來(lái)的損失在把采樣率調(diào)整到小于1/16之后就全部在實(shí)驗(yàn)誤差范圍內(nèi)颜及。在實(shí)踐中甩苛，我們發(fā)現(xiàn)即便采樣率調(diào)整到1/1024仍然是有足夠量的跟蹤數(shù)據(jù)的用來(lái)跟蹤大量的服務(wù)。保持Dapper的性能損耗基線在一個(gè)非常低的水平是很重要的俏站，因?yàn)樗鼮槟切?yīng)用提供了一個(gè)寬松的環(huán)境使用完整的Annotation API而無(wú)懼性能損失讯蒲。使用較低的采樣率還有額外的好處，可以讓持久化到硬盤(pán)中的跟蹤數(shù)據(jù)在垃圾回收機(jī)制處理之前保留更長(zhǎng)的時(shí)間肄扎，這樣為Dapper的收集組件給了更多的靈活性墨林。

4.4 可變采樣

任何給定進(jìn)程的Dapper的消耗和每個(gè)進(jìn)程單位時(shí)間的跟蹤的采樣率成正比。Dapper的第一個(gè)生產(chǎn)版本在Google內(nèi)部的所有進(jìn)程上使用統(tǒng)一的采樣率反浓，為1/1024萌丈。這個(gè)簡(jiǎn)單的方案是對(duì)我們的高吞吐量的線上服務(wù)來(lái)說(shuō)是非常有用赞哗，因?yàn)槟切└信d趣的事件(在大吞吐量的情況下)仍然很有可能經(jīng)常出現(xiàn)雷则，并且通常足以被捕捉到。

然而肪笋，在較低的采樣率和較低的傳輸負(fù)載下可能會(huì)導(dǎo)致錯(cuò)過(guò)重要事件月劈，而想用較高的采樣率就需要能接受的性能損耗。對(duì)于這樣的系統(tǒng)的解決方案就是覆蓋默認(rèn)的采樣率藤乙，這需要手動(dòng)干預(yù)的猜揪，這種情況是我們?cè)噲D避免在dapper中出現(xiàn)的。

我們?cè)诓渴鹂勺儾蓸拥倪^(guò)程中坛梁，參數(shù)化配置采樣率時(shí)而姐，不是使用一個(gè)統(tǒng)一的采樣方案，而是使用一個(gè)采樣期望率來(lái)標(biāo)識(shí)單位時(shí)間內(nèi)采樣的追蹤划咐。這樣一來(lái)拴念，低流量低負(fù)載自動(dòng)提高采樣率钧萍，而在高流量高負(fù)載的情況下會(huì)降低采樣率，使損耗一直保持在控制之下政鼠。實(shí)際使用的采樣率會(huì)隨著跟蹤本身記錄下來(lái)风瘦，這有利于從Dapper的跟蹤數(shù)據(jù)中準(zhǔn)確的分析。

4.5 應(yīng)對(duì)積極采樣(Coping with aggressive sampling)

新的Dapper用戶往往覺(jué)得低采樣率--在高吞吐量的服務(wù)下經(jīng)常低至0.01％--將會(huì)不利于他們的分析公般。我們?cè)贕oogle的經(jīng)驗(yàn)使我們相信万搔，對(duì)于高吞吐量服務(wù)，積極采樣(aggressive sampling)并不妨礙最重要的分析官帘。如果一個(gè)顯著的操作在系統(tǒng)中出現(xiàn)一次瞬雹，他就會(huì)出現(xiàn)上千次。低吞吐量的服務(wù)--也許是每秒請(qǐng)求幾十次刽虹，而不是幾十萬(wàn)--可以負(fù)擔(dān)得起跟蹤每一個(gè)請(qǐng)求挖炬，這是促使我們下決心使用自適應(yīng)采樣率的原因。

4.6 在收集過(guò)程中額外的采樣

上述采樣機(jī)制被設(shè)計(jì)為盡量減少與Dapper運(yùn)行庫(kù)協(xié)作的應(yīng)用程序中明顯的性能損耗状婶。Dapper的團(tuán)隊(duì)還需要控制寫(xiě)入中央資料庫(kù)的數(shù)據(jù)的總規(guī)模意敛，因此為達(dá)到這個(gè)目的，我們結(jié)合了二級(jí)采樣膛虫。

目前我們的生產(chǎn)集群每天產(chǎn)生超過(guò)1TB的采樣跟蹤數(shù)據(jù)草姻。Dapper的用戶希望生產(chǎn)環(huán)境下的進(jìn)程的跟蹤數(shù)據(jù)從被記錄之后能保存至少兩周的時(shí)間。逐漸增長(zhǎng)的追蹤數(shù)據(jù)的密度必須和Dapper中央倉(cāng)庫(kù)所消耗的服務(wù)器及硬盤(pán)存儲(chǔ)進(jìn)行權(quán)衡稍刀。對(duì)請(qǐng)求的高采樣率還使得Dapper收集器接近寫(xiě)入吞吐量的上限撩独。

為了維持物質(zhì)資源的需求和漸增的Bigtable的吞吐之間的靈活性，我們?cè)谑占到y(tǒng)自身上增加了額外的采樣率的支持账月。我們充分利用所有span都來(lái)自一個(gè)特定的跟蹤并分享同一個(gè)跟蹤ID這個(gè)事實(shí)综膀，雖然這些span有可能橫跨了數(shù)千個(gè)主機(jī)。對(duì)于在收集系統(tǒng)中的每一個(gè)span局齿，我們用hash算法把跟蹤ID轉(zhuǎn)成一個(gè)標(biāo)量Z剧劝，這里0<=Z<=1。如果Z比我們收集系統(tǒng)中的系數(shù)低的話抓歼，我們就保留這個(gè)span信息讥此，并寫(xiě)入到Bigtable中。反之谣妻，我們就拋棄他萄喳。通過(guò)在采樣決策中的跟蹤ID，我們要么保存蹋半、要么拋棄整個(gè)跟蹤他巨，而不是單獨(dú)處理跟蹤內(nèi)的span。我們發(fā)現(xiàn)，有了這個(gè)額外的配置參數(shù)使管理我們的收集管道變得簡(jiǎn)單多了染突，因?yàn)槲覀兛梢院苋菀椎卦谂渲梦募姓{(diào)整我們的全局寫(xiě)入率這個(gè)參數(shù)匪傍。

如果整個(gè)跟蹤過(guò)程和收集系統(tǒng)只使用一個(gè)采樣率參數(shù)確實(shí)會(huì)簡(jiǎn)單一些，但是這就不能應(yīng)對(duì)快速調(diào)整在所有部署的節(jié)點(diǎn)上的運(yùn)行期采樣率配置的這個(gè)要求觉痛。我們選擇了運(yùn)行期采樣率役衡，這樣就可以優(yōu)雅的去掉我們無(wú)法寫(xiě)入到倉(cāng)庫(kù)中的多余數(shù)據(jù)，我們還可以通過(guò)調(diào)節(jié)收集系統(tǒng)中的二級(jí)采樣率系數(shù)來(lái)調(diào)整這個(gè)運(yùn)行期采樣率薪棒。Dapper的管道維護(hù)變得更容易手蝎，因?yàn)槲覀兙涂梢酝ㄟ^(guò)修改我們的二級(jí)采樣率的配置，直接增加或減少我們的全局覆蓋率和寫(xiě)入速度俐芯。

5. 通用的Dapper工具

幾年前棵介，當(dāng)Dapper還只是個(gè)原型的時(shí)候，它只能在Dapper開(kāi)發(fā)者耐心的支持下使用吧史。從那時(shí)起邮辽，我們逐漸迭代的建立了收集組件，編程接口贸营，和基于Web的交互式用戶界面吨述，幫助Dapper的用戶獨(dú)立解決自己的問(wèn)題。在本節(jié)中钞脂，我們會(huì)總結(jié)一下哪些的方法有用揣云，哪些用處不大，我們還提供關(guān)于這些通用的分析工具的基本的使用信息冰啃。

5.1 Dapper Depot API

Dapper的“Depot API”或稱作DAPI邓夕，提供在Dapper的區(qū)域倉(cāng)庫(kù)中對(duì)分布式跟蹤數(shù)據(jù)一個(gè)直接訪問(wèn)。DAPI和Dapper跟蹤倉(cāng)庫(kù)被設(shè)計(jì)成串聯(lián)的阎毅，而且DAPI意味著對(duì)Dapper倉(cāng)庫(kù)中的元數(shù)據(jù)暴露一個(gè)干凈和直觀的的接口焚刚。我們使用了以下推薦的三種方式去暴露這樣的接口：

通過(guò)跟蹤ID來(lái)訪問(wèn)：DAPI可以通過(guò)他的全局唯一的跟蹤ID讀取任何一次跟蹤信息。

批量訪問(wèn)：DAPI可以利用的MapReduce提供對(duì)上億條Dapper跟蹤數(shù)據(jù)的并行讀取扇调。用戶重寫(xiě)一個(gè)虛擬函數(shù)矿咕，它接受一個(gè)Dapper的跟蹤信息作為其唯一的參數(shù)，該框架將在用戶指定的時(shí)間窗口中調(diào)用每一次收集到的跟蹤信息肃拜。

索引訪問(wèn)：Dapper的倉(cāng)庫(kù)支持一個(gè)符合我們通用調(diào)用模板的唯一索引痴腌。該索引根據(jù)通用請(qǐng)求跟蹤特性(commonly-requested trace features)進(jìn)行繪制來(lái)識(shí)別Dapper的跟蹤信息雌团。因?yàn)楦橧D是根據(jù)偽隨機(jī)的規(guī)則創(chuàng)建的燃领，這是最好的辦法去訪問(wèn)跟某個(gè)服務(wù)或主機(jī)相關(guān)的跟蹤數(shù)據(jù)。

所有這三種訪問(wèn)模式把用戶指向不同的Dapper跟蹤記錄锦援。正如第2.1節(jié)所述的猛蔽，Dapper的由span組成的跟蹤數(shù)據(jù)是用樹(shù)形結(jié)構(gòu)建模的，因此，跟蹤數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)曼库，也是一個(gè)簡(jiǎn)單的由span組成遍歷樹(shù)区岗。Span就相當(dāng)于RPC調(diào)用，在這種情況下毁枯，RPC的時(shí)間信息是可用的慈缔。帶時(shí)間戳的特殊的應(yīng)用標(biāo)注也是可以通過(guò)這個(gè)span結(jié)構(gòu)來(lái)訪問(wèn)的。

選擇一個(gè)合適的自定義索引是DAPI設(shè)計(jì)中最具挑戰(zhàn)性的部分种玛。壓縮存儲(chǔ)要求在跟蹤數(shù)據(jù)種建立一個(gè)索引的情況只比實(shí)際數(shù)據(jù)小26%藐鹤，所以消耗是巨大的。最初赂韵，我們部署了兩個(gè)索引：第一個(gè)是主機(jī)索引娱节，另一個(gè)是服務(wù)名的索引。然而祭示，我們并沒(méi)有找到主機(jī)索引和存儲(chǔ)成本之間的利害關(guān)系肄满。當(dāng)用戶對(duì)每一臺(tái)主機(jī)感興趣的時(shí)候，他們也會(huì)對(duì)特定的服務(wù)感興趣质涛，所以我們最終選擇把兩者相結(jié)合稠歉，成為一個(gè)組合索引，它允許以服務(wù)名稱汇陆，主機(jī)轧抗，和時(shí)間戳的順序進(jìn)行有效的查找。

5.1.1 DAPI在Google內(nèi)部的使用

DAPI在谷歌的使用有三類：使利用DAPI的持續(xù)的線上Web應(yīng)用瞬测，維護(hù)良好的可以在控制臺(tái)上調(diào)用的基于DAPI的工具横媚，可以被寫(xiě)入，運(yùn)行月趟、不過(guò)大部分已經(jīng)被忘記了的一次性分析工具灯蝴。我們知道的有3個(gè)持久性的基于DAPI的應(yīng)用程序，8個(gè)額外的按需定制的基于DAPI分析工具孝宗，以及使用DAPI框架構(gòu)建的約15~20一次性的分析工具穷躁。在這之后的工具就這是很難說(shuō)明了，因?yàn)殚_(kāi)發(fā)者可以構(gòu)建因妇、運(yùn)行和丟棄這些項(xiàng)目问潭，而不需要Dapper團(tuán)隊(duì)的技術(shù)支持。

5.2 Dapper的用戶接口

絕大多數(shù)用戶使用發(fā)生在基于web的用戶交互接口婚被。篇幅有限狡忙，我們不能列出每一個(gè)特點(diǎn)，而只能把典型的用戶工作流在圖6中展示址芯。

用戶描述的他們關(guān)心的服務(wù)和時(shí)間灾茁，和其他任何他們可以用來(lái)區(qū)分跟蹤模板的信息（比如窜觉，span的名稱）。他們還可以指定與他們的搜索最相關(guān)的成本度量(cost metric)(比如北专，服務(wù)響應(yīng)時(shí)間)禀挫。

一個(gè)關(guān)于性能概要的大表格，對(duì)應(yīng)確定的服務(wù)關(guān)聯(lián)的所有分布式處理圖表拓颓。用戶可以把這些執(zhí)行圖標(biāo)排序成他們想要的语婴，并選擇一種直方圖去展現(xiàn)出更多的細(xì)節(jié)。

一旦某個(gè)單一的分布式執(zhí)行部分被選中后驶睦，用戶能看到關(guān)于執(zhí)行部分的的圖形化描述腻格。被選中的服務(wù)被高亮展示在該圖的中心。

在生成與步驟1中選中的成本度量(cost metric)維度相關(guān)的統(tǒng)計(jì)信息之后啥繁，Dapper的用戶界面會(huì)提供了一個(gè)簡(jiǎn)單的直方圖菜职。在這個(gè)例子中，我們可以看到一個(gè)大致的所選中部分的分布式響應(yīng)時(shí)間分布圖旗闽。用戶還會(huì)看到一個(gè)關(guān)于具體的跟蹤信息的列表酬核，展現(xiàn)跟蹤信息在直方圖中被劃分為的不同區(qū)域。在這個(gè)例子中适室，用戶點(diǎn)擊列表種第二個(gè)跟蹤信息實(shí)例時(shí)嫡意，會(huì)在下方看到這個(gè)跟蹤信息的詳細(xì)視圖(步驟5)。

絕大多數(shù)Dapper的使用者最終的會(huì)檢查某個(gè)跟蹤的情況捣辆，希望能收集一些信息去了解系統(tǒng)行為的根源所在蔬螟。我們沒(méi)有足夠的空間來(lái)做跟蹤視圖的審查，但我們使用由一個(gè)全局時(shí)間軸（在上方可以看到）汽畴，并能夠展開(kāi)和折疊樹(shù)形結(jié)構(gòu)的交互方式旧巾，這也很有特點(diǎn)。分布式跟蹤樹(shù)的連續(xù)層用內(nèi)嵌的不同顏色的矩形表示忍些。每一個(gè)RPC的span被從時(shí)間上分解為一個(gè)服務(wù)器進(jìn)程中的消耗（綠色部分）和在網(wǎng)絡(luò)上的消耗（藍(lán)色部分）鲁猩。用戶Annotation沒(méi)有顯示在這個(gè)截圖中，但他們可以選擇性的以span的形式包含在全局時(shí)間軸上罢坝。

為了讓用戶查詢實(shí)時(shí)數(shù)據(jù)廓握，Dapper的用戶界面能夠直接與Dapper每一臺(tái)生產(chǎn)環(huán)境下的服務(wù)器上的守護(hù)進(jìn)程進(jìn)行交互。在該模式下嘁酿，不可能指望能看到上面所說(shuō)的系統(tǒng)級(jí)的圖表展示隙券，但仍然可以很容易基于性能和網(wǎng)絡(luò)特性選取一個(gè)特定的跟蹤。在這種模式下闹司，可在幾秒鐘內(nèi)查到實(shí)時(shí)的數(shù)據(jù)娱仔。

根據(jù)我們的記錄，大約有200個(gè)不同的Google工程師在一天內(nèi)使用的Dapper的UI;在一周的過(guò)程中开仰，大約有750-1000不同的用戶拟枚。這些用戶數(shù)薪铜，在新功能的內(nèi)部通告上众弓，是按月連續(xù)的恩溅。通常用戶會(huì)發(fā)送特定跟蹤的連接，這將不可避免地在查詢跟蹤情況時(shí)中產(chǎn)生很多一次性的谓娃，持續(xù)時(shí)間較短的交互脚乡。

6. 經(jīng)驗(yàn)

Dapper在Google被廣泛應(yīng)用，一部分直接通過(guò)Dapper的用戶界面滨达，另一部分間接地通過(guò)對(duì)Dapper API的二次開(kāi)發(fā)或者建立在基于api的應(yīng)用上奶稠。在本節(jié)中，我們并不打算羅列出每一種已知的Dapper使用方式捡遍，而是試圖覆蓋Dapper使用方式的“基本向量”锌订，并努力來(lái)說(shuō)明什么樣的應(yīng)用是最成功的。

6.1 在開(kāi)發(fā)中使用Dapper

Google AdWords系統(tǒng)是圍繞一個(gè)大型的關(guān)鍵詞定位準(zhǔn)則和相關(guān)文字廣告的數(shù)據(jù)庫(kù)搭建的画株。當(dāng)新的關(guān)鍵字或廣告被插入或修改時(shí)辆飘，它們必須通過(guò)服務(wù)策略術(shù)語(yǔ)的檢查（如檢查不恰當(dāng)?shù)恼Z(yǔ)言，這個(gè)過(guò)程如果使用自動(dòng)復(fù)查系統(tǒng)來(lái)做的話會(huì)更加有效）谓传。

當(dāng)輪到從頭重新設(shè)計(jì)一個(gè)廣告審查服務(wù)時(shí)蜈项，這個(gè)團(tuán)隊(duì)迭代的從第一個(gè)系統(tǒng)原型開(kāi)始使用Dapper，并且续挟，最終用Dapper一直維護(hù)著他們的系統(tǒng)紧卒。Dapper幫助他們從以下幾個(gè)方面改進(jìn)了他們的服務(wù)：

性能：開(kāi)發(fā)人員針對(duì)請(qǐng)求延遲的目標(biāo)進(jìn)行跟蹤，并對(duì)容易優(yōu)化的地方進(jìn)行定位诗祸。Dapper也被用來(lái)確定在關(guān)鍵路徑上不必要的串行請(qǐng)求--通常來(lái)源于不是開(kāi)發(fā)者自己開(kāi)發(fā)的子系統(tǒng)--并促使團(tuán)隊(duì)持續(xù)修復(fù)他們跑芳。

正確性：廣告審查服務(wù)圍繞大型數(shù)據(jù)庫(kù)系統(tǒng)搭建。系統(tǒng)同時(shí)具有只讀副本策略（數(shù)據(jù)訪問(wèn)廉價(jià)）和讀寫(xiě)的主策略（訪問(wèn)代價(jià)高）直颅。Dapper被用來(lái)在很多種情況中確定聋亡，哪些查詢是無(wú)需通過(guò)主策略訪問(wèn)而可以采用副本策略訪問(wèn)。Dapper現(xiàn)在可以負(fù)責(zé)監(jiān)控哪些主策略被直接訪問(wèn)际乘，并對(duì)重要的系統(tǒng)常量進(jìn)行保障坡倔。

理解性：廣告審查查詢跨越了各種類型的系統(tǒng)，包括BigTable—之前提到的那個(gè)數(shù)據(jù)庫(kù)脖含，多維索引服務(wù)罪塔，以及其他各種C++和Java后端服務(wù)。Dapper的跟蹤用來(lái)評(píng)估總查詢成本养葵，促進(jìn)重新對(duì)業(yè)務(wù)的設(shè)計(jì)征堪，用以在他們的系統(tǒng)依賴上減少負(fù)載。

測(cè)試：新的代碼版本會(huì)經(jīng)過(guò)一個(gè)使用Dapper進(jìn)行跟蹤的QA過(guò)程关拒，用來(lái)驗(yàn)證正確的系統(tǒng)行為和性能佃蚜。在跑測(cè)試的過(guò)程中能發(fā)現(xiàn)很多問(wèn)題庸娱，這些問(wèn)題來(lái)自廣告審查系統(tǒng)自身的代碼或是他的依賴包。

廣告審查團(tuán)隊(duì)廣泛使用了Dapper Annotation API谐算。Guice13開(kāi)源的AOP框架用來(lái)在重要的軟件組件上標(biāo)注“@Traced”熟尉。這些跟蹤信息可以進(jìn)一步被標(biāo)注，包含：重要子路徑的輸入輸出大小洲脂、基礎(chǔ)信息斤儿、其他調(diào)試信息，所有這些信息將會(huì)額外發(fā)送到日志文件中恐锦。

同時(shí)往果，我們也發(fā)現(xiàn)了一些廣告審查小組在使用方面的不足。比如：他們想根據(jù)他們所有跟蹤的Annotation信息一铅，在一個(gè)交互時(shí)間段內(nèi)進(jìn)行搜索陕贮，然而這就必須跑一個(gè)自定義的MapReduce或進(jìn)行每一個(gè)跟蹤的手動(dòng)檢查。另外潘飘，在Google還有一些其他的系統(tǒng)在也從通用調(diào)試日志中收集和集中信息肮之，把那些系統(tǒng)的海量數(shù)據(jù)和Dapper倉(cāng)庫(kù)整合也是有價(jià)值的。

總的來(lái)說(shuō)福也，即便如此局骤，廣告審查團(tuán)隊(duì)仍然對(duì)Dapper的作用進(jìn)行了以下評(píng)估，通過(guò)使用Dapper的跟蹤平臺(tái)的數(shù)據(jù)分析暴凑，他們的服務(wù)延遲性已經(jīng)優(yōu)化了兩個(gè)數(shù)量級(jí)峦甩。

6.1.1 與異常監(jiān)控的集成

Google維護(hù)了一個(gè)從運(yùn)行進(jìn)程中不斷收集并集中異常信息報(bào)告的服務(wù)。如果這些異常發(fā)生在Dapper跟蹤采樣的上下文中现喳，那么相應(yīng)的跟蹤ID和span的ID也會(huì)作為元數(shù)據(jù)記錄在異常報(bào)告中凯傲。異常監(jiān)測(cè)服務(wù)的前端會(huì)提供一個(gè)鏈接，從特定的異常信息的報(bào)告直接導(dǎo)向到他們各自的分布式跟蹤嗦篱。廣告審查團(tuán)隊(duì)使用這個(gè)功能可以了解bug發(fā)生的更大范圍的上下文冰单。通過(guò)暴露基于簡(jiǎn)單的唯一ID構(gòu)建的接口，Dapper平臺(tái)被集成到其他事件監(jiān)測(cè)系統(tǒng)會(huì)相對(duì)容易灸促。

6.2 解決延遲的長(zhǎng)尾效應(yīng)

考慮到移動(dòng)部件的數(shù)量诫欠、代碼庫(kù)的規(guī)模、部署的范圍浴栽，調(diào)試一個(gè)像全文搜索那樣服務(wù)（第1節(jié)里提到過(guò)）是非常具有挑戰(zhàn)性的荒叼。在這節(jié)，我們描述了我們?cè)跍p輕全文搜索的延遲分布的長(zhǎng)尾效應(yīng)上做的各種努力典鸡。Dapper能夠驗(yàn)證端到端的延遲的假設(shè)被廓，更具體地說(shuō)，Dapper能夠驗(yàn)證對(duì)于搜索請(qǐng)求的關(guān)鍵路徑萝玷。當(dāng)一個(gè)系統(tǒng)不僅涉及數(shù)個(gè)子系統(tǒng)嫁乘，而是幾十個(gè)開(kāi)發(fā)團(tuán)隊(duì)的涉及到的系統(tǒng)的情況下昆婿，端到端性能較差的根本原因到底在哪，這個(gè)問(wèn)題即使是我們最好的和最有經(jīng)驗(yàn)的工程師也無(wú)法正確回答蜓斧。在這種情況下仓蛆，Dapper可以提供急需的數(shù)據(jù)，而且可以對(duì)許多重要的性能問(wèn)題得出結(jié)論法精。

在調(diào)試延遲長(zhǎng)尾效應(yīng)的過(guò)程中多律，工程師可以建立一個(gè)小型庫(kù)痴突，這個(gè)小型庫(kù)可以根據(jù)DAPI跟蹤對(duì)象來(lái)推斷關(guān)鍵路徑的層級(jí)結(jié)構(gòu)搂蜓。這些關(guān)鍵路徑的結(jié)構(gòu)可以被用來(lái)診斷問(wèn)題，并且為全文搜索提供可優(yōu)先處理的預(yù)期的性能改進(jìn)辽装。Dapper的這項(xiàng)工作導(dǎo)致了下列發(fā)現(xiàn)：

在關(guān)鍵路徑上的短暫的網(wǎng)絡(luò)性能退化不影響系統(tǒng)的吞吐量帮碰，但它可能會(huì)對(duì)延遲異常值產(chǎn)生極大的影響。在圖7中可以看出拾积，大部分的全局搜索的緩慢的跟蹤都來(lái)源于關(guān)鍵路徑的網(wǎng)絡(luò)性能退化殉挽。

許多問(wèn)題和代價(jià)很高的查詢模式來(lái)源于一些意想不到的服務(wù)之間的交互。一旦發(fā)現(xiàn)拓巧，往往容易糾正它們斯碌，但是Dapper出現(xiàn)之前想找出這些問(wèn)題是相當(dāng)困難的。

通用的查詢從Dapper之外的安全日志倉(cāng)庫(kù)中收取肛度，并使用Dapper唯一的跟蹤ID傻唾，與Dapper的倉(cāng)庫(kù)做關(guān)聯(lián)。然后承耿，該映射用來(lái)建立關(guān)于在全局搜索中的每一個(gè)獨(dú)立子系統(tǒng)都很慢的實(shí)例查詢的列表冠骄。

6.3 推斷服務(wù)依賴

在任何給定的時(shí)間內(nèi)，Google內(nèi)部的一個(gè)典型的計(jì)算集群是一個(gè)匯集了成千上萬(wàn)個(gè)邏輯“任務(wù)”的主機(jī)加袋，一套的處理器在執(zhí)行一個(gè)通用的方法凛辣。Google維護(hù)著許多這樣的集群，當(dāng)然职烧，事實(shí)上扁誓，我們發(fā)現(xiàn)在一個(gè)集群上計(jì)算著的這些任務(wù)通常依賴于其他的集群上的任務(wù)。由于任務(wù)們之間的依賴是動(dòng)態(tài)改變的蚀之，所以不可能僅從配置信息上推斷出所有這些服務(wù)之間的依賴關(guān)系蝗敢。不過(guò)，除了其他方面的原因之外恬总，在公司內(nèi)部的各個(gè)流程需要準(zhǔn)確的服務(wù)依賴關(guān)系信息前普，以確定瓶頸所在，以及計(jì)劃服務(wù)的遷移壹堰。Google的可稱為“Service Dependencies”的項(xiàng)目是通過(guò)使用跟蹤Annotation和DAPI MapReduce接口來(lái)實(shí)現(xiàn)自動(dòng)化確定服務(wù)依賴歸屬的拭卿。

Dapper核心組件與Dapper跟蹤Annotation一并使用的情況下骡湖，“Service Dependencies”項(xiàng)目能夠推算出任務(wù)各自之間的依賴，以及任務(wù)和其他軟件組件之間的依賴峻厚。比如响蕴，所有的BigTable的操作會(huì)加上與受影響的表名稱相關(guān)的標(biāo)記。運(yùn)用Dapper的平臺(tái)惠桃，Service Dependencies團(tuán)隊(duì)就可以自動(dòng)的推算出依賴于命名的不同資源的服務(wù)粒度浦夷。

6.4 不同服務(wù)的網(wǎng)絡(luò)使用率

Google投入了大量的人力和物力資源在他的網(wǎng)絡(luò)結(jié)構(gòu)上。從前網(wǎng)絡(luò)管理員可能只關(guān)注獨(dú)立的硬件信息辜王、常用工具及以及搭建出的各種全局網(wǎng)絡(luò)鳥(niǎo)瞰圖的dashboard上的信息劈狐。網(wǎng)絡(luò)管理員確實(shí)可以一覽整個(gè)網(wǎng)絡(luò)的健康狀況，但是呐馆，當(dāng)遇到問(wèn)題時(shí)肥缔，他們很少有能夠準(zhǔn)確查找網(wǎng)絡(luò)負(fù)載的工具，用來(lái)定位應(yīng)用程序級(jí)別的罪魁禍?zhǔn)住?/p>

雖然Dapper不是設(shè)計(jì)用來(lái)做鏈路級(jí)的監(jiān)控的汹来，但是我們發(fā)現(xiàn)续膳，它是非常適合去做集群之間網(wǎng)絡(luò)活動(dòng)性的應(yīng)用級(jí)任務(wù)的分析。Google能夠利用Dapper這個(gè)平臺(tái)收班，建立一個(gè)不斷更新的控制臺(tái)坟岔，來(lái)顯示集群之間最活躍的網(wǎng)絡(luò)流量的應(yīng)用級(jí)的熱點(diǎn)。此外摔桦，使用Dapper我們能夠?yàn)榘嘿F的網(wǎng)絡(luò)請(qǐng)求提供指出的構(gòu)成原因的跟蹤社付，而不是面對(duì)不同服務(wù)器之間的信息孤島而無(wú)所適從。建立一個(gè)基于Dapper API的dashboard總共沒(méi)花超過(guò)2周的時(shí)間酣溃。

6.5 分層和共享存儲(chǔ)系統(tǒng)

在Google的許多存儲(chǔ)系統(tǒng)是由多重獨(dú)立復(fù)雜層級(jí)的分布式基礎(chǔ)設(shè)備組成的瘦穆。例如，Google的App Engine5就是搭建在一個(gè)可擴(kuò)展的實(shí)體存儲(chǔ)系統(tǒng)上的赊豌。該實(shí)體存儲(chǔ)系統(tǒng)在基于BigTable上公開(kāi)某些RDBMS功能扛或。 BigTable的同時(shí)使用Chubby7（分布式鎖系統(tǒng)）及GFS。再者碘饼，像BigTable這樣的系統(tǒng)簡(jiǎn)化了部署熙兔，并更好的利用了計(jì)算資源。

在這種分層的系統(tǒng)艾恼，并不總是很容易確定最終用戶資源的消費(fèi)模式住涉。例如，來(lái)自于一個(gè)給定的BigTable單元格的GFS大信息量主要來(lái)自于一個(gè)用戶或是由多個(gè)用戶產(chǎn)生钠绍，但是在GFS層面舆声，這兩種明顯的使用場(chǎng)景是很難界定。而且，如果缺乏一個(gè)像Dapper一樣的工具的情況下媳握，對(duì)共享服務(wù)的競(jìng)爭(zhēng)可能會(huì)同樣難于調(diào)試碱屁。

第5.2節(jié)中所示的Dapper的用戶界面可以聚合那些調(diào)用任意公共服務(wù)的多個(gè)客戶端的跟蹤的性能信息。這就很容易讓提供這些服務(wù)的源從多個(gè)維度給他們的用戶排名蛾找。（例如娩脾，入站的網(wǎng)絡(luò)負(fù)載，出站的網(wǎng)絡(luò)負(fù)載打毛，或服務(wù)請(qǐng)求的總時(shí)間）

6.6 Dapper的救火能力(Firefighting)

對(duì)于一些“救火”任務(wù)柿赊，Dapper可以處理其中的一部分』猛鳎“救火”任務(wù)在這里是指一些有風(fēng)險(xiǎn)很高的在分布式系統(tǒng)上的操作碰声。通常情況下，Dapper用戶當(dāng)正在進(jìn)行“救火”任務(wù)時(shí)需要使用新的數(shù)據(jù)展辞，并且沒(méi)有時(shí)間寫(xiě)新的DAPI代碼或等待周期性的報(bào)告運(yùn)行奥邮。

對(duì)于那些高延遲万牺，不罗珍，可能更糟糕的那些在正常負(fù)載下都會(huì)響應(yīng)超時(shí)的服務(wù)，Dapper用戶界面通常會(huì)把這些延遲瓶頸的位置隔離出來(lái)脚粟。通過(guò)與Dapper守護(hù)進(jìn)程的直接通信覆旱，那些特定的高延遲的跟蹤數(shù)據(jù)輕易的收集到。當(dāng)出現(xiàn)災(zāi)難性故障時(shí)核无，通常是沒(méi)有必要去看統(tǒng)計(jì)數(shù)據(jù)以確定根本原因扣唱，只查看示例跟蹤就足夠了(因?yàn)榍拔奶岬竭^(guò)從Dapper守護(hù)進(jìn)程中幾乎可以立即獲得跟蹤數(shù)據(jù))。

但是团南，如在6.5節(jié)中描述的共享的存儲(chǔ)服務(wù)噪沙，要求當(dāng)用戶活動(dòng)過(guò)程中突然中斷時(shí)能盡可能快的匯總信息。對(duì)于事件發(fā)生之后吐根，共享服務(wù)仍然可以利用匯總的的Dapper數(shù)據(jù)正歼，但是，除非收集到的Dapper數(shù)據(jù)的批量分析能在問(wèn)題出現(xiàn)10分鐘之內(nèi)完成拷橘，否則Dapper面對(duì)與共享存儲(chǔ)服務(wù)相關(guān)的“救火”任務(wù)就很難按預(yù)想的那般順利完成局义。

7. 其他收獲

雖然迄今為止，我們?cè)贒apper上的經(jīng)驗(yàn)已經(jīng)大致符合我們的預(yù)期冗疮，但是也出現(xiàn)了一些積極的方面是我們沒(méi)有充分預(yù)料到的萄唇。首先，我們獲得了超出預(yù)期的Dapper使用用例的數(shù)量术幔，對(duì)此我們可謂歡心鼓舞另萤。另外，在除了幾個(gè)的在第6節(jié)使用經(jīng)驗(yàn)中提到過(guò)的一些用例之外诅挑，還包括資源核算系統(tǒng)四敞，對(duì)指定的通訊模式敏感的服務(wù)的檢查工具勾缭，以及一種對(duì)RPC壓縮策略的分析器，等等目养。我們認(rèn)為這些意想不到的用例一定程度上是由于我們向開(kāi)發(fā)者以一種簡(jiǎn)單的編程接口的方式開(kāi)放了跟蹤數(shù)據(jù)存儲(chǔ)的緣故俩由，這使得我們能夠充分利用這個(gè)大的多的社區(qū)的創(chuàng)造力。除此之外癌蚁，Dapper對(duì)舊的負(fù)載的支持也比預(yù)期的要簡(jiǎn)單幻梯，只需要在程序中引入一個(gè)用新版本的重新編譯過(guò)的公共組件庫(kù)(包含常規(guī)的線程使用，控制流和RPC框架)即可努释。

Dapper在Google內(nèi)部的廣泛使用還為我們?cè)贒apper的局限性上提供了寶貴的反饋意見(jiàn)碘梢。下面我們將介紹一些我們已知的最重要的Dapper的不足：

合并的影響：我們的模型隱含的前提是不同的子系統(tǒng)在處理的都是來(lái)自同一個(gè)被跟蹤的請(qǐng)求。在某些情況下伐蒂，緩沖一部分請(qǐng)求煞躬，然后一次性操作一個(gè)請(qǐng)求集會(huì)更加有效。（比如逸邦，磁盤(pán)上的一次合并寫(xiě)入操作）恩沛。在這種情況下甘晤，一個(gè)被跟蹤的請(qǐng)求可以看似是一個(gè)大型工作單元醋安。此外装畅，當(dāng)有多個(gè)追蹤請(qǐng)求被收集在一起争舞，他們當(dāng)中只有一個(gè)會(huì)用來(lái)生成那個(gè)唯一的跟蹤ID饰抒，用來(lái)給其他span使用详瑞，所以就無(wú)法跟蹤下去了摘刑。我們正在考慮的解決方案伟葫，希望在可以識(shí)別這種情況的前提下裹芝，用盡可能少的記錄來(lái)解決這個(gè)問(wèn)題部逮。

跟蹤批處理負(fù)載：Dapper的設(shè)計(jì)，主要是針對(duì)在線服務(wù)系統(tǒng)嫂易，最初的目標(biāo)是了解一個(gè)用戶請(qǐng)求產(chǎn)生的系統(tǒng)行為兄朋。然而，離線的密集型負(fù)載炬搭，例如符合MapReduce10模型的情況蜈漓，也可以受益于性能挖潛。在這種情況下宫盔，我們需要把跟蹤ID與一些其他的有意義的工作單元做關(guān)聯(lián)融虽，諸如輸入數(shù)據(jù)中的鍵值（或鍵值的范圍），或是一個(gè)MapReduce shard灼芭。

尋找根源：Dapper可以有效地確定系統(tǒng)中的哪一部分致使系統(tǒng)整個(gè)速度變慢有额，但并不總是能夠找出問(wèn)題的根源。例如，一個(gè)請(qǐng)求很慢有可能不是因?yàn)樗约旱男袨槲∮樱怯捎陉?duì)列中其他排在它前面的(queued ahead of)請(qǐng)求還沒(méi)處理完茴迁。程序可以使用應(yīng)用級(jí)的annotation把隊(duì)列的大小或過(guò)載情況寫(xiě)入跟蹤系統(tǒng)。此外萤衰，如果這種情況屢見(jiàn)不鮮堕义，那么在ProfileMe11中提到的成對(duì)的采樣技術(shù)可以解決這個(gè)問(wèn)題。它由兩個(gè)時(shí)間重疊的采樣率組成脆栋，并觀察它們?cè)谡麄€(gè)系統(tǒng)中的相對(duì)延遲倦卖。

記錄內(nèi)核級(jí)的信息：一些內(nèi)核可見(jiàn)的事件的詳細(xì)信息有時(shí)對(duì)確定問(wèn)題根源是很有用的。我們有一些工具椿争，能夠跟蹤或以其他方式描述內(nèi)核的執(zhí)行怕膛，但是，想用通用的或是不那么突兀的方式秦踪，是很難把這些信息到捆綁到用戶級(jí)別的跟蹤上下文中褐捻。我們正在研究一種妥協(xié)的解決方案，我們?cè)谟脩魧用嫔习岩恍﹥?nèi)核級(jí)的活動(dòng)參數(shù)做快照椅邓，然后綁定他們到一個(gè)活動(dòng)的span上柠逞。

8. 相關(guān)產(chǎn)品

在分布式系統(tǒng)跟蹤領(lǐng)域，有一套完整的體系希坚，一部分系統(tǒng)主要關(guān)注定位到故障位置边苹，其他的目標(biāo)是針對(duì)性能進(jìn)行優(yōu)化。 Dapper確實(shí)被用于發(fā)現(xiàn)系統(tǒng)問(wèn)題裁僧，但它更通常用于探查性能不足，以及提高全面大規(guī)模的工作負(fù)載下的系統(tǒng)行為的理解慕购。

與Dapper相關(guān)的黑盒監(jiān)控系統(tǒng)聊疲，比如Project51，WAP515和Sherlock2沪悲，可以說(shuō)不依賴運(yùn)行庫(kù)的情況下获洲，黑盒監(jiān)控系統(tǒng)能夠?qū)崿F(xiàn)更高的應(yīng)用級(jí)透明。黑盒的缺點(diǎn)是一定程度上不夠精確殿如，并可能在統(tǒng)計(jì)推斷關(guān)鍵路徑時(shí)帶來(lái)更大的系統(tǒng)損耗贡珊。

對(duì)于分布式系統(tǒng)監(jiān)控來(lái)說(shuō)，基于Annotation的中間件或應(yīng)用自身是一個(gè)可能是更受歡迎的解決辦法.拿Pip14和Webmon16系統(tǒng)舉例涉馁，他們更依賴于應(yīng)用級(jí)的Annotation门岔，而X-Trace12，Pinpoint9和Magpie3大多集中在對(duì)庫(kù)和中間件的修改烤送。Dapper更接近后者寒随。像Pinpoint，X-Trace，和早期版本的Magpie一樣妻往，Dapper采用了全局標(biāo)識(shí)符把分布式系統(tǒng)中各部分相關(guān)的事件聯(lián)系在一起互艾。和這些系統(tǒng)類似，Dapper嘗試避免使用應(yīng)用級(jí)Annotation讯泣，而是把的植入隱藏在通用組件模塊內(nèi)纫普。Magpie放棄使用全局ID，仍然試圖正確的完成請(qǐng)求的正確傳播好渠，他通過(guò)采用應(yīng)用系統(tǒng)各自寫(xiě)入的事件策略局嘁，最終也能精確描述不同事件之間關(guān)系。但是目前還不清楚Magpie在實(shí)際環(huán)境中實(shí)現(xiàn)透明性這些策略到底多么有效晦墙。 X-Trace的核心Annotation比Dapper更有野心一些悦昵，因?yàn)閄-Trace系統(tǒng)對(duì)于跟蹤的收集，不僅在跟蹤節(jié)點(diǎn)層面上晌畅，而且在節(jié)點(diǎn)內(nèi)部不同的軟件層也會(huì)進(jìn)行跟蹤但指。而我們對(duì)于組件的低性能損耗的要求迫使我們不能采用X-Trace這樣的模型，而是朝著把一個(gè)請(qǐng)求連接起來(lái)完整跟蹤所能做到的最小代價(jià)而努力抗楔。而Dapper的跟蹤仍然可以從可選的應(yīng)用級(jí)Annotation中獲益棋凳。

9. 總結(jié)

在本文中，我們介紹Dapper這個(gè)Google的生產(chǎn)環(huán)境下的分布式系統(tǒng)跟蹤平臺(tái)连躏，并匯報(bào)了我們開(kāi)發(fā)和使用它的相關(guān)經(jīng)驗(yàn)剩岳。 Dapper幾乎在部署在所有的Google系統(tǒng)上，并可以在不需要應(yīng)用級(jí)修改的情況下進(jìn)行跟蹤入热，而且沒(méi)有明顯的性能影響拍棕。Dapper對(duì)于開(kāi)發(fā)人員和運(yùn)維團(tuán)隊(duì)帶來(lái)的好處，可以從我們主要的跟蹤用戶界面的廣泛使用上看出來(lái)勺良，另外我們還列舉了一些Dapper的使用用例來(lái)說(shuō)明Dapper的作用绰播，這些用例有些甚至都沒(méi)有Dapper開(kāi)發(fā)團(tuán)隊(duì)參與，而是被應(yīng)用的開(kāi)發(fā)者開(kāi)發(fā)出來(lái)的尚困。

據(jù)我們所知蠢箩，這是第一篇匯報(bào)生產(chǎn)環(huán)境下分布式系統(tǒng)跟蹤框架的論文。事實(shí)上事甜，我們的主要貢獻(xiàn)源于這個(gè)事實(shí)：論文中回顧的這個(gè)系統(tǒng)已經(jīng)運(yùn)行兩年之久谬泌。我們發(fā)現(xiàn)，結(jié)合對(duì)開(kāi)發(fā)人員提供簡(jiǎn)單API和對(duì)應(yīng)用系統(tǒng)完全透明來(lái)增強(qiáng)跟蹤的這個(gè)決定逻谦，是非常值得的掌实。

我們相信，Dapper比以前的基于Annotation的分布式跟蹤達(dá)到更高的應(yīng)用透明度跨跨，這一點(diǎn)已經(jīng)通過(guò)只需要少量人工干預(yù)的工作量得以證明潮峦。雖然一定程度上得益于我們的系統(tǒng)的同質(zhì)性囱皿，但它本身仍然是一個(gè)重大的挑戰(zhàn)。最重要的是忱嘹，我們的設(shè)計(jì)提出了一些實(shí)現(xiàn)應(yīng)用級(jí)透明性的充分條件嘱腥，對(duì)此我們希望能夠?qū)Ωe(cuò)雜環(huán)境下的解決方案的開(kāi)發(fā)有所幫助。

最后拘悦，通過(guò)開(kāi)放Dapper跟蹤倉(cāng)庫(kù)給內(nèi)部開(kāi)發(fā)者齿兔，我們促使更多的基于跟蹤倉(cāng)庫(kù)的分析工具的產(chǎn)生，而僅僅由Dapper團(tuán)隊(duì)默默的在信息孤島中埋頭苦干的結(jié)果遠(yuǎn)達(dá)不到現(xiàn)在這么大的規(guī)模础米，這個(gè)決定促使了設(shè)計(jì)和實(shí)施的展開(kāi)分苇。

Acknowledgments

We thank Mahesh Palekar, Cliff Biffle, Thomas Kotzmann, Kevin Gibbs, Yonatan Zunger, Michael Kleber, and Toby Smith for their experimental data and feedback about Dapper experiences. We also thank Silvius Rus for his assistance with load testing. Most importantly, though, we thank the outstanding team of engineers who have continued to develop and improve Dapper over the years; in order of appearance, Sharon Perl, Dick Sites, Rob von Behren, Tony DeWitt, Don Pazel, Ofer Zajicek, Anthony Zana, Hyang-Ah Kim, Joshua MacDonald, Dan Sturman, Glenn Willen, Alex Kehlenbeck, Brian McBarron, Michael Kleber, Chris Povirk, Bradley White, Toby Smith, Todd Derr, Michael De Rosa, and Athicha Muthitacharoen. They have all done a tremendous amount of work to make Dapper a day-to-day reality at Google.

References

1 M. K. Aguilera, J. C. Mogul, J. L. Wiener, P. Reynolds, and A. Muthitacharoen. Performance Debugging for Distributed Systems of Black Boxes. In Proceedings of the 19th ACM Symposium on Operating Systems Principles, December 2003.

2 P. Bahl, R. Chandra, A. Greenberg, S. Kandula, D. A. Maltz, and M. Zhang. Towards Highly Reliable Enterprise Network Services Via Inference of Multi-level Dependencies. In Proceedings of SIGCOMM, 2007.

3 P. Barham, R. Isaacs, R. Mortier, and D. Narayanan. Magpie: online modelling and performance-aware systems. In Proceedings of USENIX HotOS IX, 2003.

4 L. A. Barroso, J. Dean, and U. Holzle. Web Search for a Planet: The Google Cluster Architecture. IEEE Micro, 23(2):22–28, March/April 2003.

5 T. O. G. Blog. Developers, start your engines. http://googleblog.blogspot.com/2008/04/developers-start-your-engines.html,2007.

6 T. O. G. Blog. Universal search: The best answer is still the best answer. http://googleblog.blogspot.com/2007/05/universal-search-best-answer-is-still.html, 2007.

7 M. Burrows. The Chubby lock service for loosely-coupled distributed systems. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, pages 335 – 350, 2006.

8 F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable: A Distributed Storage System for Structured Data. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI’06), November 2006.

9 M. Y. Chen, E. Kiciman, E. Fratkin, A. fox, and E. Brewer. Pinpoint: Problem Determination in Large, Dynamic Internet Services. In Proceedings of ACM International Conference on Dependable Systems and Networks, 2002.

10 J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In Proceedings of the 6th USENIX Symposium on Operating Systems Design and Implementation (OSDI’04), pages 137 – 150, December 2004.

11 J. Dean, J. E. Hicks, C. A. Waldspurger, W. E. Weihl, and G. Chrysos. ProfileMe: Hardware Support for Instruction-Level Profiling on Out-of-Order Processors. In Proceedings of the IEEE/ACM International Symposium on Microarchitecture, 1997.

12 R. Fonseca, G. Porter, R. H. Katz, S. Shenker, and I. Stoica. X-Trace: A Pervasive Network Tracing Framework. In Proceedings of USENIX NSDI, 2007.

13 B. Lee and K. Bourrillion. The Guice Project Home Page. http://code.google.com/p/google-guice/, 2007.

14 P. Reynolds, C. Killian, J. L. Wiener, J. C. Mogul, M. A. Shah, and A. Vahdat. Pip: Detecting the Unexpected in Distributed Systems. In Proceedings of USENIX NSDI, 2006.

15 P. Reynolds, J. L. Wiener, J. C. Mogul, M. K. Aguilera, and A. Vahdat. WAP5: Black Box Performance Debugging for Wide-Area Systems. In Proceedings of the 15th International World Wide Web Conference, 2006.

16 P. K. G. T. Gschwind, K. Eshghi and K. Wurster. WebMon: A Performance Profiler for Web Transactions. In E-Commerce Workshop, 2002.

下載

【英文】Dapper，大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)原文.pdf - https://github.com/souyunku/Dapper-translation