分布式鏈路跟蹤 Sleuth 與 Zipkin【Finchley 版】


 

Spring Cloud Sleuth

Span是基本的工作單位。 例如,發送 RPC是一個新的跨度,就像向RPC發送響應一樣。 跨度由跨度唯一的64位ID和跨度所包含的另一個64位ID標識。 Spans還有其他數據,例如描述,鍵值注釋,導致它們的跨度的ID以及進程ID(通常為IP地址)。 跨度啟動和停止,並且他們跟蹤他們的時間信息。 一旦你創建了一個跨度,你必須在將來某個時候停止它。 一組Spans形成一個叫做Trace的樹狀結構。 例如,如果您正在運行分布式大數據存儲,則跟蹤可能由放入請求組成。

一般的,一個分布式服務跟蹤系統主要由三部分構成:數據收集數據存儲數據展示

根據系統大小不同,每一部分的結構又有一定變化。譬如,對於大規模分布式系統,數據存儲可分為實時數據和全量數據兩部分,實時數據用於故障排查(Trouble Shooting),全量數據用於系統優化;數據收集除了支持平台無關和開發語言無關系統的數據收集,還包括異步數據收集(需要跟蹤隊列中的消息,保證調用的連貫性),以及確保更小的侵入性;數據展示又涉及到數據挖掘和分析。雖然每一部分都可能變得很復雜,但基本原理都類似。

服務追蹤的追蹤單元是從客戶發起請求(request)抵達被追蹤系統的邊界開始,到被追蹤系統向客戶返回響應(response)為止的過程,稱為一個 trace。每個 trace 中會調用若干個服務,為了記錄調用了哪些服務,以及每次調用的消耗時間等信息,在每次調用服務時,埋入一個調用記錄,稱為一個 span。這樣,若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程中,會不斷地有請求和響應發生,也就會不斷生成 trace,把這些帶有 span 的 trace 記錄下來,就可以描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間,以及請求成功與否等信息,就可以在發生問題的時候,找到異常的服務;根據歷史數據,還可以從系統整體層面分析出哪里性能差,定位性能優化的目標。

Spring Cloud Sleuth 為服務之間調用提供鏈路追蹤。通過 Sleuth 可以很清楚的了解到一個服務請求經過了哪些服務,每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的調用關系。此外 Sleuth 可以幫助我們:

耗時分析: 通過 Sleuth 可以很方便的了解到每個采樣請求的耗時,從而分析出哪些服務調用比較耗時; 可視化錯誤: 對於程序未捕捉的異常,可以通過集成 Zipkin 服務界面上看到; 鏈路優化: 對於調用比較頻繁的服務,可以針對這些服務實施一些優化措施。 Spring Cloud Sleuth 可以結合 Zipkin,將信息發送到 Zipkin,利用 Zipkin 的存儲來存儲信息,利用 Zipkin UI 來展示數據。

這是 Spring Cloud Sleuth 的概念圖:每個 color的顏色表示一個 span(有七個 spans - 從A到G)。 考慮以下說明:

  1. Trace Id = X

  2. Span Id = D

  3. Client Sent

本說明指出當前的跨度(span)將跟蹤標識設置為X,跨度標識設置為D.此外還發生了客戶端已發送事件。

下圖顯示了跨度(span)的父子關系:

Zipkin

Zipkin 是 Twitter 的一個開源項目,它基於 Google Dapper 實現,它致力於收集服務的定時數據,以解決微服務架構中的延遲問題,包括數據的收集、存儲、查找和展現。 我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據,並通過它提供的 REST API 接口來輔助我們查詢跟蹤數據以實現對分布式系統的監控程序,從而及時地發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發的 API 接口之外,它也提供了方便的 UI 組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細,比如:可以查詢某段時間內各用戶請求的處理時間等。 Zipkin 提供了可插拔數據存儲方式:In-Memory、MySql、Cassandra 以及 Elasticsearch。接下來的測試為方便直接采用 In-Memory 方式進行存儲,生產推薦 Elasticsearch。

上圖展示了 Zipkin 的基礎架構,它主要由 4 個核心組件構成:

Collector:收集器組件,它主要用於處理從外部系統發送過來的跟蹤信息,將這些信息轉換為 Zipkin 內部處理的 Span 格式,以支持后續的存儲、分析、展示等功能。Storage:存儲組件,它主要對處理收集器接收到的跟蹤信息,默認會將這些信息存儲在內存中,我們也可以修改此存儲策略,通過使用其他存儲組件將跟蹤信息存儲到數據庫中。RESTful API:API 組件,它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息,或是外接系統訪問以實現監控等。Web UI:UI 組件,基於 API 組件實現的上層應用。通過 UI 組件用戶可以方便而有直觀地查詢和分析跟蹤信息。

