微服務內建SPRING CLOUD SLEUTH、ELK 和 ZIPKIN 進行監控-spring cloud 入門教程

與建立基于微服務的架構相關的最常提到的挑戰之一是監控。每個微服務都應該在與其他微服務隔離的環境中運作，是以它不會與它們共享資料庫或日志檔案等資源。然而，微服務架構的基本要求是相對容易通路調用曆史，包括能夠檢視多個微服務之間的請求傳播。Grepping 日志不是該問題的正确解決方案。在使用 Spring Boot 和 Spring Cloud 架構建立微服務時，可以使用一些有用的工具，比如：Spring Cloud Sleuth，Zipkin 。

Spring Cloud Sleuth – 作為 Spring Cloud 項目的一部分提供的庫。允許您通過向 HTTP 請求添加适當的标頭來跟蹤後續微服務的進度。該庫基于 MDC（Mapped Diagnostic Context）概念，您可以在其中輕松提取放入上下文的值并将其顯示在日志中。

Zipkin – 分布式跟蹤系統，有助于為在獨立服務之間傳播的每個請求收集計時資料。它有簡單的管理控制台，我們可以在其中找到後續服務生成的時間統計的可視化報告。

ELK – Elasticsearch、Logstash、Kibana：通常一起使用的三種不同工具。它們用于實時搜尋、分析和可視化日志資料。

關于ELK更多内容請參閱作者的Elasticsearch從入門到精通 Kibana從入門到精通 logstash快速入門實戰指南

可能很多人，即使您之前沒有接觸過 Java 或微服務，也聽說過 Logstash 和 Kibana。例如，如果您在hub.docker.com中檢視最流行的images，您會發現上述工具。在我們的示例中，我們将使用這些工具。讓我們從使用 Elasticsearch 運作容器開始。

docker run -d -it --name es -p 9200:9200 -p 9300:9300 elasticsearch      

我們可以運作 Kibana 容器并将其連結到 Elasticsearch。

docker run -d -it --name kibana --link es:elasticsearch -p 5601:5601 kibana      

最後，我們将啟動 Logstash，并聲明輸入和輸出。作為輸入，我們聲明 TCP，它與

LogstashTcpSocketAppender

在我們的示例應用程式中用作日志附加程式相容。作為輸出，elasticsearch 已被聲明。每個微服務都将以其名稱為索引，并帶有micro字首。

docker run -d -it --name logstash -p 5000:5000 logstash -e 'input { tcp { port => 5000 codec => "json" } } output { elasticsearch { hosts => ["192.168.99.100"] index => "micro-%{serviceName}"} }'      

現在我們可以看看示例微服務。這篇文章是我之前文章使用 Zuul、Ribbon、Feign、Eureka 和 Sleuth、Zipkin 建立簡單spring cloud微服務用例-spring cloud 入門教程的延續。體系結構和公開的服務與前一個示例中的相同。就像之前提到的，我們将使用 Logback 庫将日志資料發送到 Logstash。 除了三個 Logback 依賴項之外，我們還添加了用于 Zipkin 內建和 Spring Cloud Sleuth starter 的庫。這是微服務的pom.xml片段。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

< dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-starter-sleuth</ artifactId > </ dependency > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-sleuth-zipkin</ artifactId > </ dependency > < dependency > < groupId >net.logstash.logback</ groupId > < artifactId >logstash-logback-encoder</ artifactId > < version >4.9</ version > </ dependency > < dependency > < groupId >ch.qos.logback</ groupId > < artifactId >logback-classic</ artifactId > < version >1.2.3</ version > </ dependency > < dependency > < groupId >ch.qos.logback</ groupId > < artifactId >logback-core</ artifactId > < version >1.2.3</ version > </ dependency >

Logback 配置檔案位于src/main/resources目錄下 。下面展現的是logback.xml檔案内容片段。我們可以配置哪些日志字段發送到Logstash，我們還附加服務名稱字段到索引中。

24 25

< appender name = "STASH" class = "net.logstash.logback.appender.LogstashTcpSocketAppender" > < destination >192.168.99.100:5000</ destination > < encoder class = "net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder" > < providers > < mdc /> < context /> < logLevel /> < loggerName /> < pattern > < pattern > { "serviceName": "account-service" } </ pattern > </ pattern > < threadName /> < message /> < logstashMarkers /> < stackTrace /> </ providers > </ encoder > </ appender >

Spring Cloud Sleuth 的配置非常簡單。我們隻需要将

spring-cloud-starter-sleuth

依賴添加到pom.xml，在采樣的類上聲明 

@Bean

。

@Bean public AlwaysSampler defaultSampler() { return new AlwaysSampler(); }

啟動 ELK docker 容器後，我們需要運作我們的微服務。有 5 個 Spring Boot 應用程式需要運作discovery-service、account-service、customer-service、gateway-service和zipkin-service。全部啟動後，我們可以嘗試調用一些服務，例如http://localhost:8765/api/customer/customers/ {id}，這會導緻客戶和帳戶服務的調用。所有日志都将存儲在帶有micro-%{serviceName}索引的elasticsearch 中。可以使用micro-*索引模式在 Kibana 中搜尋它們。索引模式在 Kibana 中的管理部分下建立->索引模式（Management -> Index patterns）。Kibana 的通路位址http://192.168.99.100:5601。第一次運作後，我們會提示輸入索引模式，是以讓我們輸入micro-*。在“Discover（發現）”部分下，我們可以通過時間線可視化檢視所有比對類型模式的日志。

Kibana 是相當直覺且使用者友好的工具。Kibana 的使用方法我就不詳細介紹了，你自己看文檔或者直接點選 UI 就可以很容易地找到了。最重要的是能夠通過過濾條件搜尋日志。下圖中有一個通過X-B3-TraceId字段搜尋日志的示例，該字段由 Spring Cloud Sleuth 添加到請求頭中。Sleuth 還添加了X-B3-SpanId來标記單個微服務的請求。我們可以選擇在結果清單中顯示哪個字段——在這個示例中，我選擇了message和serviceName，就像您在圖檔的左窗格中看到的那樣。

這是帶有單個請求詳細資訊的圖檔。展開每個日志行後可見。

Spring Cloud Sleuth 還将統計資訊發送到 Zipkin。這是另一種資料報告形式，而不是存儲在 Logstash 中。它展現的是每個請求的計時統計資訊。Zipkin UI 非常簡單。您可以按時間、服務名稱、端點名稱等條件過濾請求。這是使用 Kibana 可視化的具有相同請求的圖檔：http://localhost:8765/api/customer/customers/ {id}。

我們始終可以通過單擊來檢視每個請求的詳細資訊。然後你會看到類似于下面可見的圖檔。一開始，請求已經在 API 網關上進行了處理。然後網關在 Eureka 伺服器上發現客戶服務并調用該服務。客戶服務也必須發現帳戶服務，然後調用它。在此視圖中，您可以輕松找出最耗時的操作。

使用 Zuul、Ribbon、Feign、Eureka 和 Sleuth、Zipkin 建立簡單spring cloud微服務用例-spring cloud 入門教程

微服務內建SPRING CLOUD SLEUTH、ELK 和 ZIPKIN 進行監控-spring cloud 入門教程

使用Hystrix 、Feign 和 Ribbon建構微服務-spring cloud 入門教程

使用 Spring Boot Admin 監控微服務-spring cloud 入門教程

基于Redis做Spring Cloud Gateway 中的速率限制實踐-spring cloud 入門教程

內建SWAGGER2服務-spring cloud 入門教程

Hystrix 簡介-spring cloud 入門教程

Hystrix 原理深入分析-spring cloud 入門教程 

使用Apache Camel建構微服務-spring cloud 入門教程

內建 Kubernetes 來建構微服務-spring cloud 入門教程

內建SPRINGDOC OPENAPI 的微服務實踐-spring cloud 入門教程

SPRING CLOUD 微服務快速指南-spring cloud 入門教程

基于GraphQL的微服務實踐-spring cloud 入門教程

最火的Spring Cloud Gateway 為經過身份驗證的使用者啟用速率限制實踐-spring cloud 入門教程