一、為什麼需要分布式調用跟蹤系統
随着分布式服務架構的流行，特别是微服務等設計理念在系統中的應用，業務的調用鍊越來越複雜，
可以看到，随着服務的拆分，系統的子產品變得越來越多，不同的子產品可能由不同的團隊維護，
一個請求可能會涉及到幾十個服務的協同處理， 牽扯到多個團隊的業務系統，那麼如何快速準确的定位到線上故障？
同時，缺乏一個自上而下全局的調用id，如何有效的進行相關的資料分析工作？
對于大型網站系統，如淘寶、京東等電商網站，這些問題尤其突出。
一個典型的分布式系統請求調用過程：
比較成熟的解決方案是通過調用鍊的方式，把一次請求調用過程完整的串聯起來，這樣就實作了對請求調用路徑的監控。
通過調用鍊跟蹤，一次請求的邏輯軌迹可以用完整清晰的展示出來。
開發中可以在業務日志中添加調用鍊id，可以通過調用鍊結合業務日志快速定位錯誤資訊。
在調用鍊的各個環節分别添加調用時延，可以分析系統的性能瓶頸，進行針對性的優化。
通過分析各個環節的平均時延，qps等資訊，可以找到系統的薄弱環節，對一些子產品做調整，如資料備援等。
調用鍊是一條完整的業務日志，可以得到使用者的行為路徑，彙總分析應用在很多業務場景。
低侵入性，應用透明：
作為非業務元件，應當盡可能少侵入或者無侵入其他業務系統，對于使用方透明，減少開發人員的負擔
低損耗：
服務調用埋點本身會帶來性能損耗，這就需要調用跟蹤的低損耗，
實際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑
大範圍部署，擴充性：
作為分布式系統的元件之一，一個優秀的調用跟蹤系統必須支援分布式部署，具備良好的可擴充性
埋點即系統在目前節點的上下文資訊，可以分為用戶端埋點、服務端埋點，以及用戶端和服務端雙向型埋點。
埋點日志通常要包含以下内容：
traceid、rpcid、調用的開始時間，調用類型，協定類型，調用方ip和端口，請求的服務名等資訊；
調用耗時，調用結果，異常資訊，消息封包等；
預留可擴充字段，為下一步擴充做準備；
日志的采集和存儲有許多開源的工具可以選擇，
一般來說，會使用離線+實時的方式去存儲日志，主要是分布式日志采集的方式。
典型的解決方案如flume結合kafka等mq。
一條調用鍊的日志散落在調用經過的各個伺服器上，
首先需要按 traceid 彙總日志，然後按照rpcid 對調用鍊進行順序整理。
調用鍊資料不要求百分之百準确，可以允許中間的部分日志丢失。
彙總得到各個應用節點的調用鍊日志後，可以針對性的對各個業務線進行分析。
需要對具體日志進行整理，進一步儲存在hbase或者關系型資料庫中，可以進行可視化的查詢。
大的網際網路公司都有自己的分布式跟蹤系統，
比如google的dapper，twitter的zipkin，淘寶的鷹眼，新浪的watchman，京東的hydra等。
dapper是google生産環境下的分布式跟蹤系統，dapper有三個設計目标：
低消耗：跟蹤系統對線上服務的影響應該做到足夠小。
應用級的透明：對于應用的程式員來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那麼這個跟蹤系統顯然是侵入性太強的。
延展性：google至少在未來幾年的服務和叢集的規模，監控系統都應該能完全把控住。
2、drapper的日志格式：
<b>（1）</b>dapper用span來表示一個服務調用開始和結束的時間，也就是時間區間。
dapper記錄了span的名稱以及每個span的id和父id，如果一個span沒有父id被稱之為root span。所有的span都挂在一個特定的trace上，共用一個traceid，這些id用全局64位整數标示。
drapper如何進行跟蹤收集：
分為3個階段：
①各個服務将span資料寫到本機日志上；
②dapper守護程序進行拉取，将資料讀到dapper收集器裡；
③dapper收集器将結果寫到bigtable中，一次跟蹤被記錄為一行。
關于淘寶的鷹眼系統，主要資料來自于内部分享，
鷹眼埋點和生成日志：
如何抓取和存儲日志：
鷹眼的實作小結：
參考資料：
<a href="http://www.cnblogs.com/lbser/p/3390852.html" target="_blank">分布式追蹤系統dapper</a>
<a href="https://bigbully.github.io/dapper-translation/" target="_blank">dapper，大規模分布式系統的跟蹤系統</a>
<a href="https://book.douban.com/subject/26702824/" target="_blank">李林峰《分布式服務架構原理與實踐》</a>