1. 程式人生 > >SpringCloud,Sleuth+Zipkin

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:




相關推薦

SpringCloudSleuth+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 服務並發原理編程SpringBootSpringCloudRocketMQ中間件視頻教程

工資 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呼叫服務來完成,整個呼叫過程可能會聚合多個後臺伺服器協同完成。在整個鏈路上,任何一處呼叫超時 或出錯都有可能造成前端請求失敗。這時跟蹤記錄這些請求的呼叫的情況就要複雜的多

SpringBootSpringCloudDocker構建微服務學習筆記

SpringCloud與阿里巴巴的dubbo都是實現微服務架構的基礎框架,由與我在學習的時候是提供SpringBoot來嘗試構建微服務,因此我使用了SpringCloud。 SpringCloud的子專案非常多,在最開始學習微服務的第一步只需要學會微服務的服務

spring-cloud-sleuth+zipkin追蹤服務

本文簡單介紹瞭如何利用Zipkin對SpringCloud應用進行服務分析在實際的應用場景中,Zipkin可以結合壓力測試工具一起使用,分析系統在大壓力下的可用性和效能。設想這麼一種情況,如果你的微服務數量逐漸增大,服務間的依賴關係越來越複雜,怎麼分析它們之間的呼叫關係及相互