分布式服務跟蹤 Sleuth

sleuth是基於logback實現資料跟蹤的。在預設情況下，sleuth是基於日誌向控制台輸出跟蹤內容。不利於管理，統計，檢視，分析。在控制台中輸出跟蹤內容會嚴重影響系統效能。如果將跟蹤資料記錄在logback對應的日誌檔案中，也有問題：logback是分散的，是整合在每個服務應用中的，那麼日誌檔案也是分散的， 也不利於跟蹤資訊的檢視，管理，分析。

所以sleuth提供了集中式的跟蹤資料儲存方案。可以使用elk來實現logback跟蹤資訊的收集，儲存。實質上是使用logstash來做資料的收集，用elasticsearch做資料的儲存，使用kibana做資料的檢視顯示。

使用elk收集跟蹤資料，必須依賴logback日誌工具，也就是必須提供logback.xml配置檔案，並且日誌級別建議調整為debug。

使用elk收集跟蹤資料結構圖

logstash中的配置內容：定義在$logstash_home/config/***.conf。本案例中的配置檔案命名為：log_to_es.conf。內容如下：其中input用於定義logstash對外提供的輸入配置；output用於定義logstash接收資料後的輸出配置，elasticsearch相關配置根據具體環境定義。

# for detail structure of this file

# set: 
input 
}filter 
output 
}

配置檔案配置完畢後，重新啟動logstash，啟動命令為：

$logstash_home/bin/logstash -f config/log_to_es.conf

上述命令是讓logstash啟動的時候載入自定義配置檔案，提供輸入及輸出配置。

} 修改所有需要採集跟蹤資訊的應用

增加sleuth相關依賴

org.springframework.cloud

spring-cloud-starter-sleuth
net.logstash.logback
logstash-logback-encoder
5.0

提供logback.xml配置檔案，並定義logstash相關輸出配置：其中logstash的輸出目的地destination需要根據具體環境配置。如果使用logstash集群，destination內的位址使用逗號『,』分割。

<?xml version="1.0" encoding="utf-8"?>			

$utf8
utc",
"span": "%x",
"exportable": "%x",
"pid": "$",
"thread": "%thread",
"class": "%logger",
"rest": "%message"
}

上述所有步驟操作完畢後，使用elk實現跟蹤資料收集的案例就改造完畢了，可以啟動並觀察elasticsearch中對應索引的內容。

使用圖形簡單解釋上述資料

分布式服務跟蹤Sleuth

作用 隨著業務的發展，系統規模也會變得越來越大，微服務間的呼叫關係也變得越來越錯綜複雜。通常由乙個客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果，在複雜的微服務架構系統中，幾乎每乙個前端請求都會形成乙個複雜的分布式服務呼叫鏈路，在每條鏈路中任何乙個依賴服務出現延遲過高...

分布式服務跟蹤Sleuth

隨著業務的發展,系統規模也會變得越來越大,各微服務間的呼叫關係也變得越來越錯綜複雜。通常乙個由客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果,在複雜的微服務架構系統中,幾乎每乙個前端請求都會形成一條複雜的分布式服務呼叫鏈路,在每條鏈路中任何乙個依賴服務出現延遲過高或錯...

sleuth服務跟蹤學習總結

springcloud提供了服務跟蹤元件，用於分析各個微服務間的呼叫關係 一次微服務呼叫，可能涉及多個微服務的呼叫。sleuth主要是通過在日誌中引入乙個id,來實現服務跟蹤的。並且這個id有兩種型別，trace id和 span id span id 代表工作的基本單元 如每次傳送的http請求 ...