SpringCloud,Sleuth+Zipkin
一、介紹
SpringCloud Sleuth為微服務提供了呼叫鏈路追蹤解決方案,並且相容支援了Zipkin,只需要引入相應的依賴,配置,即可實現對鏈路的監控。
SpringCloud Sleuth可以追蹤10種元件:async、Hystrix、messaging、websocket、rxjava、scheduling、web(Spring MVC Controller, Servlet)、webclient(Spring RestTemplate)、Feign、Zuul 。可以參考 Spring Cloud Sleuth訊息追蹤原理,該部落格介紹了Sleuth對8中常用元件的追蹤原理。
SpringCloud對Zipkin進行了有效的整合,Zipkin是Twitter開源的輕量級分散式鏈路呼叫監控系統。Zipkin易於搭建,但是監控的東西很簡單。pinpoint以及skywalking不僅僅提供了分散式服務的跟蹤能力,還提供了其他效能監控,是一個APM解決方案。
分散式服務追蹤系統主要有一下三個關鍵點:
1. Span。一個基礎工作單元(例如服務呼叫)。為了統計各處理單元的時間延遲,當請求到達各服務元件時,也通過一個唯一標識(Span ID)標記它的開始、具體過程、結束。通過Span的開始和結束的時間戳,就能統計這個Span的時間延遲,獲取事件名稱、請求資訊等元資料。
2. Trace。 一系列Span組成的樹狀結構。所有Span通過相同的Trace串聯組成。為了實現請求跟蹤,當請求到一個分散式系統的入口端點時,只需要服務跟蹤框架為該請求建立一個唯一的跟蹤標識(Trace ID),同時在服務內部流轉時始終保持傳遞該唯一標識,直到請求返回為止。框架通過它將請求過程中的日誌關聯起來。
3. Annotation。用來及時記錄一個事件的存在,一些核心Annotation用來定義請求的開始和結束。
● cs(Client Sent):客戶端發出一個請求,這個Annotation描述了這個Span的開始。
● sr(Server Received):服務端收到請求並開始處理。timestampsr-timesampcs=網路延遲。
● ss(Server Sent):伺服器處理完並準備返回給客戶端。timestampss-timesampsr=伺服器處理時間。
● cr(Client Received):客戶端收到響應,表明Span的結束。timestampcr-timestampcs=請求總時間。
二、Zipkin結構與傳輸
下圖更能體現Zipkin的工作流程。
跟蹤工具報告是非同步的,避免跟蹤系統對服務造成延時或故障。
Client收到服務的響應後,非同步傳送給Zipkin,Zipkin Collecter守護程式收到追蹤資料,Zipkin Collecter就會對追蹤資料進行驗證、儲存、索引。
Transport
追蹤資料要從Span傳輸到Zipkin Collector服務,有三種主要的傳輸方式:Http,MQ(kafka),Scribe。
Components
Collector:一旦資料到達了Zipkin Collector的守護程式,就會被收集。
Storage:預設記憶體。Cassandra最初是為了存Zipkin資料而建立的,因為Cassandra可拓展。Cassandra可插拔,所以通常用ES,Mysql等替代。
Query Service:一旦資料被儲存或者索引,我們就要用一種方法提取資料。查詢守護程序提供一個簡單的JSON API用於查詢和檢索跟蹤。這個API的主要使用者是Web UI。
Web UI:提供了基於服務、時間、註釋檢視跟蹤的方法。(沒有內建的身份驗證機制)
三、建立一個Zipkin Server
1. 匯入web依賴,以及Zipkin Server、Zipkin UI的依賴
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>
2. 開啟@EnableZipkinServer註解@SpringBootApplication
@EnableZipkinServer
public class ZipkinApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinApplication.class, args);
}
}
3. 修改配置檔案,設定埠spring.application.name=sleuth-service
server.port=8770
四、建立service-1,service-2, service-1通過RestTemplate呼叫service-2
1. 引入web、Sleuth、Zipkin依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
2. 兩個工程建立兩個介面,service-1的介面呼叫service-2的介面
service-1:
@SpringBootApplication
@RestController
public class Service1Application {
public static void main(String[] args) {
SpringApplication.run(Service1Application.class, args);
}
@Autowired
RestTemplate restTemplate;
@Bean
RestTemplate getRestTemplate(){
return new RestTemplate();
}
@RequestMapping("/service2")
public String callService2(){
return restTemplate.getForObject("http://localhost:8772/call", String.class);
}
}
service-2:@SpringBootApplication
@RestController
public class Service2Application {
@Autowired
RestTemplate restTemplate;
@Bean
RestTemplate getRestTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(Service2Application.class, args);
}
@RequestMapping("/call")
public String call(){
return "service-2 called..";
}
}
3. 增加配置
service-1:
server.port=8771
spring.application.name=service-1
spring.zipkin.base-url=http://localhost:8770
spring.sleuth.sampler.percentage=1
service-2:server.port=8772
spring.application.name=service-2
spring.zipkin.base-url=http://localhost:8770
spring.sleuth.sampler.percentage=1
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
注意:這裡要配置取樣率spring.sleuth.sampler.percentage=1,如果不配置這裡預設為0.1,如果調大值為1,可以在Web UI上更及時看到資訊。但是調大會影響服務呼叫速率。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
五、測試
先啟動Zipkin Server,訪問 http:localhost:8770/
啟動兩個服務, 訪問service-1中呼叫service-2的介面 localhost:8771/service2
再重新整理Zipkin UI的Dependencies
trace:
相關推薦
SpringCloud,Sleuth+Zipkin
一、介紹 SpringCloud Sleuth為微服務提供了呼叫鏈路追蹤解決方案,並且相容支援了Zipkin,只需要引入相應的依賴,配置,即可實現對鏈路的監控。 SpringCloud Sleuth可以追蹤10種元件:async、Hystrix、me
十二、springcloud之展示追蹤數據 Sleuth+zipkin
圖片 rgs 用戶 ati 請求 sta ring zip 設置 一、Zipkin簡介 Zipkin是Twitter的一個開源項目,它基於Google Dapper實現。我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據,並通過它提供的REST API接口來輔助我們查詢
springcloud服務追蹤Zipkin和spring cloud Sleuth
參考文章一: 摘要: 本文簡單介紹瞭如何利用Zipkin對SpringCloud應用進行服務分析。在實際的應用場景中,Zipkin可以結合壓力測試工具一起使用,分析系統在大壓力下的可用性和效能。 設想這麼一種情況,如果你的微服務數量逐漸增大,服務間的依賴關係越來越複雜,怎麼分析它們
springcloud+sleuth+zipkin+kafka+es
前面已經完成了Springcloud+sleuth+zipkin的入門,以及kafka的安裝。至於ES這裡就不在說明了,網上安裝使用資料挺多的,這裡僅僅是將其作為持久化工具使用。 環境說明 jdk1.8 server 64位 intellij IDEA 2
springcloud-sleuth+zipkin入門一
說明 zipkin是twitter公司基於Google的drapper論文,建立一套分散式、服務計時框架,可以用於鏈路跟蹤。目前有的java版本的實現有DropWizard zipkin和Springcloud-sleuth+zipkin等。本文是搭建Spri
全鏈路spring cloud sleuth+zipkin
arc owa version public kafka 分享 cli self 兩個 http://blog.csdn.net/qq_15138455/article/details/72956232 版權聲明:@入江之鯨 一、About ZipKi
14套java精品高級架構課,Dubbo分布式Restful 服務,並發原理編程,SpringBoot,SpringCloud,RocketMQ中間件視頻教程
工資 tac ini ati album rii fms ont html 14套java精品高級架構課,緩存架構,深入Jvm虛擬機,全文檢索Elasticsearch,Dubbo分布式Restful 服務,並發原理編程,SpringBoot,SpringCloud,Ro
Spring Cloud Sleuth + zipkin 實現服務追蹤
工作 process image -o 唯一id dep 單元 圖片 zipkin 服務追蹤 Spring Cloud Sleuth實現了一種分布式的服務鏈路跟蹤解決方案,通過使用Sleuth可以讓我們快速定位某個服務的問題。 官方文檔地址如下: http://cloud
全鏈路追蹤spring-cloud-sleuth-zipkin
authorize 采樣 quest child 手機號 main rgs lin oot 微服務架構下 多個服務之間相互調用,在解決問題的時候,請求鏈路的追蹤是十分有必要的,鑒於項目中采用的spring cloud架構,所以為了方便使用,便於接入等 項目中采用了sprin
sleuth+zipkin日誌輸出traceId(五)
日誌配置 在需要追蹤的示例應用中,修改日誌配置,這裡使用springboot構建,logback作為日誌輸出工具 <property name="FILE_LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS
Spring Cloud 分散式鏈路跟蹤 Sleuth + Zipkin + Elasticsearch
隨著業務越來越複雜,系統也隨之進行各種拆分,特別是隨著微服務架構的興起,看似一個簡單的應用,後臺可能很多服務在支撐;一個請求可能需要多個服務的呼叫;當請求遲緩或不可用時,無法得知是哪個微服務引起的,這時就需要解決如何快速定位服務故障點,Zipkin 分散式跟蹤系統就能很好的解決這樣的問題。 如果想學習Java
Spring Cloud 分散式鏈路跟蹤 Sleuth + Zipkin + Elasticsear
隨著業務越來越複雜,系統也隨之進行各種拆分,特別是隨著微服務架構的興起,看似一個簡單的應用,後臺可能很多服務在支撐;一個請求可能需要多個服務的呼叫;當請求遲緩或不可用時,無法得知是哪個微服務引起的,這時就需要解決如何快速定位服務故障點,Zipkin 分散式跟蹤系統就能很好的解決這樣的問題。 那麼到底怎麼使用
sleuth+zipkin自定義取樣率(九)
問題背景 zipkin原生提供的取樣率設定,僅能針對全域性進行設定,無法做到精細化設定,比如,有些介面我們覺得比較重要,所以想取樣率高一點,有些介面很簡單,我們希望不採集或者採集率設定低一點,原生是沒辦法做到的,需要完成這個功能,需要我們重寫他的取樣率計算器。
Spring Cloud(九)Sleuth+ZipKin 實現服務追蹤
注:本文Spring Cloud 版本 Finchley.SR1 為什麼需要服務追蹤 微服務架構是一個分散式架構,它按業務劃分服務單元,一個分散式系統往往有很多個服務單元。由於服務單元數量眾多,業務的複雜性,如果出現了錯誤和異常,很難去定位。主要體現在,一個請求
Spring Cloud(十)Sleuth+ZipKin 實現服務追蹤(續)
注:本文Spring Cloud 版本 Finchley.SR1 本節是對上一篇的延續,沒有檢視上一篇的請先檢視 Spring Cloud(九)Sleuth+ZipKin 實現服務追蹤 相信細心的網友也發現了,以上的配置方式使用的是 http 傳送鏈路資料,並且
sleuth+zipkin 呼叫追蹤全量日誌方案
spring cloud中的zipkin日誌統計是由sleuth客戶端和zipkin伺服器組成。 sleuth收集客端trace,通過mq將trace傳送到zipkin伺服器。 zipkin 做持久化和查詢展示功能。常用kafka+zk叢集作為mq將資訊由客戶端發往伺服器,elasticsearc
rancher部署springcloud,各微服務放在不同主機需要注意的點。
rancher建立了一個應用 在應用名裡填寫名稱,其他不添,一個應用就建立了,應用建立後就建立具體服務 名稱隨意,比方你在此處建立eureka,就寫eureka,映象裡添自己docker push到自己的私有映象庫,或者開源的映象,這裡不做贅述。 eureka啟
Spring Cloud微服務(8)之 sleuth+zipkin日誌聚合
1.簡介 (1)什麼是服務追蹤 Sleuth 在微服務架構中,要完成一個功能,通過Rest請求服務API呼叫服務來完成,整個呼叫過程可能會聚合多個後臺伺服器協同完成。在整個鏈路上,任何一處呼叫超時 或出錯都有可能造成前端請求失敗。這時跟蹤記錄這些請求的呼叫的情況就要複雜的多
SpringBoot,SpringCloud,Docker構建微服務學習筆記
SpringCloud與阿里巴巴的dubbo都是實現微服務架構的基礎框架,由與我在學習的時候是提供SpringBoot來嘗試構建微服務,因此我使用了SpringCloud。 SpringCloud的子專案非常多,在最開始學習微服務的第一步只需要學會微服務的服務
spring-cloud-sleuth+zipkin追蹤服務
本文簡單介紹瞭如何利用Zipkin對SpringCloud應用進行服務分析在實際的應用場景中,Zipkin可以結合壓力測試工具一起使用,分析系統在大壓力下的可用性和效能。設想這麼一種情況,如果你的微服務數量逐漸增大,服務間的依賴關係越來越複雜,怎麼分析它們之間的呼叫關係及相互