大规模分布式跟踪系统的理论
概述
當(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)題的工具。
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)查詢(xún)服務(wù)器發(fā)起了一個(gè)Web查詢(xún)，每一個(gè)查詢(xún)都有自己的Index。這個(gè)查詢(xún)可能會(huì)被發(fā)送到多個(gè)的子系統(tǒng)，這些子系統(tǒng)分別用來(lái)處理廣告、進(jìn)行拼寫(xiě)檢查或是查找一些像圖片、視頻或新聞這樣的特殊結(jié)果。根據(jù)每個(gè)子系統(tǒng)的查詢(xún)結(jié)果進(jìn)行篩選，得到最終結(jié)果，最后匯總到頁(yè)面上。我們把這種搜索模型稱(chēng)為“全局搜索”（universal search）。總的來(lái)說(shuō)，這一次全局搜索有可能調(diào)用上千臺(tái)服務(wù)器，涉及各種服務(wù)。而且，用戶對(duì)搜索的耗時(shí)是很敏感的，而任何一個(gè)子系統(tǒng)的低效都導(dǎo)致導(dǎo)致最終的搜索耗時(shí)。如果一個(gè)工程師只能知道這個(gè)查詢(xún)耗時(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)求類(lèi)型，而一個(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)異?；蚴悄切┲匾南到y(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)想生效，就必須需要依賴(lài)應(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ò)了，其中的Pinpoint[9]、Magpie[3]和X-Trace[12]和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]依賴(lài)于應(yīng)用程序或中間件明確地標(biāo)記一個(gè)全局ID，從而連接每一條記錄和發(fā)起者的請(qǐng)求。雖然黑盒方案比標(biāo)注方案更輕便，他們需要更多的數(shù)據(jù)，以獲得足夠的精度，因?yàn)樗麄円蕾?lài)于統(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ù)器的查詢(xún)等。從形式上看，我們的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名稱(chēng)，以及每個(gè)span的ID和父ID，以重建在一次追蹤過(guò)程中不同span之間的關(guān)系。如果一個(gè)span沒(méi)有父ID被稱(chēng)為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：在圖2中所示的一個(gè)單獨(dú)的span的細(xì)節(jié)圖
圖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)行跟蹤，幾乎完全依賴(lài)于基于少量通用組件庫(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)類(lèi)型。
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)銷(xiāo)。我們還發(fā)現(xiàn)，某些類(lèi)型的Web服務(wù)對(duì)植入帶來(lái)的性能損耗確實(shí)非常敏感。因此，除了把Dapper的收集工作對(duì)基本組件的性能損耗限制的盡可能小之外，我們還有進(jìn)一步控制損耗的辦法，那就是遇到大量請(qǐng)求時(shí)只記錄其中的一小部分。我們將在4.4節(jié)中討論跟蹤的采樣率方案的更多細(xì)節(jié)。
圖5：Dapper收集管道的總覽
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方法的名稱(chēng)，但在這個(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)行分類(lèi)。例如，所有的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++偏底層);這些類(lèi)型的應(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)銷(xiāo)是Dapper性能影響中最關(guān)鍵的部分，因?yàn)槭占头治隹梢愿菀自诰o急情況下被關(guān)閉。Dapper運(yùn)行庫(kù)中最重要的跟蹤生成消耗在于創(chuàng)建和銷(xiāo)毀span和annotation，并記錄到本地磁盤(pán)供后續(xù)的收集。根span的創(chuàng)建和銷(xiāo)毀需要損耗平均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ò)資源。
表1：Dapper守護(hù)進(jìn)程在負(fù)載測(cè)試時(shí)的CPU資源使用率
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ì)性能的影響。
表2：網(wǎng)絡(luò)搜索集群中，對(duì)不同采樣率對(duì)網(wǎng)絡(luò)延遲和吞吐的影響。延遲和吞吐的實(shí)驗(yàn)誤差分別是2.5%和0.15%。
我們看到，雖然對(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)行期采樣率，這樣就可以?xú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”或稱(chēng)作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ù)名稱(chēng)，主機(jī)，和時(shí)間戳的順序進(jìn)行有效的查找。
5.1.1 DAPI在Google內(nèi)部的使用
DAPI在谷歌的使用有三類(lèi)：使利用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中展示。
圖6
為了讓用戶查詢(xún)實(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ā)送特定跟蹤的連接，這將不可避免地在查詢(xún)跟蹤情況時(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)在很多種情況中確定，哪些查詢(xún)是無(wú)需通過(guò)主策略訪問(wèn)而可以采用副本策略訪問(wèn)。Dapper現(xiàn)在可以負(fù)責(zé)監(jiān)控哪些主策略被直接訪問(wèn)，并對(duì)重要的系統(tǒng)常量進(jìn)行保障。
- 理解性：廣告審查查詢(xún)跨越了各種類(lèi)型的系統(tǒng)，包括BigTable—之前提到的那個(gè)數(shù)據(jù)庫(kù)，多維索引服務(wù)，以及其他各種C++和Java后端服務(wù)。Dapper的跟蹤用來(lái)評(píng)估總查詢(xún)成本，促進(jìn)重新對(duì)業(yè)務(wù)的設(shè)計(jì)，用以在他們的系統(tǒng)依賴(lài)上減少負(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)自身的代碼或是他的依賴(lài)包。
廣告審查團(tuán)隊(duì)廣泛使用了Dapper Annotation API。Guice[13]開(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é)論。
圖7：全局搜索的跟蹤片段，在不常遇到高網(wǎng)絡(luò)延遲的情況下，在沿著關(guān)鍵路徑的端到端的請(qǐng)求延遲，如圖所示。
在調(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à)很高的查詢(xún)模式來(lái)源于一些意想不到的服務(wù)之間的交互。一旦發(fā)現(xiàn)，往往容易糾正它們，但是Dapper出現(xiàn)之前想找出這些問(wèn)題是相當(dāng)困難的。
- 通用的查詢(xún)從Dapper之外的安全日志倉(cāng)庫(kù)中收取，并使用Dapper唯一的跟蹤ID，與Dapper的倉(cāng)庫(kù)做關(guān)聯(lián)。然后，該映射用來(lái)建立關(guān)于在全局搜索中的每一個(gè)獨(dú)立子系統(tǒng)都很慢的實(shí)例查詢(xún)的列表。
6.3 推斷服務(wù)依賴(lài)
在任何給定的時(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ù)通常依賴(lài)于其他的集群上的任務(wù)。由于任務(wù)們之間的依賴(lài)是動(dòng)態(tài)改變的，所以不可能僅從配置信息上推斷出所有這些服務(wù)之間的依賴(lài)關(guān)系。不過(guò)，除了其他方面的原因之外，在公司內(nèi)部的各個(gè)流程需要準(zhǔn)確的服務(wù)依賴(lài)關(guān)系信息，以確定瓶頸所在，以及計(jì)劃服務(wù)的遷移。Google的可稱(chēng)為“Service Dependencies”的項(xiàng)目是通過(guò)使用跟蹤Annotation和DAPI MapReduce接口來(lái)實(shí)現(xiàn)自動(dòng)化確定服務(wù)依賴(lài)歸屬的。
Dapper核心組件與Dapper跟蹤Annotation一并使用的情況下，“Service Dependencies”項(xiàng)目能夠推算出任務(wù)各自之間的依賴(lài)，以及任務(wù)和其他軟件組件之間的依賴(lài)。比如，所有的BigTable的操作會(huì)加上與受影響的表名稱(chēng)相關(guān)的標(biāo)記。運(yùn)用Dapper的平臺(tái)，Service Dependencies團(tuán)隊(duì)就可以自動(dòng)的推算出依賴(lài)于命名的不同資源的服務(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 Engine[5]就是搭建在一個(gè)可擴(kuò)展的實(shí)體存儲(chǔ)系統(tǒng)上的。該實(shí)體存儲(chǔ)系統(tǒng)在基于BigTable上公開(kāi)某些RDBMS功能。 BigTable的同時(shí)使用Chubby[7]（分布式鎖系統(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ù)載，例如符合MapReduce[10]模型的情況，也可以受益于性能挖潛。在這種情況下，我們需要把跟蹤ID與一些其他的有意義的工作單元做關(guān)聯(lián)，諸如輸入數(shù)據(jù)中的鍵值（或鍵值的范圍），或是一個(gè)MapReduce shard。
- 尋找根源：Dapper可以有效地確定系統(tǒng)中的哪一部分致使系統(tǒng)整個(gè)速度變慢，但并不總是能夠找出問(wèn)題的根源。例如，一個(gè)請(qǐng)求很慢有可能不是因?yàn)樗约旱男袨?#xff0c;而是由于隊(duì)列中其他排在它前面的(queued ahead of)請(qǐng)求還沒(méi)處理完。程序可以使用應(yīng)用級(jí)的annotation把隊(duì)列的大小或過(guò)載情況寫(xiě)入跟蹤系統(tǒng)。此外，如果這種情況屢見(jiàn)不鮮，那么在ProfileMe[11]中提到的成對(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)，比如Project5[1]，WAP5[15]和Sherlock[2]，可以說(shuō)不依賴(lài)運(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è)可能是更受歡迎的解決辦法.拿Pip[14]和Webmon[16]系統(tǒng)舉例，他們更依賴(lài)于應(yīng)用級(jí)的Annotation，而X-Trace[12]，Pinpoint[9]和Magpie[3]大多集中在對(duì)庫(kù)和中間件的修改。Dapper更接近后者。像Pinpoint，X-Trace，和早期版本的Magpie一樣，Dapper采用了全局標(biāo)識(shí)符把分布式系統(tǒng)中各部分相關(guān)的事件聯(lián)系在一起。和這些系統(tǒng)類(lèi)似，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)。
總結(jié)
以上是生活随笔為你收集整理的大规模分布式跟踪系统的理论的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 解决Mysql读写分离数据延迟
- 下一篇： diamond淘宝框架使用