快速上手

Zipkin 分為兩端,一個是 Zipkin 服務端,一個是 Zipkin 客戶端,客戶端也就是微服務的應用。 客戶端會配置服務端的 URL 地址,一旦發生服務間的調用的時候,會被配置在微服務里面的 Sleuth 的監聽器監聽,並生成相應的 Trace 和 Span 信息發送給服務端。 發送的方式主要有兩種,一種是 HTTP 報文的方式,還有一種是消息總線的方式如 RabbitMQ。

不論哪種方式,我們都需要:

一個 Eureka 服務注冊中心,這里我們就用之前的eureka項目來當注冊中心。一個 Zipkin 服務端。

Zipkin服務端

  1. <dependency>

  2.    <groupId>io.zipkin.java</groupId>

  3.    <artifactId>zipkin-server</artifactId>

  4. </dependency>

  5. <dependency>

  6.    <groupId>io.zipkin.java</groupId>

  7.    <artifactId>zipkin-autoconfigure-ui</artifactId>

  8. </dependency>

application.yml

  1. spring:

  2.  application:

  3.    name: zipkin-server

  4. server:

  5.  port: 9411

看起來似乎很簡單,不過springboot2.x過后更簡單!關於 Zipkin 的服務端,在使用 Spring Boot 2.x 版本后,官方就不推薦自行定制編譯了,反而是直接提供了編譯好的 jar 包來給我們使用,詳情參考連接如果你的jdk是1.8+可以使用如下方式:

  1. $ curl -sSL https://zipkin.io/quickstart.sh | bash -s

  2. $ java -jar zipkin.jar

如果你的是docker部署請:

  1. docker run -d -p 9411:9411 openzipkin/zipkin

Zipkin客戶端

導入核心依賴:

  1. <dependency>

  2.    <groupId>org.springframework.cloud</groupId>

  3.    <artifactId>spring-cloud-starter-zipkin</artifactId>

  4. </dependency>

spring-cloud-starter-zipkin依賴內部包含了兩個依賴,等於同時引入了 spring-cloud-starter-sleuthspring-cloud-sleuth-zipkin兩個依賴。名字特別像,注意區分。

我的springgateway的配置文件 application.yml

  1. ## SERVER

  2. server:

  3.  port: 8764

  4. management:

  5.  server:

  6.    port: 9275

  7.  endpoints:

  8.    web:

  9.      exposure:

  10.        include: "*"

  11.      base-path: /actuator

  12.      path-mapping:

  13.        health: /healthcheck

  14.        info:  /infocheck

  15. eureka:

  16.  instance:

  17.    hostname: localhost

  18.    health-check-url-path: ${management.endpoints.web.base-path}${management.endpoints.web.path-mapping.health}

  19.    status-page-url-path: ${management.endpoints.web.base-path}${management.endpoints.web.path-mapping.info}

  20.  client:

  21.    service-url:

  22.      defaultZone: http://localhost:8763/eureka/

  23.  server:

  24.    renewal-percent-threshold: 0.8

  25. spring:

  26.  application:

  27.    name: gateway #1

  28.  zipkin:

  29.    base-url: http://localhost:9411 #2

  30.  sleuth:

  31.    sampler:

  32.      probability: 1.0 #3

指定項目名稱可以方便的標記應用,在之后的監控頁面可以看到這里的配置名稱

指定zipkin的服務端,用於發送鏈路調用報告

采樣率,值為[0,1]之間的任意實數,顧名思義,這里代表100%采集報告。

總結:

本篇文章參考官網講解了一下 SpringCloudSleuth實現鏈路監控的一些知識點,以及一些簡單的入門使用,最重要的是注意版本是 Springboot2.x,官方已經推薦使用它自己的 zipkin服務端的jar包了,盡量別自行修改代碼,否則出現問題不好解決!

參考資料

Spring Cloud Sleuth官方資料

http://cloud.spring.io/spring-cloud-sleuth/single/spring-cloud-sleuth.html#_distributed_tracing_with_zipkin

openzipkin/zipkin

https://github.com/openzipkin/zipkin

spring4all社區資料【使用Spring Cloud Sleuth實現鏈路監控】

http://www.spring4all.com/article/156

推薦:Dubbo x Cloud Native 服務架構長文總結(很全)

上一篇:SpringCloudGateway【Finchley 版】上的監控


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM