Spring Cloud 學(xué)習(xí)筆記 - No.8 分布式服務(wù)跟蹤 Sleuth

請(qǐng)先閱讀之前的內(nèi)容：

在我們之前的例子中，服務(wù) eureka-consumer 中的 /consumer 接口實(shí)際上是通過(guò) Rest 調(diào)用服務(wù) eureka-client 中的 /add 接口來(lái)實(shí)現(xiàn)具體的計(jì)算邏輯。

生產(chǎn)環(huán)境中，通常一個(gè)由客戶端發(fā)起的請(qǐng)求在后端系統(tǒng)中會(huì)經(jīng)過(guò)多個(gè)不同的微服務(wù)調(diào)用來(lái)協(xié)同產(chǎn)生最后的請(qǐng)求結(jié)果，即形成一條復(fù)雜的分布式服務(wù)調(diào)用鏈路，在每條鏈路中任何一個(gè)依賴服務(wù)出現(xiàn)延遲過(guò)高或錯(cuò)誤的時(shí)候都有可能引起請(qǐng)求最后的失敗。
這時(shí)候?qū)τ诿總€(gè)請(qǐng)求分布式服務(wù)調(diào)用鏈路的跟蹤就變得越來(lái)越重要，通過(guò)實(shí)現(xiàn)對(duì)請(qǐng)求調(diào)用的跟蹤可以幫助我們快速的發(fā)現(xiàn)錯(cuò)誤根源以及監(jiān)控分析每條請(qǐng)求鏈路上的性能瓶頸。

針對(duì)上面所述的分布式服務(wù)跟蹤問(wèn)題，Spring Cloud Sleuth 提供了一套完整的解決方案。
網(wǎng)址：https://cloud.spring.io/spring-cloud-sleuth/

Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin and HTrace. For most users Sleuth should be invisible, and all your interactions with external systems should be instrumented automatically. You can capture data simply in logs, or by sending it to a remote collector service.

首先我們分別在服務(wù) eureka-consumer 中的 /consumer 接口和服務(wù) eureka-client 中的 /add 接口中添加日志：

@ApiOperation(value = "提供 1 + 2 的加法結(jié)果", notes = "")
@GetMapping("/consumer")
public String consumer() {
    logger.info("{} REST API provided by {}", "consumer", "eureka-consumer");
    return consumerService.consumer();
}

@GetMapping("/add")
public Integer add(@RequestParam Integer operand1, @RequestParam Integer operand2) throws InterruptedException {

    logger.info("{} REST API provided by {}", "add", "eureka-client");

    return operand1 + operand2;
}

重啟服務(wù)，調(diào)用 http://127.0.0.1:3001/consumer（調(diào)用兩次），
我們從 eureka-consumer 的日志輸出中可以看到：

INFO 56477 --- [nio-3001-exec-4] c.example.controller.ConsumerController  : consumer REST API provided by eureka-consumer
INFO 56477 --- [nio-3001-exec-4] c.example.controller.ConsumerController  : consumer REST API provided by eureka-consumer

我們從 eureka-client 的日志輸出中可以看到：

INFO 56356 --- [nio-2002-exec-3] c.e.controller.CalculatorController      : add REST API provided by eureka-client
INFO 56356 --- [nio-2002-exec-3] c.e.controller.CalculatorController      : add REST API provided by eureka-client

但是這樣存在一個(gè)問(wèn)題：這兩條日志直接并不能看出關(guān)聯(lián)關(guān)系。例如，我們發(fā)送了好多次請(qǐng)求，那么在日志中就會(huì)出現(xiàn)好多條 consumer REST API provided by eureka-consumer 和好多條 add REST API provided by eureka-client。
那么第幾條 consumer REST API provided by eureka-consumer 和 第幾條 add REST API provided by eureka-client 處于同一個(gè)分布式服務(wù)調(diào)用鏈路？我們無(wú)法得知。

實(shí)現(xiàn)跟蹤

我們?cè)?eureka-consumer 和 eureka-client 分別添加如下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

