開源-解決方案-實時數據追蹤:Zipkin 介紹


ylbtech-開源-解決方案-實時數據追蹤:Zipkin 介紹

 

1.返回頂部
1、

介紹

Zipkin 是一款開源的分布式實時數據追蹤系統(Distributed Tracking System),基於 Google Dapper 的論文設計而來,由 Twitter公司開發貢獻。其主要功能是聚集來自各個異構系統的實時監控數據,用來追蹤微服務架構下的系統延時問題應用系統需要進行裝備(instrument)以向 Zipkin 報告數據。Zipkin 的用戶界面可以呈現一幅關聯圖表,以顯示有多少被追蹤的請求通過了每一層應用。Zipkin 以 Trace 結構表示對一次請求的追蹤,又把每個 Trace 拆分為若干個有依賴關系的 Span。在微服務架構中,一次用戶請求可能會由后台若干個服務負責處理,那么每個處理請求的服務就可以理解為一個 Span(可以包括 API 服務,緩存服務,數據庫服務以及報表服務等)。當然這個服務也可能繼續請求其他的服務,因此 Span 是一個樹形結構以體現服務之間的調用關系Zipkin 的用戶界面除了可以查看 Span 的依賴關系之外還以瀑布圖的形式顯示了每個 Span 的耗時情況可以一目了然的看到各個服務的性能狀況。打開每個 Span,還有更詳細的數據以鍵值對的形式呈現,而且這些數據可以在裝備應用的時候自行添加。

架構

    zipkin結構

        可以看到zipkin內部主要分為四部分:collector、storage、api、ui

            collector:負責將各系統報告過來的追蹤數據進行接收

            storage:默認使用Cassandra存儲數據,也可以替換為其他存儲,例如mysql5.6-5.7,ElasticSearch 2.x和5.x,還有一些第三方的存儲

            api:查詢服務用來向其他服務提供數據查詢的能力,是以json api格式提供

            ui:Web服務是官方默認提供的一個圖形用戶界面

    transport

        transport負責從運輸從service收集來的spans,並把這些spans轉化為zipkin的通用span,並將其傳遞到存儲層,這種方法是模塊化的,允許任何生產者接收任何類型的數據,zipkin配有HTTP、kafka、scribe三種類型的transport。instrumentations負責和transport進行交互。

    instrumentations

        官方維護

        ps:支持go、scala,這個不錯

        第三方維護

        ps:支持python,我就可以自己玩了,同時支持了四個Python庫,最基礎的是py_zipkin模塊,pyramid_zipkin、swagger_zipkin、flask_zipkin三個都是基於py_zipkin再次封裝的。

核心數據結構

            traceId:全局跟蹤ID,用它來標記一次完整服務調用,所以和一次服務調用相關的span中的traceId都是相同的,Zipkin將具有相同traceId的span組裝成跟蹤樹來直觀的將調用鏈路圖展現在我們面前。

            id:span的id,理論上來說,span的id只要做到一個traceId下唯一就可以

            parentId:父span的id,調用有層級關系,所以span作為調用節點的存儲結構,也有層級關系,就像圖3所示,跟蹤鏈是采用跟蹤樹的形式來展現的,樹的根節點就是調用調用的頂點,從開發者的角度來說,頂級span是從接入了Zipkin的應用中最先接觸到服務調用的應用中采集的。所以,頂級span是沒有parentId字段的

            name:span的名稱,主要用於在界面上展示,一般是接口方法名,name的作用是讓人知道它是哪里采集的span,不然某個span耗時高我都不知道是哪個服務節點耗時高

            timestamp:span創建時的時間戳,用來記錄采集的時刻。

            duration:持續時間,即span的創建到span完成最終的采集所經歷的時間,除去span自己邏輯處理的時間,該時間段可以理解成對於該跟蹤埋點來說服務調用的總耗時

            annotations:基本標注列表,一個標注可以理解成span生命周期中重要時刻的數據快照,比如一個標注中一般包含發生時刻(timestamp)、事件類型(value)、端點(endpoint)等信息

                事件類型

                        cs:客戶端/消費者發起請求

                        cr:客戶端/消費者接收到應答

                        sr:服務端/生產者接收到請求

                        ss:服務端/生產者發送應答

                    PS:這四種事件類型的統計都應該是Zipkin提供客戶端來做的,因為這些事件和業務無關,這也是為什么跟蹤數據的采集適合放到中間件或者公共庫來做的原因。

            binaryAnnotations:業務標注列表,如果某些跟蹤埋點需要帶上部分業務數據(比如url地址、返回碼和異常信息等),可以將需要的數據以鍵值對的形式放入到這個字段中。
    

參考

    zipkin官網

    分布式跟蹤系統(一):Zipkin的背景和設計

    分布式跟蹤系統(二):Zipkin的Span模型

2、
2.返回頂部
 
3.返回頂部
 
4.返回頂部
 
5.返回頂部
0、
1、
2、
 
6.返回頂部
 
warn 作者:ylbtech
出處:http://ylbtech.cnblogs.com/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM