Zipkin是Twitter的一個開源專案，是一個致力於收集Twitter所有服務的監控資料的分散式跟蹤系統，它提供了收集資料，和查詢資料兩大介面服務。
部署Zipkin環境的操作記錄：
部署Zipkin，比較麻煩的是前期環境的準備，只有先把前期環境安裝好了，後面的部署就順利多了。（部署機ip為192.168.1.102）
一、環境準備：
1）java環境安裝（Centos中yum方式安裝java）
-------------------------------------------------------------------------------------------
特別注意：現在安裝zipkin，必須使用java8（即java-1.8.0-openjdk）
[root@wutao2 ~]# java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b15)
OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)
最後別忘了新增jdk的環境變數
[root@dev ~]# vim /etc/profile
......
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk.x86_64
export CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export PATH=$PATH:$JAVA_HOME/bin
[root@dev ~]# source /etc/profile
--------------------------------------------------------------------------------------------
2）npm環境安裝
隨同NodeJS一起安裝的包管理工具
這個國內目前知道的只有淘寶有。
[root@dev ~]# alias npm="npm --registry=https://registry.npm.taobao.org --disturl=https://npm.taobao.org/mirrors/node"
3）node環境安裝（版本：V5.5.0）
[root@dev ~]# yum install npm -y
[root@dev ~]# git clone https://github.com/creationix/nvm.git /usr/local/nvm
[root@dev ~]# source /usr/local/nvm/install.sh
[root@dev ~]# nvm --version
[root@dev ~]# nvm install v5.5.0
-----------------------------------------------------------------
出現如下報錯：
[root@dev nvm]# nvm install v5.5.0
-bash: nvm_has: command not found
-bash: nvm_has: command not found
nvm needs curl or wget to proceed.
解決辦法：
在當前使用者家目錄的.bash_profile檔案中新增如下內容
[root@dev ~]# cat /root/.bash_profile
.....
export NVM_DIR="/usr/local/nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
[root@dev ~]# source /root/.bash_profile
然後再次執行下面命令就不會出現上面報錯了：
[root@dev ~]# nvm install v5.5.0
-----------------------------------------------------------------
二、Zipkin安裝部署：（zipkin專案的git地址：https://github.com/twitter/zipkin）
[root@dev ~]# wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec'
其為一個spring boot 工程，直接執行jar
[root@dev ~]# nohup java -jar zipkin.jar & //回車，放到後臺去執行
[root@dev ~]# lsof -i:9411
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 8440 root 33u IPv6 64454 0t0 TCP *:9411 (LISTEN)
zipkin訪問：
由於zipkin部署機192.168.1.102是一臺虛擬機器，沒有外網ip。
所以通過它的宿主機（113.10.77.99/192.168.1.17）的NAT轉發進行訪問。
即訪問宿主機的9411埠轉發到192.168.1.102的9411埠
在宿主機192.168.1.17上的操作：（由於是單機，所以是192.168.1.102/32）
[root@linux-node2 ~]# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 9411 -j DNAT --to-destination 192.168.1.102:9411
[root@linux-node2 ~]# iptables -t nat -A POSTROUTING -d 192.168.1.102/32 -p tcp -m tcp --sport 9411 -j SNAT --to-source 192.168.1.17
[root@linux-node2 ~]# iptables -t filter -A INPUT -p tcp -m state --state NEW -m tcp --dport 9411 -j ACCEPT
[root@linux-node2 ~]# service iptables save
[root@linux-node2 ~]# service iptables restart
可以檢視iptables防火牆配置檔案：
[root@linux-node2 ~]# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.21 on Wed Dec 7 20:10:51 2016 *raw :PREROUTING ACCEPT [5603:1412953] :OUTPUT ACCEPT [5269:1369985] COMMIT # Completed on Wed Dec 7 20:10:51 2016 # Generated by iptables-save v1.4.21 on Wed Dec 7 20:10:51 2016 *mangle :PREROUTING ACCEPT [5603:1412953] :INPUT ACCEPT [5379:1395017] :FORWARD ACCEPT [144:21528] :OUTPUT ACCEPT [5269:1369985] :POSTROUTING ACCEPT [5413:1391513] COMMIT # Completed on Wed Dec 7 20:10:51 2016 # Generated by iptables-save v1.4.21 on Wed Dec 7 20:10:51 2016 *nat :PREROUTING ACCEPT [62:4444] :INPUT ACCEPT [14:760] :OUTPUT ACCEPT [1:60] :POSTROUTING ACCEPT [1:60] -A PREROUTING -p tcp -m tcp --dport 9411 -j DNAT --to-destination 192.168.1.102:9411 -A POSTROUTING -d 192.168.1.102/32 -p tcp -m tcp --sport 9411 -j SNAT --to-source 192.168.1.17 COMMIT # Completed on Wed Dec 7 20:10:51 2016 # Generated by iptables-save v1.4.21 on Wed Dec 7 20:10:51 2016 *filter :INPUT ACCEPT [7:3550] :FORWARD ACCEPT [17:3786] :OUTPUT ACCEPT [45:5785] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 9411 -j ACCEPT COMMIT # Completed on Wed Dec 7 20:10:51 2016
然後在谷歌瀏覽器裡訪問http://113.10.77.99:9411/，即可看到zipkin的web頁面了
三、Zipkin功能解說
zipkin作用
全鏈路追蹤工具（根據依賴關係）
檢視每個介面、每個service的執行速度（定位問題發生點或者尋找效能瓶頸）
zipkin工作原理
創造一些追蹤識別符號（tracingId，spanId，parentId），最終將一個request的流程樹構建出來
zipkin架構
其中：
Collector接收各service傳輸的資料；
Cassandra作為Storage的一種，也可以是mysql等，預設儲存在記憶體中，配置cassandra可以參考這裡；
Query負責查詢Storage中儲存的資料,提供簡單的JSON API獲取資料，主要提供給web UI使用；
Web 提供簡單的web介面；
zipkin分散式跟蹤系統的目的：
zipkin為分散式鏈路呼叫監控系統，聚合各業務系統呼叫延遲資料，達到鏈路呼叫監控跟蹤；
zipkin通過採集跟蹤資料可以幫助開發者深入瞭解在分散式系統中某一個特定的請求時如何執行的；
假如我們現在有一個使用者請求超時，我們就可以將這個超時的請求呼叫鏈展示在UI當中；我們可以很快度的定位到導致響應很慢的服務究竟是什麼。如果對這個服務細節也很很清晰，那麼我們還可以定位是服務中的哪個問題導致超時；
zipkin系統讓開發者可通過一個Web前端輕鬆的收集和分析資料，例如使用者每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。
例如下圖：
在複雜的呼叫鏈路中假設存在一條呼叫鏈路響應緩慢，如何定位其中延遲高的服務呢？
1）日誌：通過分析呼叫鏈路上的每個服務日誌得到結果
2）zipkin：使用zipkin的web UI可以一眼看出延遲高的服務
各業務系統在彼此呼叫時，將特定的跟蹤訊息傳遞至zipkin,zipkin在收集到跟蹤資訊後將其聚合處理、儲存、展示等，使用者可通過web UI方便
獲得網路延遲、呼叫鏈路、系統依賴等等。
transport作用：收集被trace的services的spans，並將它們轉化為zipkin common Span，之後把這些Spans傳遞的儲存層。
有三種主要的transport：
HTTP（預設）
通過http headers來傳遞追蹤資訊
header中的key
X-B3-TraceId: 64 encoded bits（id被encode為hex Strings）
X-B3-SpanId: 64 encoded bits
X-B3-ParentSpanId: 64 encoded bits
X-B3-Sampled: Boolean (either “1” or “0”)（下面的呼叫是否進行取樣）
X-B3-Flags: a Long
Scribe
Kafka
zipkin基礎架構（4個元件：collector、storage、search、webUI）
collector
作用：zipkin collector會對一個到來的被trace的資料（span）進行驗證、儲存並設定索引。
storage
in-memory（預設）
僅用於測試，因為採集資料不會持久化
預設使用這個儲存，若要使用其他儲存，檢視：
https://github.com/openzipkin/zipkin/tree/master/zipkin-server
https://github.com/openzipkin/zipkin-dependencies
JDBC (mysql)
如果採集資料量很大的話，查詢速度會比較慢
Cassandra
zipkin最初始內建的儲存（擴充套件性好、schema靈活）
This store requires a spark job to aggregate dependency links
Elasticsearch
This store requires a spark job to aggregate dependency links
被設計用於大規模
儲存形式為json
search
webUI
zipkin核心資料結構
Annotation（用途：用於定位一個request的開始和結束，cs/sr/ss/cr含有額外的資訊，比如說時間點）
cs：Client Start,表示客戶端發起請求
一個span的開始
sr：Server Receive,表示服務端收到請求
ss：Server Send,表示服務端完成處理，並將結果傳送給客戶端
cr：Client Received,表示客戶端獲取到服務端返回資訊
一個span的結束
當這個annotation被記錄了，這個RPC也被認為完成了
BinaryAnnotation（用途：提供一些額外資訊，一般已key-value對出現）
Span：一個請求（包含一組Annotation和BinaryAnnotation）；它是基本工作單元，一次鏈路呼叫(可以是RPC，DB等沒有特定的限制)建立一個span，通過一個64位ID標識它。
span通過還有其他的資料，例如描述資訊，時間戳，key-value對的(Annotation)tag資訊，parent-id等,其中parent-id
可以表示span呼叫鏈路來源，通俗的理解span就是一次請求資訊
Trace：類似於樹結構的Span集合，表示一條呼叫鏈路，存在唯一標識
Traces are built by collecting all Spans that share a traceId
通過traceId、spanId和parentId，被收集到的span會匯聚成一個tree，從而提供出一個request的整體流程。（這也是zipkin的工作原理）
注意：時間點計算
sr-cs：網路延遲
ss-sr：邏輯處理時間
cr-cs：整個流程時間
Trace identifiers
含義：通過下邊3個Id，對資料進行重組
三個Id（64位 long型資料）
TraceId
The overall ID of the trace.
Every span in a trace will share this ID.
SpanId
The ID for a particular span.
This may or may not be the same as the trace id.
ParentId
This is an optional ID that will only be present on child spans.
That is the span without a parent id is considered the root of the trace.
zipkin工作流程圖（完整的呼叫鏈路）
上圖說明：X和A可以相等
上圖表示一請求鏈路，一條鏈路通過Trace Id唯一標識，Span標識發起的請求資訊，各span通過parent id關聯起來；
父子span關係：
說明：parentId==null，表示該span就是root span。
整個鏈路的依賴關係如下:
完成鏈路呼叫的記錄後，如何來計算呼叫的延遲呢，這就需要利用Annotation資訊：
總結兩點：
1）使用zipkin，必須使用java8
2）在生產環境，不會對每個請求都進行取樣追蹤（降低trace對整個服務的效能損耗）