添加 spring-cloud-starter-sleuth 依賴之后， 它會(huì)自動(dòng)的為當(dāng)前應(yīng)用構(gòu)建起各通信通道的跟蹤機(jī)制，比如：

  • 通過(guò)諸如 RabbitMQ、Kafka 等消息中間件傳遞的請(qǐng)求
  • 通過(guò) Zuul 服務(wù)網(wǎng)關(guān)傳遞的請(qǐng)求
  • 通過(guò) RestTemplate 發(fā)起的請(qǐng)求

重啟服務(wù)，調(diào)用 http://127.0.0.1:3001/consumer （調(diào)用兩次），
我們從 eureka-consumer 的日志輸出中可以看到：

INFO [eureka-consumer,7d46e2f108b162a3,7d46e2f108b162a3,false] 60307 --- [nio-3001-exec-5] c.example.controller.ConsumerController  : consumer REST API provided by eureka-consumer
INFO [eureka-consumer,b1ec47bd025f3650,b1ec47bd025f3650,false] 60307 --- [nio-3001-exec-7] c.example.controller.ConsumerController  : consumer REST API provided by eureka-consumer

我們從 eureka-client 的日志輸出中可以看到：

INFO [eureka-client,7d46e2f108b162a3,39b07f1c5d3f1a2a,false] 59975 --- [nio-2001-exec-9] c.e.controller.CalculatorController      : add REST API provided by eureka-client
INFO [eureka-client,b1ec47bd025f3650,52375bb6fdb08a40,false] 60113 --- [nio-2002-exec-6] c.e.controller.CalculatorController      : add REST API provided by eureka-client

我們可以看到多了一些形如 [eureka-consumer,7d46e2f108b162a3,7d46e2f108b162a3,false] 的日志信息，而這些元素正是實(shí)現(xiàn)分布式服務(wù)跟蹤的重要組成部分，它們每個(gè)值的含義如下：

  • 第一個(gè)值：eureka-consumer，它記錄了應(yīng)用的名稱。
  • 第二個(gè)值：7d46e2f108b162a3，Spring Cloud Sleuth 生成的一個(gè)ID，稱為 Trace ID，它用來(lái)標(biāo)識(shí)一條請(qǐng)求鏈路。一條分布式服務(wù)調(diào)用鏈路中包含一個(gè) Trace ID，多個(gè) Span ID。
  • 第三個(gè)值：7d46e2f108b162a3，Spring Cloud Sleuth 生成的另外一個(gè)ID，稱為 Span ID，它表示一個(gè)基本的工作單元，比如：發(fā)送一個(gè) HTTP 請(qǐng)求。
  • 第四個(gè)值：false，表示是否要將該信息輸出到 Zipkin 等服務(wù)中來(lái)收集和展示。

從上面的日志中，我們可以看出，第一次 http://127.0.0.1:3001/consumer 調(diào)用的 Trace ID 為 7d46e2f108b162a3，它對(duì)應(yīng)了兩個(gè) Span ID，即兩次 HTTP 請(qǐng)求：

  • 請(qǐng)求到 eureka-consumer，Span ID 為 7d46e2f108b162a3
  • 請(qǐng)求到 eureka-client，Span ID 為 39b07f1c5d3f1a2a

