使用 Spring Cloud Sleuth、Elastic Stack 和 Zipkin 作微服務監控

關於遷移微服務架構，最常被說起的挑戰莫過於監控。每一個微服務應獨立於其餘服務的運行環境，因此他們之間不會共享如數據源、日誌文件等資源。

然而，較容易的查看服務的調用歷史，而且可以查看多個微服務的請求傳播是微服務架構的重要需求。獲取服務日誌不是此問題的正確解決之道，因此這裏我要分享一些頗有幫助的第三方工具，以方便在建立微服務的時候應用，如Sping Boot和Spring Cloud。

Tools工具

• Spring Cloud Sleuth. 做爲Spring Cloud項目的庫之一，經過添加相關HTTP請求頭，記錄微服務隨後的調用過程。藉助於於MDC(映射診斷的上下文)，能夠輕易的獲取上下文中的值，並顯示在相關日誌中。

• Zipkin. 一款分佈式追蹤系統，用於收集每一個獨立服務請求的時間。有一個簡單的管理控制檯，可視化顯示服務調用的時間統計。

• Elastic Stack (ELK). Elasticsearch, Logstash, 及Kibana，一般三者一塊兒使用，用來實時查找、分析、可視乎日誌數據。

可能你之前沒有開發過Java或是微服務，但大家大部分的人都或許據說過Elasticsearch和Kibana。例如你在瀏覽Docker Hub時，你就會看到在流行的鏡像中不少項目使用到了上述工具。在咱們的案例中，我將使用這些鏡像。感謝Docker鏡像，讓我能輕易的在本機安裝徹底的Elastic Stack環境。接下來讓咱們開始Elasticsearch容器吧。

 

關於遷移微服務架構，最常被說起的挑戰莫過於監控。每一個微服務應獨立於其餘服務的運行環境，因此他們之間不會共享如數據源、日誌文件等資源。

然而，較容易的查看服務的調用歷史，而且可以查看多個微服務的請求傳播是微服務架構的重要需求。獲取服務日誌不是此問題的正確解決之道，因此這裏我要分享一些頗有幫助的第三方工具，以方便在建立微服務的時候應用，如Sping Boot和Spring Cloud。

 

docker run - d - it--name es - p 9200: 9200 - p 9300: 9300 - e "discovery.type=single-node" docker.elastic.co /  elasticsearch / elasticsearch: 6.1 .1

 

 

在開發模式下運行 Elasticsearch 最方便，由於咱們不須要提供額外的配置。若是你想在生產環境下啓動 ，須要將 Linux 核心配置項 vm.max_map_count 設置爲不小於 262144 的數。修改這個配置的過程在不一樣的操做系統下是不一樣的。若是在 Windows 下使用 Docker Toolbox，須要經過 docker-machine 來設置。 

docker - machine ssh
sudo sysctl - w vm.max_map_count = 262144

 

而後運行 Kibana 容器並將其鏈接到 Elasticsearch。

docker run - d - it--name kibana--link es: elasticsearch - p 5601: 5601 docker.elastic.co / kibana / kibana: 6.1 .1

 

最後咱們開啓聲明瞭輸入了輸出的 Logstash。咱們將輸入聲明爲 TCP，它在咱們的示例應用中是兼容 LogstashTcpSocketAppender 的日誌記錄器。Elasticsearch 被聲明爲輸出。每一個微服務的名稱都會被加上 micro 前綴並加入索引。Logstash 還有不少其它可用的輸入輸出插件，能夠在這裏查看[譯者注：這裏應該有一個連接，可是原文沒有加連接]。另外一個輸入方式是使用 RabbitMQ 和 Spring AMQPAppender，我在博文中說明了：如何在 Logstash、Elasticsearch 和 RabbitMQ 之間傳輸日誌。

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}"} }'

 

微服務

如今來看個微服務的示例。本文是我另外一篇博文——使用 Spring Cloud、Eureka 和 Zuul 建立微服務——的延續，其示例架構和使用的示例與前文相同。示例源代碼在 GitHub（logstash 分支）上。我曾經提到要使用 Logback 庫來向 Logstash 發送日誌數據。除了 Logback 的 3 個依賴庫，咱們還要添加用於 Zipkin 集成和 Spring Cloud Sleuth 入門的一些庫。下面是用於微服務的 pom.xml 代碼段：

<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 的 mdc、logLevel、message 等日誌字段。咱們還添加了一個服務名稱字段，用於 Elastic - 建立用於搜索的索引。

<appender name="STASH" class="net.logstash.logbackappender.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 註解。在這個例子中，我聲明瞭 AlwaysSampler  類，它會導出全部的span——不過還有其餘選擇，好比 PercentageBasedSampler 類，它會覆蓋span的一部分。

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

 

Kibana

以後，開始 ELK docker 容器，咱們須要運行咱們的微服務。這裏有 5 個Spring Boot 應用須要運行：

 

1.  discovery-service

2. account-service

3. customer-service

4. gateway-service

5. zipkin-service 

在推出全部這些服務以後，咱們能夠嘗試調用一些服務，例如，

http://localhost:8765/api/customer/customers/{id}

 它會對客戶賬戶服務進行調用。全部的日誌將會被存儲在 Elasticsearch 而且以 micro-%{serviceName} 爲索引。日誌能夠在 Kibana 工具中被搜索，這項功能能夠在 管理 -> 索引 中找到 模式。讓 Kibana 在  http://192.168.99.100:5601 中可用，並在以後運行它，輸入 micro-*，咱們會獲得一個索引模式的提示。在發現這個功能裏，咱們可讓咱們輸入的模式匹配日誌，並作一個時間線的虛擬化。

 

 

Kibana是一個至關直觀和用戶友好的工具。我不會詳細描述如何使用Kibana，由於你能夠輕鬆地經過查閱文檔或僅經過UI知道。最重要的是它可以經過過濾標準來搜索日誌。在下圖中，有一個經過檢索由Spring Cloud Sleuth添加到請求標題中的X-B3-TraceId字段來搜索日誌的示例。Sleuth還增長了X-B3-TraceId來標記單個微服務的請求。咱們能夠選擇在結果列表中展現哪些字段; 在本示例中，我選擇了message和和serviceName，以下圖的左側邊窗所示。

這是一張關於單個請求細節的截圖。在展開每一個日誌行以後它是可見的。

Zipkin

Spring Cloud Sleuth也能夠發送追蹤統計到Zipkin。這是相比存儲在Elastic Stack數據以外另一類數據。它們是針對每一個請求的計時統計。Zipkin UI很是簡潔。你能夠經過類如時間、服務名以及端點名稱這類查詢條件過濾 請求。

以下這張圖展現的與Kibana展現相同的請求 (http://localhost:8765/api/customer/customers/{id}).

咱們老是能夠經過單擊每一個請求查看它的明細。而後，你能夠看到相似下面這樣的圖片。一開始，這個請求被API網關處理，接着，網關發現Eureka服務器上的客戶服務並調用該服務。客戶服務也須要發現帳戶服務而後調用它。在這個視圖裏，你能夠很容易的發現哪一個操做是最耗時的。

 

總結

 

---

 

微服務系統顧名思義就是一組相對小而獨立的應用集。在你的系統裏微服務的數量沒有上限。他們的數量甚至能夠達到幾百上千。考慮到咱們所討論的上千的獨立應用，彼此能夠獨立啓動。因此，爲了成功監控如此龐大的系統，咱們必須得集中的收集、儲存日誌與追蹤數據。使用如Elastic Stack和Zipkin之類的工具，使得監控微服務的系統再也不是難事。固然也有一些其餘的工具，例如：Hystrix 和 Turbine,能夠針對全部傳入請求提供實時度量指標。