Zipkin是Twitter的一個開源項目，是一個緻力于收集Twitter所有服務的監控資料的分布式跟蹤系統，它提供了收集資料，和查詢資料兩大接口服務。
部署Zipkin環境的操作記錄：
部署Zipkin，比較麻煩的是前期環境的準備，隻有先把前期環境安裝好了，後面的部署就順利多了。（部署機ip為192.168.1.102）
一、環境準備：
-------------------------------------------------------------------------------------------
特别注意：現在安裝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
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 ~]# 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<code># Generated by iptables-save v1.4.21 on Wed Dec 7 20:10:51 2016</code>
<code>*raw</code>
<code>:PREROUTING ACCEPT [5603:1412953]</code>
<code>:OUTPUT ACCEPT [5269:1369985]</code>
<code>COMMIT</code>
<code># Completed on Wed Dec 7 20:10:51 2016</code>
<code>*mangle</code>
<code>:INPUT ACCEPT [5379:1395017]</code>
<code>:FORWARD ACCEPT [144:21528]</code>
<code>:POSTROUTING ACCEPT [5413:1391513]</code>
<code>*nat</code>
<code>:PREROUTING ACCEPT [62:4444]</code>
<code>:INPUT ACCEPT [14:760]</code>
<code>:OUTPUT ACCEPT [1:60]</code>
<code>:POSTROUTING ACCEPT [1:60]</code>
<code>-A PREROUTING -p tcp -m tcp --dport 9411 -j DNAT --to-destination 192.168.1.102:9411</code>
<code>-A POSTROUTING -d 192.168.1.102</code><code>/32</code> <code>-p tcp -m tcp --sport 9411 -j SNAT --to-</code><code>source</code> <code>192.168.1.17</code>
<code>*filter</code>
<code>:INPUT ACCEPT [7:3550]</code>
<code>:FORWARD ACCEPT [17:3786]</code>
<code>:OUTPUT ACCEPT [45:5785]</code>
<code>-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT</code>
<code>-A INPUT -p icmp -j ACCEPT</code>
<code>-A INPUT -i lo -j ACCEPT</code>
<code>-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT</code>
<code>-A INPUT -p tcp -m state --state NEW -m tcp --dport 9411 -j ACCEPT</code>
然後在谷歌浏覽器裡通路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（預設）
僅用于測試，因為采集資料不會持久化
預設使用這個存儲，若要使用其他存儲，檢視：
JDBC (mysql)
如果采集資料量很大的話，查詢速度會比較慢
Cassandra
zipkin最初始内建的存儲（擴充性好、schema靈活）
This store requires a spark job to aggregate dependency links
Elasticsearch
被設計用于大規模
存儲形式為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。
整個鍊路的依賴關系如下:
完成鍊路調用的記錄後，如何來計算調用的延遲呢，這就需要利用<code>Annotation</code>資訊：
總結兩點：
1）使用zipkin，必須使用java8
2）在生産環境，不會對每個請求都進行采樣追蹤（降低trace對整個服務的性能損耗）
***************當你發現自己的才華撐不起野心時，就請安靜下來學習吧***************
本文轉自散盡浮華部落格園部落格，原文連結：http://www.cnblogs.com/kevingrace/p/5570258.html，如需轉載請自行聯系原作者