實(shí)現(xiàn)原理

  • 當(dāng)請(qǐng)求發(fā)送到分布式系統(tǒng)的入口端點(diǎn)時(shí)（例如上面的 /consumer），Spring Cloud Sleuth 為該請(qǐng)求創(chuàng)建一個(gè)唯一的跟蹤標(biāo)識(shí)，同時(shí)在分布式系統(tǒng)內(nèi)部流轉(zhuǎn)的時(shí)候，框架始終保持傳遞該唯一標(biāo)識(shí)，直到返回給請(qǐng)求方為止，這個(gè)唯一標(biāo)識(shí)就是前文中提到的 Trace ID（例如上面的 7d46e2f108b162a3)。通過(guò) Trace ID 的記錄，我們就能將所有請(qǐng)求過(guò)程日志關(guān)聯(lián)起來(lái)。
  • 為了統(tǒng)計(jì)各處理單元的時(shí)間延遲，當(dāng)請(qǐng)求達(dá)到各個(gè)服務(wù)組件時(shí)，或是處理邏輯到達(dá)某個(gè)狀態(tài)時(shí)，也通過(guò)一個(gè)唯一標(biāo)識(shí)來(lái)標(biāo)記它的開始、具體過(guò)程以及結(jié)束，該標(biāo)識(shí)就是我們前文中提到的 Span ID（例如上面的 39b07f1c5d3f1a2a)，對(duì)于每個(gè) Span 來(lái)說(shuō)，它必須有開始和結(jié)束兩個(gè)節(jié)點(diǎn)，通過(guò)記錄開始 Span 和結(jié)束 Span 的時(shí)間戳，就能統(tǒng)計(jì)出該 Span 的時(shí)間延遲，除了時(shí)間戳記錄之外，它還可以包含一些其他元數(shù)據(jù)，比如：事件名稱、請(qǐng)求信息等。

整合 ELK

在上面的例子中，日志文件都離散的存儲(chǔ)在各個(gè)服務(wù)實(shí)例的文件系統(tǒng)之上，僅僅通過(guò)查看日志文件來(lái)分析分布式服務(wù)調(diào)用鏈路依然是一件相當(dāng)麻煩的差事，所以我們還需要一些工具來(lái)幫助我們集中的收集、存儲(chǔ)和搜索這些跟蹤信息。

ELK 平臺(tái)主要有由 ElasticSearch、Logstash 和 Kiabana 三個(gè)開源免費(fèi)工具組成，具體參見 ELK 三件套的一些實(shí)踐。

Spring Cloud Sleuth 在與 ELK 平臺(tái)整合使用時(shí)，實(shí)際上我們只要實(shí)現(xiàn)與負(fù)責(zé)日志收集的 Logstash 完成數(shù)據(jù)對(duì)接即可，所以我們需要為 Logstash 準(zhǔn)備 JSON 格式的日志輸出。
由于 Spring Boot 應(yīng)用默認(rèn)使用了 Logback 來(lái)記錄日志，而 Logstash 自身也有對(duì) Logback 日志工具的支持工具，所以我們可以直接通過(guò)在 Logback 的配置中增加對(duì) Logstash 的 Appender，就能非常方便的將日志轉(zhuǎn)換成以 JSON 的格式存儲(chǔ)和輸出了。

我們?cè)?eureka-consumer 和 eureka-client 分別添加如下依賴：

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>4.9</version>
</dependency>

