http://www.cnblogs.com/LBSer/p/3390852.html
最近單位需要做自己的分布式監控系統，因此看了一些資料，其中就有google的分布式追蹤系統dapper的論文：http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN//pubs/archive/36356.pdf，結合自己的理解描述下這篇論文。
一、引子：
用戶輸入關鍵字后只要敲個回車鍵就能返回搜索結果（圖1a），這樣一個簡單的過程可能涉及到上千個服務，可能需要上千個服務器協作完成。如圖1b所示，user發了RequestX請求到達A，A通過rpc（遠程過程調用，如thrift）調用B以及C，而C又需要通過rpc調用D以及E等等。
對user的一次請求，他遲遲未收到響應ReplyX，或者響應時間很慢，我們需要確認性能到底消耗在哪個環節，這個時候我們該怎么辦呢？自然是分析我們的日志。
我們每個服務都會有請求日志，請求日志記錄着一次調用所花費的時間，比如對A來說，記錄着調用B所花費的時間以及調用C所花費的時間，同理C的請求日志記錄着調用D以及E所花費的時間。對於互聯網應用來說，各個服務比如B，同一時刻可能有成百上千次請求記錄。
這種日志有個致命缺點---沒有將這些記錄與特定的請求關聯一起。對於user的一條特定的請求RequestX，我們不知道B日志中哪條記錄與之對應，也不知道C日志中哪條記錄與之對應。。。總而言之，我們不能很具體的分析user的一次請求響應緩慢到底消耗在哪個環節。
二、 如何將各個服務日志的每一條記錄與特定的請求關聯在一起呢？
當前學術界和工業界有兩種方法：
1）黑盒方法（black box）
日志還是一樣的記錄，只是通過機器學習的方法來關聯記錄與特定的請求。以一條特定請求RequestX為變量，通過黑盒（也就是機器學習的模型，比如回歸分析）從A的日志中找出一條記錄與之對應，同理可以找出B、C、D、E等等的相關記錄。
黑盒方法的優勢就是不需要改變現有日志記錄方法，但是缺點很明顯，機器學習的精度往往不高，實際使用中效果不好。
2）基於注釋的方案
利用應用程序或中間件給每條記錄一個全局標志符，借此將一串請求關聯起來。比如對RequestX來說，賦予一個標志符1000，后續相關各個服務都會將標識符1000與記錄一起打在日志里。這種方法的優勢就是比較精確，目前google、twitter、淘寶等都采用這種方式。下面介紹google的分布式追蹤系統解決方案---dapper。
三、dapper的設計目標：
1）低消耗
dapper本質是用來發現性能消耗問題，如果dapper本身很消耗性能，沒人願意使用，因此低消耗是必須的，dapper使用一系列創新方法確保低消耗，比如使用采樣方法。
2）應用級透明
應用級透明的意思是程序員可以不需要在自己的代碼中嵌入dapper相關的代碼就能達到分布式追蹤日志記錄的目的。每一個工程師都希望自己的代碼是純粹的，如果需要嵌入dapper相關代碼，那么既影響代碼維護，又影響bug定位。
3）擴展性好
對於一個快速發展的互聯網公司而言，用戶規模快速增長導致着服務以及機器數量越來越多，因此dapper需要適應相應的發展，擴展性要好。
四、dapper的幾個關鍵點：
1）dapper日志記錄的格式是怎樣的呢？
dapper用span來表示一個服務調用開始和結束的時間，也就是時間區間(圖2對應着圖1b的調用圖)。dapper記錄了span的名稱以及每個span的ID和父ID，如果一個span沒有父ID被稱之為root span。所有的span都掛在一個特定得追蹤上，共用一個跟蹤ID，這些ID用全局64位整數標示，也就是圖2的traceID。
2）如何實現應用級透明？
在google的環境中，所有的應用程序使用相同的線程模型、控制流和RPC系統，既然不能讓工程師寫代碼記錄日志，那么就只能讓這些線程模型、控制流和RPC系統來自動幫助工程師記錄日志了。
舉個例子，幾乎所有的google進程間通信是建立在一個用C++和JAVA開發的RPC框架上，dapper把跟蹤植入這個框架，span的ID和跟蹤的ID會從客戶端發送到服務端，這樣工程師也就不需要關心。
3）dapper跟蹤收集的流程
如圖3所示，分為3個階段：a）各個服務將span數據寫到本機日志上；b）dapper守護進程進行拉取，將數據讀到dapper收集器里；c）dapper收集器將結果寫到bigtable中，一次跟蹤被記錄為一行。
4）如何盡可能降低開銷？
作為一個分布式追蹤系統，dapper希望盡可能降低性能開銷。如果對每一次的請求都進行追蹤收集，開銷還是有點大的。一個比較好的方式是通過統計采樣的方法，抽樣追蹤一些請求，從而達到性能開銷與精度的折中。
dapper的第一個版本設置了一個統一的采樣率1/1024，也就是1024個請求才追蹤一次。后來發現對一些高吞吐的服務來說是可以的，比如每秒幾十萬的請求，但是對一些低吞吐量的服務，比如每秒幾十個請求的服務，如果采樣率設置為1/1024，很多性能問題可能不會被追蹤到。因此在第二版本dapper提供了自適應的采樣率，在低吞吐量時候提高采樣率，在高吞吐量時降低采樣率。
上面的采樣是在第一個階段，此外在收集器將span數據寫到bigtable時，還可以使用第二次采樣，即不一定都將數據寫入到bigtable中。
五、dapper的使用
1）監測新服務部署性能情況
對一個新服務，往往需要經過一段時間的觀察，這時候可以使用dapper進行監測，從而發現存在的性能的問題；
2）推斷服務間的依存關系
通過使用dapper，可以很清晰的表明一個服務依賴了哪些服務，以及一個服務影響到哪些服務，這樣能促使我們在上線的時候能及時通知下游服務監控者重點觀察。
...）
六、dapper的不足
1）某些時候緩沖一些請求，然后一次性操作會比較高效，比如I/O請求等。各個請求都有traceID，但是聚集之后只有一個請求，因此只能選擇一個traceID用於傳遞到聚集請求，這時追蹤會中斷。
2）dapper可能找出某個環節慢了，但不一定能找出根源。比如一個請求慢可能不是它自身慢，而可能它在消息隊列中比較靠后。
...）