1、背景
上了 springboot 微服務框架后會有很多微服務，每次都到單個微服務自己的日志海洋里去找需要很大經理，
日志跟蹤就會成為一個麻煩。我們嘗試來尋找一個簡化方案
2、了解 Sleuth
SpringCloud Sleuth主要功能就是在分布式系統中提供追蹤解決方案。它大量借用了Google Dapper的設計， 先來了解一下Sleuth中的術語和相關概念。
官網：https://spring.io/projects/spring-cloud-sleuth
一些概念：
- Trace
由一組Trace Id相同的Span串聯形成一個樹狀結構。為了實現請求跟蹤，當請求到達分布式系統的入口端點時，只需要服務跟蹤框架為該請求創建一個唯一的標識（即TraceId） - Span
代表了一組基本的工作單元。為了統計各處理單元的延遲，當請求到達各個服務組件的時候，也通過一個唯一標識（SpanId）來標記它的開始、具體過程和結束。 - Annotation
用它記錄一段時間內的事件，內部使用的重要注釋
如何使用
Sleuth 的使用及其簡單，直接引入一個依賴即可。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
日志參數詳解：
我們隨便在一個服務里面打印日志，可以在控制臺觀察到sleuth的日志輸出：
[product-service,d1e92e984eaec1ff,d1e92e984eaec1ff,true]
四個值分別表示：[ 服務名，Trace ID，spanID，是否輸出 ]
- 服務名。即spring.application.name 的值
- Trace ID。d1e92e984eaec1ff，sleuth生成的一個ID，叫Trace ID，用來標識一條請求鏈路，一條請求鏈路中包含一個Trace ID，多個Span ID
- spanID 。d1e92e984eaec1ff、spanID 基本的工作單元，獲取元數據，如發送一個http
- true，是否要將該信息輸出到zipkin服務中來收集和展示。
然后，為了方便可視化展示和全文檢索，可通過 Zipkin 將日志聚合展示。
3、了解 zipkin
Zipkin 是一個分布式追蹤系統。它有助于收集解決服務架構中的延遲問題所需的時間數據。功能包括收集和查找此數據。
Zipkin 是 Twitter 的一個開源項目，它基于Google Dapper實現，它致力于收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據，并通過它提供的REST API接口來輔助我們查詢跟蹤數據以實現對分布式系統的監控程序，從而及時地發現系統中出現的延遲升高問題并找出系統性能瓶頸的根源。除了面向開發的 API 接口之外，它也提供了方便的UI組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細，比如：可以查詢某段時間內各用戶請求的處理時間等。
Zipkin 提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。
它主要由 4 個核心組件構成：
Collector：收集器組件，它主要用于處理從外部系統發送過來的跟蹤信息，將這些信息轉換為Zipkin內部處理的 Span 格式，以支持后續的存儲、分析、展示等功能。
Storage：存儲組件，它主要對處理收集器接收到的跟蹤信息，默認會將這些信息存儲在內存中，我們也可以修改此存儲策略，通過使用其他存儲組件將跟蹤信息存儲到數據庫中。
RESTful API：API 組件，它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息，或是外接系統訪問以實現監控等。
Web UI：UI 組件， 基于API組件實現的上層應用。通過UI組件用戶可以方便而有直觀地查詢和分析跟蹤信息。
Zipkin分為兩端，一個是 Zipkin服務端，一個是 Zipkin客戶端，客戶端也就是微服務的應用。 客戶端會配置服務端的 URL 地址，一旦發生服務間的調用的時候，會被配置在微服務里面的 Sleuth 的監聽器監聽，并生成相應的 Trace 和 Span 信息發送給服務端。
java 獲取并運行
curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
docker運行
docker run -d -p 9411:9411 openzipkin/zipkin
打開 http://localhost:9411 訪問。