我們?cè)?eureka-consumer 和 eureka-client 分別添加配置文件 /resources/logback-spring.xml?？梢钥闯?，我們?yōu)槿罩径x兩個(gè) Appender：

  • 一個(gè)是控制臺(tái) ConsoleAppender
  • 一個(gè)是地址為 127.0.0.1:9250 的 LogstashTcpSocketAppender
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

    <springProperty scope="context" name="springAppName" source="spring.application.name"/>

    <!-- 控制臺(tái)的日志輸出樣式 -->
    <property name="CONSOLE_LOG_PATTERN"
              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr([${springAppName:-},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]){yellow} %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

    <!-- 控制臺(tái)Appender -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>

    <!-- 將日志內(nèi)容直接通過(guò) Tcp Socket 輸出到 Logstash 服務(wù)端 -->
    <appender name="logstash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>127.0.0.1:9250</destination>
        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <pattern>
                    <pattern>
                        {
                        "severity": "%level",
                        "service": "${springAppName:-}",
                        "trace": "%X{X-B3-TraceId:-}",
                        "span": "%X{X-B3-SpanId:-}",
                        "exportable": "%X{X-Span-Export:-}",
                        "pid": "${PID:-}",
                        "thread": "%thread",
                        "class": "%logger{40}",
                        "rest": "%message"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="console"/>
        <appender-ref ref="logstash"/>
    </root>
</configuration>

確保 ELK 三件套已正常啟動(dòng)并部署，參見 ELK 三件套的一些實(shí)踐。
重啟 eureka-consumer（端口 3001，3002） 和 eureka-client（端口 2001，2002），調(diào)用 http://127.0.0.1:3001/consumer，http://127.0.0.1:3002/consumer（調(diào)用多次）。

隨后我們進(jìn)入到 Kibana 管理頁(yè)面 http://localhost:5601/。
首先創(chuàng)建一個(gè)索引模式 Index Patterns，名稱為 testing-log：

創(chuàng)建一個(gè)索引模式 Index Patterns

然后我們可以在 Discover 頁(yè)面做一個(gè)查詢，例如我們想知道 Trace Id 為 22829366859badc0 的日志，可以通過(guò)如下方式：
Trace Id 為 22829366859badc0 的日志

整合 Zipkin

在 ELK 平臺(tái)中的數(shù)據(jù)分析維度缺少對(duì)請(qǐng)求鏈路中各階段時(shí)間延遲的關(guān)注，對(duì)于這樣的問(wèn)題，我們就可以引入 Zipkin 來(lái)解決。

Zipkin 簡(jiǎn)介

https://zipkin.io/

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.
Applications are instrumented to report timing data to Zipkin.
The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application.

圖片引用自：http://blog.didispace.com/spring-cloud-starter-dalston-8-4/

Zipkin 的基礎(chǔ)架構(gòu)

  • Collector：收集器組件，處理從外部系統(tǒng)發(fā)送過(guò)來(lái)的跟蹤信息，將這些信息轉(zhuǎn)換為 Zipkin 內(nèi)部處理的 Span 格式，以支持后續(xù)的存儲(chǔ)、分析、展示等功能。
  • Storage：存儲(chǔ)組件，處理收集器接收到的跟蹤信息，默認(rèn)會(huì)將這些信息存儲(chǔ)在內(nèi)存中，我們也可以修改此存儲(chǔ)策略，通過(guò)使用其他存儲(chǔ)組件將跟蹤信息存儲(chǔ)到數(shù)據(jù)庫(kù)中。
  • RESTful API：API 組件，它主要用來(lái)提供外部訪問(wèn)接口。比如給客戶端展示跟蹤信息，或是外接系統(tǒng)訪問(wèn)以實(shí)現(xiàn)監(jiān)控等。
  • Web UI：UI組件，基于API組件實(shí)現(xiàn)的上層應(yīng)用。通過(guò) UI 組件用戶可以方便而有直觀地查詢和分析跟蹤信息。

Zipkin 通過(guò) HTTP 收集數(shù)據(jù)

首先創(chuàng)建一個(gè) Zipkin 服務(wù)器，這是一個(gè) Spring Boot 應(yīng)用，命名為 zipkin-server，添加如下依賴：

<dependencies>
    <dependency>
        <groupId>io.zipkin.java</groupId>
        <artifactId>zipkin-server</artifactId>
    </dependency>
    <dependency>
        <groupId>io.zipkin.java</groupId>
        <artifactId>zipkin-autoconfigure-ui</artifactId>
    </dependency>
</dependencies>

注意：由于 Zipkin 目前不兼容 Spring Boot 2.0，請(qǐng)使用 1.5 版本的 Spring Boot：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.5.10.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

隨后使用 @EnableZipkinServer 注解來(lái)啟動(dòng) Zipkin Server：

@SpringBootApplication
@EnableZipkinServer
public class ZipkinServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ZipkinServerApplication.class, args);
    }
}

在 application.properties 中設(shè)置端口：

spring.application.name=zipkin-server
server.port=4321

最后通過(guò) mvn spring-boot:run 啟動(dòng) 并訪問(wèn) http://127.0.0.1:4321/ 來(lái)訪問(wèn) Zipkin Web UI：

Zipkin Web UI

現(xiàn)在我們要為應(yīng)用 eureka-consumer 和 eureka-client 引入和配置 Zipkin 服務(wù)。
我們?cè)?eureka-consumer 和 eureka-client 分別添加如下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>

