分佈式監控系統zipkin介紹

zipkin是Twitter基於google的分佈式監控系統Dapper（論文）的開發源實現，zipkin用於跟蹤分佈式服務之間的應用數據鏈路，分析處理延時，幫助咱們改進系統的性能和定位故障。

zipkin架構

Instrumented client和Instrumented server是分佈式系統中的服務，經過裝備庫採集跟蹤信息，裝備庫再調用Transport，把跟蹤信息發送給zipkin。

裝備庫

針對不一樣語言，不一樣RPC框架，有不一樣的裝備庫實現，目前已有實現列表見此，其中Brave是zipkin官方提供的Java的裝備庫。
一個裝備庫的實現須要考慮以下狀況：

• 實現語言，和須要裝備的服務的語言一致
• zipkin須要的核心數據結構信息記錄，包括tracerid,spanid的生成，延遲時間的計算，事件記錄，tag記錄等
• 服務之間跟蹤信息的傳遞，稱爲植入，不一樣RPC接口植入的方式不同，例如HTTP接口採用B3協議植入
  植入的信息包括：Trace Id、Span Id、Parent Id、Sampled、Flags
• 採樣，減小跟蹤致使的系統負荷
• 報告給zipkin，調用Transport將跟蹤信息傳給zipkin

Transport

Transport是zipkin對外提供的接口，目前有HTTP、Kafka、Scribe三種。

• HTTP：採用json格式，接口定義見https://github.com/openzipkin/zipkin-api
• Kafka：分佈式發佈訂閱消息系統
• Scribe：Facebook的日誌收集系統https://github.com/facebook/scribe

核心數據結構

v2版本：

• traceId：64位或128位，全局惟一，
• parentId：父spanid，64位，根span的parentId爲空
• id：spanid，64位，tranceId內惟一
• name：方法名
• serviceName：服務名
• timestamp：自1970-1-1 00:00:00 UTC的微秒
• duration：開始span到結束span的時間，單位微秒
• annotations：記錄事件，value有一些預約義的值，例如客戶端發送(cs)，客戶端接收(cr)，服務端接收(sr)，服務端發送(ss)等
• tags：記錄附加數據

一個Span就是記錄[remoteEndpoint.serviceName]服務的[Span.name]方法的執行過程，其中的annotation記錄了中間的一些事件發生時間，經過這些時間能夠獲得[Span.name]方法的網絡傳輸時間，服務端執行時間，客戶端響應時間等信息，從而對其進行診斷優化。多個Span經過parentId構成一個樹形結構，根Span的parentId爲空，描述了一次trace（tranceId標識）中多個服務之間的調用過程。

示例說明

https://github.com/zhongpan/zipkin-ice

假設service1.fun1中調用service2.fun2和service3.fun3，service2.fun2中調用service4.fun4。本次跟蹤各個服務中會建立如上的span1~span7，span1爲根span。span2和span4爲一次RPC的客戶端和服務端行爲，能夠共享spanid，span4不用新生成spanid，span2和span4在zipkin中會合併爲1個span，span3/span5以及span6/span7相似。最終，在zipkin界面展現的樹形結構爲：