概述
zipkin
爲分佈式鏈路調用監控系統,聚合各業務系統調用延遲數據,達到鏈路調用監控跟蹤。
在複雜的調用鏈路中假設存在一條調用鏈路響應緩慢,如何定位其中延遲高的服務呢?
- 日誌: 通過分析調用鏈路上的每個服務日誌得到結果
- zipkin:使用
zipkin
的web UI
可以一眼看出延遲高的服務
zipkin
zipkin主要涉及四個組件 collector storage search web UI
- Collector接收各service傳輸的數據
- Cassandra作爲Storage的一種,也可以是mysql等,默認存儲在內存中,配置cassandra可以參考這裏
- Query負責查詢Storage中存儲的數據,提供簡單的JSON API獲取數據,主要提供給web UI使用
- Web 提供簡單的web界面
使用zipkin涉及幾個概念
1. Span:基本工作單元,一次鏈路調用(可以是RPC,DB等沒有特定的限制)創建一個span,通過一個64位ID標識它,
span通過還有其他的數據,例如描述信息,時間戳,key-value對的(Annotation)tag信息,parent-id等,其中parent-id
可以表示span調用鏈路來源,通俗的理解span就是一次請求信息
2. Trace:類似於樹結構的Span集合,表示一條調用鏈路,存在唯一標識
3. Annotation: 註解,用來記錄請求特定事件相關信息(例如時間),通常包含四個註解信息
cs - Client Start,表示客戶端發起請求
sr - Server Receive,表示服務端收到請求
ss - Server Send,表示服務端完成處理,並將結果發送給客戶端
cr - Client Received,表示客戶端獲取到服務端返回信息
4. BinaryAnnotation:提供一些額外信息,一般已key-value對出現
完整的調用鏈路
上圖表示一請求鏈路,一條鏈路通過Trace Id
唯一標識,Span
標識發起的請求信息,各span
通過parent id
關聯起來,如圖
整個鏈路的依賴關係如下:
完成鏈路調用的記錄後,如何來計算調用的延遲呢,這就需要利用Annotation
信息
sr-cs 得到請求發出延遲
ss-sr 得到服務端處理延遲
cr-cs 得到真個鏈路完成延遲
Span細節圖
注意,上圖並沒有顯示Span的所有細節(比如name和binaryAnnotation等),但這並不影響我們分析問題。
上圖的①和⑥是一次完整的RPC調用,它發生在服務器0和服務器1之間,顯而易見的是,用於描述該RPC調用的Span的spanId是1000,所以,這是同一個Span的,只是它的數據來源於兩臺不同的服務器(應用):服務器0和服務器1。
往低層說,該Span由兩條跟蹤日誌表示,一條在服務器0上被採集,另一條在服務器1上被採集,他們的Span的traceId、spanId和parentSpanId都是一樣的!而且該Span將成爲跟蹤樹中的頂節點,因爲他們的parentSpanId爲null。
對於步驟①來說,服務器1上的sr減去服務器0上的cs的時間就是約等於網絡耗時(這裏忽略不同服務器時鐘的差異),同理,對於其他步驟,sr-cs和cr-ss得到的都是網絡耗時。
我們接着看請求步驟②和④,從跟蹤樹的層次來說他們屬於①下的子調用,所以它們的parentSpanId就是①的1000。步驟②和④都會分別產生一個spanId(上面的1001和1002),所以如上圖,看似一次簡單的RPC過程,其實共產生了6條Span日誌,它們將在Zipkin服務端組裝成3個Span。
spring boot集成
pom引入
<!--增加zipkin的依賴 --> <dependency> <dependency> |
啓動文件增加引用 @EnableZipkinServer
@EnableZipkinServer @SpringBootApplication public class ServerZipkinApplication { public static void main(String[] args) { SpringApplication.run(ServerZipkinApplication.class, args); } } |
進入網址:http://127.0.0.1:9411/ 查看鏈路依賴關係,9411是服務端口號