我們?cè)?eureka-consumer 和 eureka-client 的 application.properties 中增加 Zipkin Server 的配置信息：

spring.zipkin.baseUrl=http://localhost:4321

我們?cè)?eureka-consumer 和 eureka-client 的啟動(dòng)程序中添加：（具體原因下面《抽樣收集》會(huì)補(bǔ)充說(shuō)明）

@Bean
public Sampler defaultSampler() {
    return Sampler.ALWAYS_SAMPLE;
}

重啟 eureka-consumer（端口 3001，3002） 和 eureka-client（端口 2001，2002），調(diào)用 http://127.0.0.1:3001/consumer，http://127.0.0.1:3002/consumer（調(diào)用多次）。

隨后我們進(jìn)入到 Zipkin Web UI http://127.0.0.1:4321/：

Zipkin Web UI

Zipkin 通過(guò) 消息中間件 收集數(shù)據(jù)

Spring Cloud Sleuth 在整合 Zipkin 時(shí)，不僅實(shí)現(xiàn)了以 HTTP 的方式收集跟蹤信息，還實(shí)現(xiàn)了通過(guò)消息中間件來(lái)對(duì)跟蹤信息進(jìn)行異步收集的封裝。通過(guò)結(jié)合 Spring Cloud Stream，我們可以非常輕松的讓應(yīng)用客戶端將跟蹤信息輸出到消息中間件上，同時(shí) Zipkin 服務(wù)端從消息中間件上異步地消費(fèi)這些跟蹤信息。

具體參見 http://blog.didispace.com/spring-cloud-starter-dalston-8-4/

Zipkin 數(shù)據(jù)模型

  • Span：它代表了一個(gè)基礎(chǔ)的工作單元。每一個(gè)不同的工作單元都通過(guò)一個(gè)64位的ID來(lái)唯一標(biāo)識(shí)，稱為 Span ID。另外，在工作單元中還存儲(chǔ)了一個(gè)用來(lái)串聯(lián)其他工作單元的ID，它也通過(guò)一個(gè)64位的ID來(lái)唯一標(biāo)識(shí)，稱為 Trace ID。
  • Trace：它是由一系列具有相同 Trace ID 的 Span 串聯(lián)形成的一個(gè)樹狀結(jié)構(gòu)。
  • Annotation：它用來(lái)及時(shí)地記錄一個(gè)事件的存在。我們可以把 Annotation 理解為一個(gè)包含有時(shí)間戳的事件標(biāo)簽，對(duì)于一個(gè) HTTP 請(qǐng)求來(lái)說(shuō)，在 Sleuth 中定義了下面四個(gè)核心 Annotation 來(lái)標(biāo)識(shí)一個(gè)請(qǐng)求的開始和結(jié)束：
    • cs（Client Send）：該 Annotation 用來(lái)記錄客戶端發(fā)起了一個(gè)請(qǐng)求，同時(shí)它也標(biāo)識(shí)了這個(gè) HTTP 請(qǐng)求的開始。
    • sr（Server Received）：該 Annotation 用來(lái)記錄服務(wù)端接收到了請(qǐng)求，并準(zhǔn)備開始處理它。通過(guò)計(jì)算 sr 與 cs 兩個(gè) Annotation 的時(shí)間戳之差，我們可以得到當(dāng)前 HTTP 請(qǐng)求的網(wǎng)絡(luò)延遲。
    • ss（Server Send）：該 Annotation 用來(lái)記錄服務(wù)端處理完請(qǐng)求后準(zhǔn)備發(fā)送請(qǐng)求響應(yīng)信息。通過(guò)計(jì)算 ss 與 sr 兩個(gè) Annotation 的時(shí)間戳之差，我們可以得到當(dāng)前服務(wù)端處理請(qǐng)求的時(shí)間消耗。
    • cr（Client Received）：該 Annotation 用來(lái)記錄客戶端接收到服務(wù)端的回復(fù)，同時(shí)它也標(biāo)識(shí)了這個(gè) HTTP 請(qǐng)求的結(jié)束。通過(guò)計(jì)算 cr 與 cs 兩個(gè) Annotation 的時(shí)間戳之差，我們可以得到該 HTTP 請(qǐng)求從客戶端發(fā)起開始到接收服務(wù)端響應(yīng)的總時(shí)間消耗。
  • BinaryAnnotation：它用來(lái)對(duì)跟蹤信息添加一些額外的補(bǔ)充說(shuō)明，一般以鍵值對(duì)方式出現(xiàn)。

