經過ZipKin整理調用鏈路

原因

公司使用的是Docker+微服務,服務拆分差很少41個了,而後過完年來就接到這個需求,把指定業務功能的業務基線整理出來,好比,登陸這個操做會通過哪些微服務,把登陸這個操做的鏈條列出來,從api--途徑的服務--DB這樣一個鏈條。接到這個需求後,我就傻逼似的一個一個去問開發,然而開發每一個人只負責本身開發的模塊,具體途徑的他們也不知道;而後一直拖一直拖,拖到了如今,總得找個辦法把這個給完成了,恰好公司有用到Zipkin這個,可是並不瞭解,只知道有這麼個東西,那就先了解他,而後根據他的數據庫和咱們本身的ELK操做日誌找到這些個調用鏈路。 

思路

ELK日誌會記錄操做日誌,日誌裏會把Zipkin的三個ID打印出來,好比我作一個登錄操做,經過Kibana顯示的ELK裏會有登錄這個操做的日誌,那我獲取這個登錄操做的SpanId,經過Zipkin的API接口和SpanId能夠獲取全部和這個SpanId有關的信息;而後根據獲取的信息把調用鏈給整理出來。 
 

Zipkin的相關了解

 
主要是根據寫篇博文學習;參考地址: http://www.javashuo.com/article/p-ycfoacoh-go.html 
 

1、Zipkin的由來sql

在單機系統使用過程當中,若是某個請求響應過慢或者響應出錯,經過查看日誌就能夠清楚的知道某個請求出了問題;若是在分佈式系統中,客戶端一個請求到達服務器後,由多個服務協做完成。如服務A調用服務B,服務B調用服務C,服務C調用服務D,那麼想要知道哪一個服務處理時間過長或是處理異常致使的話,就須要一個服務一個服務的去機器查看日誌,先定位出問題的服務,再定位出問題的地方。隨着系統愈來愈壯大,服務愈來愈多,一個請求對應處理的服務調用鏈就越長,這種排查方式很艱難,爲了解決這個問題,便誕生了各類分佈式場景中追蹤問題的解決方案,zipkin就是其中之一。
 

2、什麼是ZipKin數據庫

一個獨立的分佈式追蹤系統,客戶端存在於應用中(各個服務中),應具有追蹤信息生成,採集發送等功能,而服務端應該包含如下基本的三個功能
1)信息收集:用來收集各服務端採集的信息,並對這些信息進行梳理存儲、創建索引
2)數據存儲:存儲追蹤數據
3)查詢服務:提供查詢請求鏈路信息的接口
 
3、 它的總體結構圖
 
 
 
Zipkin(服務端)包含四個組件,分別是collector,storage,search,Web UI
1)collector信息收集器,做爲一個守護進程,它會時刻等待着客戶端傳遞過來的追蹤數據,對這些數據進程驗證,存儲以及建立查詢須要的索引
2)storage是存儲組件,zipkin默認直接將數據存儲在內存中,此外支持使用Cassandra、Elasticsearch和Mysql
3)search是一個查詢進程,它提供了簡單的JSON API來提供外部調用查詢
4)Web UI是zipkin的服務端展現平臺,主要調用search提供的接口,用圖標將鏈路信息清晰的展現
 
4、基本概念
 
Trace: 一個請求達到應用後所調用的全部服務組成的調用鏈就像一個樹結構(如圖),咱們追蹤這個調用鏈路獲得的這個數結構能夠稱之爲Trace
Span:在一次Trace中,每一個服務的每一次調用,就是一個基本工做單元(如圖中的每個樹節點),稱之爲span
 
 
 
每個span都有一個id做爲惟一標識,一樣每一次Trace都會生成一個traceID在span中做爲追蹤評標識,另外再經過一個parentId標明本次調用的發起者(就是發起者的span-id)。當span有了上面三個標識後,就能夠很清晰的將多個span進行梳理串聯,最終概括出一條完整的跟蹤鏈路。
 
 
5、實戰
 
1)根據指定的trace_id得到返回值,而後根據返回值分析調用鏈
 
curl http://localhost:9411/api/v2/trace/2e0d4019eb7aae31

 

2)獲取全部的服務
 
curl http://localhost:9411/api/v2/services

 

3)span數據結構詳解
 
一次追蹤鏈路會包含不少的span,所以一個span即是一個數組,標準的json爲:
 
[
  {
    "traceId": "string",    // 追蹤鏈路ID
    "name": "string",       // span名稱,通常爲方法名稱
    "parentId": "string",   // 調用者ID
    "id": "string",         // spanID
    "kind": "CLIENT",       // 替代zipkin v1的註解中的四個核心狀態,詳細介紹見下文
    "timestamp": 0,         // 時間戳,調用時間
    "duration": 0,          // 持續時間-調用的服務所消耗的時間
    "debug": true,          
    "shared": true,
    "localEndpoint": {      // 本地網絡節點上下文
      "serviceName": "string",
      "ipv4": "string",
      "ipv6": "string",
      "port": 0
    },
    "remoteEndpoint": {    // 遠端網絡節點上下文
      "serviceName": "string",
      "ipv4": "string",
      "ipv6": "string",
      "port": 0
    },
    "annotations": [      // value一般是縮寫代碼,對應的時間戳表示代碼標記事件的時間
      {
        "timestamp": 0,
        "value": "string"
      }
    ],
    "tags": {        // span的上下文信息,好比:http.method、http.path
      "additionalProp1": "string",
      "additionalProp2": "string",
      "additionalProp3": "string"
    }
  }
]

 

個人根據返回的json信息,並根據 traceId、 parentId、id、kind(CLINET、CLIENT)把誰調用誰,哪一個服務到哪一個服務整理出來:
 
 
6、有關Cassandra數據庫相關操做
 
1)鏈接數據庫
cqlsh 172.10.0.5

 

2)查看全部的庫
 
cqlsh> describe keyspaces;

 

3)使用指定的庫
cqlsh> use zipkin2;

 

4)查看全部的表
cqlsh> describe tables;

 

5)根據指定條件查詢
#查詢前得對查詢列創建索引
cqlsh:zipkin2> create index on span(trace_id);
cqlsh:zipkin2> select * from trace_by_service_span where trace_id='f81a638649326474';
相關文章
相關標籤/搜索