Spring Cloud Sleuth為Spring Cloud實現了分布式鏈路跟蹤解決方案。也引入了Google論文 Dapper 中的術語。
Span：基本工作單元，例如，發送RPC是一個新的span，就像向RPC發送響應一樣，Span由span的唯一64位ID標識，另一個64位ID標識其所屬的Trace。Span還有其他數據，例如描述、帶時間戳的事件、鍵值annotations（標簽），導致它們的span的ID以及進程ID（通常是IP地址）。
span可以啟動和停止，它們可以跟蹤自己的時間信息，創建span后，必須在將來的某個時刻停止它。
啟動Trace的初始span稱為 root span ，該span的ID值等於trace ID。
Trace：一組span形成的樹狀結構，例如，如果運行分布式大數據存儲，則可能由 PUT 請求形成trace。
Annotation：用於及時記錄事件的存在，使用 Brave 工具，不再需要為 Zipkin 設置特殊的事件來了解客戶端和 服務器 是誰、請求在哪里開始以及在哪里結束，然而，出於學習目的，標記這些事件以突出發生了什么類型的操作。
- cs ：Client Sent，客戶端發起了一個請求，這個annotation表示span的開始。
- sr ：Server Received，服務器端獲得了請求並開始處理它，從此時間戳中減去
cs時間戳會顯示網絡延遲。 - ss ：Server Sent，在請求處理完成時注釋（當響應被發送回客戶端時），從此時間戳中減去
sr時間戳會顯示服務器端處理請求所需的時間。 - cr ：Client Received，表示span的結束，客戶端已成功從服務器端收到響應，從此時間戳中減去
cs時間戳會顯示客戶端從服務器接收響應所需的全部時間。
下圖顯示了系統中的 Span 和 Trace ，以及Zipkin annotations：
標記的每種顏色表示一個span（有七個span — 從 A 到 G ），請考慮以下標記：
Trace Id = X Span Id = D Client Sent
此標記表示當前span的 Trace Id 設置為 X ， Span Id 設置為 D ，此外，還發生了 Client Sent 事件。
下圖顯示了span的父—子關系：
實際項目中若已引入Spring Could sleuth包，則默認會在打印日志時輸出traceId、spanId等內容，若它調用一個也是用Spring Could sleuth的服務，則會自動傳遞traceId
類似這種traceId的傳遞操作，在服務內多采用ThreadLocal或MDC的方式，在分布式微服務時一般在request header或url參數中傳遞。