抽樣收集

我們收集的跟蹤信息越多就可以更好的反映出系統(tǒng)的實(shí)際運(yùn)行情況，并給出更精準(zhǔn)的預(yù)警和分析，但是在高并發(fā)的分布式系統(tǒng)運(yùn)行時(shí)，大量的請(qǐng)求調(diào)用會(huì)產(chǎn)生海量的跟蹤日志信息，如果我們收集過(guò)多的跟蹤信息將會(huì)對(duì)我們整個(gè)分布式系統(tǒng)的性能造成一定的影響，同時(shí)保存大量的日志信息也需要不少的存儲(chǔ)開銷。
所以，在 Sleuth 中采用了抽樣收集的方式來(lái)為跟蹤信息打上收集標(biāo)記，也就是我們之前在日志信息中看到的第四個(gè) boolean 類型的值，它代表了該信息是否要被后續(xù)的跟蹤信息收集器獲取和存儲(chǔ)。

Sampling is an up-front decision, meaning that the decision to report data is made at the first operation in a trace and that decision is propagated downstream.

在 Sleuth 中的抽樣收集策略是通過(guò) Sampler 抽象類實(shí)現(xiàn)的，它的定義如下：

public abstract class Sampler {
    public static final Sampler ALWAYS_SAMPLE = new Sampler() {
        public boolean isSampled(long traceId) {
            return true;
        }

        public String toString() {
            return "AlwaysSample";
        }
    };
    public static final Sampler NEVER_SAMPLE = new Sampler() {
        public boolean isSampled(long traceId) {
            return false;
        }

        public String toString() {
            return "NeverSample";
        }
    };

    public Sampler() {
    }

    public abstract boolean isSampled(long var1);

    public static Sampler create(float rate) {
        return CountingSampler.create(rate);
    }
}

通過(guò)覆蓋 isSampled 方法，Spring Cloud Sleuth 會(huì)在產(chǎn)生跟蹤信息的時(shí)候調(diào)用它來(lái)為跟蹤信息生成是否要被收集的標(biāo)志。需要注意的是，即使 isSampled 返回了 false，它僅代表該跟蹤信息不被輸出到后續(xù)對(duì)接的遠(yuǎn)程分析系統(tǒng)（比如：Zipkin），對(duì)于請(qǐng)求的跟蹤活動(dòng)依然會(huì)進(jìn)行，所以我們?cè)谌罩局羞€是能看到收集標(biāo)識(shí)為 false的記錄。
Sleuth 會(huì)使用 PercentageBasedSampler 實(shí)現(xiàn)的抽樣策略，以請(qǐng)求百分比的方式配置和收集跟蹤信息，我們可以通過(guò)在 application.properties 中配置下面的參數(shù)對(duì)其百分比值進(jìn)行設(shè)置，它的默認(rèn)值為 0.1，代表收集 10% 的請(qǐng)求跟蹤信息：

spring.sleuth.sampler.percentage=0.1

也可以通過(guò)創(chuàng)建 AlwaysSampler 的 Bean（它實(shí)現(xiàn)的 isSampled 方法始終返回 true）：

@Bean
public Sampler defaultSampler() {
    return Sampler.ALWAYS_SAMPLE;
}

引用：
程序猿DD Spring Cloud基礎(chǔ)教程
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（入門）
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（跟蹤原理）
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（整合logstash）
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（整合zipkin）
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（收集原理）
Spring Cloud構(gòu)建微服務(wù)架構(gòu)：分布式服務(wù)跟蹤（抽樣收集）
Spring Cloud Dalston中文文檔

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容