傳送門：SpringCloud版本Hoxton SR5 --- 第一講：認識 先看Sleuth、Zipkin、Elasticsearch 可以完成的功能，或者說他在項目中的定位和作用。
Sleuth比較正式的一些功能描述：（上面那篇文章也有舉例說明）
spring Cloud Sleuth爲 spring Cloud提供了分佈式跟蹤的解決方案，它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的設計，先來了解一下 Sleuth的術語， Sleuth借用了 Dapper的術語。
span（跨度）：基本工作單元。 span用一個64位的id唯一標識。除ID外，span還包含其他數據，例如描述、時間戳事件、鍵值對的註解（標籤）， spanID、span父 ID等。 span被啓動和停止時，記錄了時間信息。初始化 span被稱爲"rootspan"，該 span的 id和 trace的 ID相等。
trace（跟蹤）：一組共享"rootspan"的 span組成的樹狀結構稱爲 traceo trac也用一個64位的 ID唯一標識， trace中的所有 span都共享該 trace的 ID
annotation（標註）： annotation用來記錄事件的存在，其中，核心annotation用來定義請求的開始和結束。
CS（ Client sent客戶端發送）：客戶端發起一個請求，該 annotation描述了span的開 始。
SR（ server Received服務器端接收）：服務器端獲得請求並準備處理它。如果用 SR減去 CS時間戳，就能得到網絡延遲。c)
SS（ server sent服務器端發送）：該 annotation表明完成請求處理（當響應發回客戶端時）。如果用 SS減去 SR時間戳，就能得到服務器端處理請求所需的時間。
CR（ Client Received客戶端接收）： span結束的標識。客戶端成功接收到服務器端的響應。如果 CR減去 CS時間戳，就能得到從客戶端發送請求到服務器響應的所需的時間
上面的這些功能，不是很理解，暫時就不說了。
最上面的那個鏈接其實已經說了Sleuth 和 Zipkin分別完成的功能，這裏就再詳細的提一嘴：
都知道，當我們再單體項目中一臺服務器跑遍整個項目，日誌這一塊可以直接查看。但是微服務架構不行，因爲相同功能的項目，可能會部署到10臺服務器上，然後調用的時候，通過Ribbon負載均衡決定到底調用哪一臺服務器完成調用功能。這時候如果要看日誌，通常情況下，是不是A服務調B服務，但是B服務有10臺服務器，你怎麼知道調用的是哪臺服務器？日誌也可以看，但是微服務更多呢？頻繁的切換服務器查看日誌，你不吐，我都要看吐。
所以這時候出現一個技術：Spring Cloud Sleuth(鏈路跟蹤)，他有一個Trace Id，當第一個調用傳入服務器的時候，他就給這個調用設置一個Trace ID，然後當這個調用繼續訪問其他服務器的時候，Sleuth就讓這個Trace ID跟着這個調用接口傳遞下去，這樣就能清晰的獲取到每一個請求經過了哪些服務器，調用了哪些接口。
還沒完，還有一個Span ID，當所有的微服務都整合了SpringCloud Sleuth之後，一個請求過來，調用到的每個服務器接口的時候都會生成一個Span ID,如果每個Span ID的生成時間相減，是不是就可以獲取調用過程的時間 ？程序員就可以通過展示的時間，來判斷某個接口是不是需要優化。
所以：Sleuth的作用主要就是標記請求的調用鏈、獲取每個請求調用開始時間。
上面我們知道了每個請求的調用經過的服務器和調用的接口，還有每個調用開始的時間，但是上面僅僅是採集數據。當我們採集到數據之後，我們還需要將這些數據通過Zipkin的客戶端發送給Zipkin服務端。而Zipkiin服務端拿到數據之後，就通過Trace ID開始整合，將Trace ID相同的數據整合到一起，並根據Span ID創建的時間，計算出每個服務、組件之間調用的時間，然後通過Zipkiin提供的UI界面，提供查詢功能，顯示出來。你以爲就大功告成了 ？還沒有。
作爲程序員都知道，健壯性、高可用是必不可少的。Zipkin雖然整合了數據，並提供了UI界面，但是所有數據都是保存在內存中的。他沒有持久化到硬盤。所以當Zipkin重啓之後，所有數據都會立即清空。所以需要將這些日誌信息保存到硬盤中，這時候使用官方提供的Elasticsearch持久化日誌信息。（Zipkiin整合Elasticsearch很簡單，將Elasticsearch的連接地址交給Zipkini，然後啓動Zipkin就好了）
到這裏，幾乎可以說，大功告成了，但是實際開發中，通常會用到rabbitmq、kafka這種通訊工具。所以需要打印使用mq的日誌，就需要Zipkin整合mq（Zipkin自己提供了整合，但是mq的連接地址、用戶名、密碼，你需要交給Zipkin）
現在就正式開始：
客戶端：
每一個調用的需要打印日誌的微服務都需要做如下操作：
添加依賴：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
每一個調用的需要打印日誌的微服務都需要在配置文件添加如下配置：
spring:
##################################################### zipkin ########################################################
zipkin:
base-url: http://47.**.1**.61:9411/ #指定Zipkin server地址
############################################### Spring cloud sleuth #################################################
sleuth:
sampler:
probability: 1.0 #request採樣的數量 默認是0.1 也即是10% 顧名思義 採取10%的請求數據 因爲在分佈式系統中，數據量可能會非常大，因此採樣非常重要。這裏暫時設置爲全部採集。
好了沒有，就這麼簡單。
服務端：Zipkin的服務端，官網建議直接使用它提供的jar包，或者他提供的docker鏡像進行部署。
我是使用的Docker'鏡像，下面的鏈接直接跳轉Docker運行Zipkin的服務端：
Zipkin服務端部署及整合RabbitMq傳送門：Docker運行Zipkin-Server、整合rabbitmq
爲了將日誌信息持久化，提供下面的鏈接：
Zipkin整合Elasticsearch傳送門：docker之Elasticsearch鏡像安裝及運行、整合Zipkin
到這裏Spring Cloud Sleuth 的使用，就完成了。