分布式呼叫鏈跟蹤系統 Zipkin

官網、github

英語 tracer，***

概念 範疇：分布式呼叫鏈跟蹤系統，或分布式鏈路呼叫監控系統。

trace、span

zipkin 以 trace 結構表示對一次請求的追蹤，又把每個 trace 拆分為若干個有依賴關係的 span。

在微服務架構中，一次使用者請求可能會由後台若干個服務負責處理，那麼每個處理請求的服務就可以理解為乙個 span（可以包括 api 服務，快取服務，資料庫服務以及報表服務等）。當然這個服務也可能繼續請求其他的服務，因此 span 是乙個樹形結構，以體現服務之間的呼叫關係。

zipkin快速開始

隨著業務越來越複雜，系統也隨之進行各種拆分，特別是隨著微服務架構和容器技術的興起，看似簡單的乙個應用，後台可能有幾十個甚至幾百個服務在支撐；乙個前端的請求可能需要多次的服務呼叫最後才能完成；當請求變慢或者不可用時，我們無法得知是哪個後台服務引起的，這時就需要解決如何快速定位服務故障點，zipkin分布式跟蹤系統就能很好的解決這樣的問題。

***(tracer)位於你的應用程式中，並記錄發生的操作的時間和元資料,提供了相應的類庫，對使用者的使用來說是透明的，收集的跟蹤資料稱為span;

將資料傳送到zipkin的儀器化應用程式中的元件稱為reporter，reporter通過幾種傳輸方式之一將追蹤資料傳送到zipkin收集器(collector)，

然後將跟蹤資料進行儲存(storage)，由api查詢儲存以向ui提供資料。

1、trace

zipkin 使用 trace 結構表示對一次請求的跟蹤，一次請求可能由後台的若干服務負責處理，每個服務的處理是乙個span，span之間有依賴關係，trace就是樹結構的span集合；

每個服務的處理跟蹤是乙個span，可以理解為乙個基本的工作單元，包含了一些描述資訊：id，parentid，name，timestamp，duration，annotations等，例如：

,

"timestamp": 1458702548786000
,          "value": "cs"
}      ],
"binaryannotations": [}]
}

traceid：標記一次請求的跟蹤，相關的spans都有相同的traceid；

id：span id；

name：span的名稱，一般是介面方法的名稱；

parentid：可選的id，當前span的父span id，通過parentid來保證span之間的依賴關係，如果沒有parentid，表示當前span為根span；

timestamp：span建立時的時間戳，使用的單位是微秒（而不是毫秒），所有時間戳都有錯誤，包括主機之間的時鐘偏差以及時間服務重新設定時鐘的可能性，

出於這個原因，span應盡可能記錄其duration；

duration：持續時間使用的單位是微秒（而不是毫秒）；

annotations：注釋用於及時記錄事件；有一組核心注釋用於定義rpc請求的開始和結束；

1）、cs:client send，客戶端發起請求；

2）、sr:server receive，伺服器接受請求，開始處理；

3）、ss:server send，伺服器完成處理，給客戶端應答；

4）、cr:client receive，客戶端接受應答從伺服器；

binaryannotations：二進位制注釋，旨在提供有關rpc的額外資訊。

收集的spans必須從被追蹤的服務運輸到zipkin collector，有三個主要的傳輸方式：http, kafka和scribe；

有4個元件組成zipkin：collector，storage，search，web ui

collector：一旦跟蹤資料到達zipkin collector守護程序，它將被驗證，儲存和索引，以供zipkin收集器查詢；

storage：zipkin最初資料儲存在cassandra上，因為cassandra是可擴充套件的，具有靈活的模式，並在twitter中大量使用；但是這個元件可插入，除了cassandra之外，還支援elasticsearch和mysql；

search：一旦資料被儲存和索引，我們需要一種方法來提取它。查詢守護程序提供了乙個簡單的json api來查詢和檢索跟蹤，主要給web ui使用；

web ui：建立了乙個gui，為檢視痕跡提供了乙個很好的介面；web ui提供了一種基於服務，時間和注釋檢視跟蹤的方法。

分布式鏈路呼叫跟蹤系統

一.為什麼需要分布式呼叫跟蹤 隨著分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，系統架構變得越來越分散，如下圖所示 分布式服務拆分以後，系統變得日趨複雜，業務的呼叫鏈也越來越長，如何快速定位線上故障，就需要依賴分布式呼叫跟蹤技術。可以看到，隨著服務的拆分，系統的模組變得越來越多，不同的...

分布式系統呼叫鏈監控

乙個請求完整的呼叫鏈可能如下圖，經過多個系統服務，呼叫關係複雜。期間我們會關注各個呼叫的各項效能指標，比如吞吐量 tps 響應時間及錯誤記錄等。全鏈路效能監控從整體維度到區域性維度展示各項指標，將跨應用的所有呼叫鏈效能資訊集中展現，可方便度量整體和區域性效能，並且方便找到故障產生的源頭，生產上可極大...

skywalking分布式呼叫鏈

部署 elasticsearch 修改elasticsearch.yml檔案 設定 cluster.name collectordbcluster。此名稱需要和collector配置檔案一致。設定 node.name anyname，可以設定為任意名字，如elasticsearch為集群模式，則每個...