1. Sleuth基础知识
1.1 什么是Spring Cloud Sleuth？
Spring Cloud Sleuth 是一个分布式追踪解决方案，属于 Spring Cloud 的一部分。其主要目的是为了在分布式系统中简化问题追踪过程，它通过为服务之间的通信分配一个唯一的跟踪标识，帮助开发者理解微服务架构下请求的流向和持续时间。
在一个由许多小服务组成的系统中，一个客户端请求可能需要穿越多个服务才能完成工作。Sleuth 会为这一请求分配一个唯一的跟踪ID，并将其沿着请求传递的路线，在涉及的每个服务中记录称为"Spans"的时间片段。这使得我们能够将请求路径视作一个整体，即便请求是在分布式系统中传输的。
Sleuth 追踪信息的收集通常包括以下要素：
- Trace ID：这是给定用户请求的整个追踪路径的唯一标识符。
- Span ID：在单个服务级别，跟踪请求花费时间的一部分（也就是Span）的唯一标识符。
- Parent Span ID：指示当前追踪片段是从哪个父Span分支出来的。
- Tags / Metadata：关于请求和相应Span的附加信息。
- Events：某些时间点的特定事件记录，如请求开始、结束等。
Spring Cloud Sleuth 在整合上自动与 Spring Boot 应用和 Spring Cloud 组件一起工作，非常容易使用。
与 Zipkin 或其他可视化分析工具的集成，使得追踪数据可以被查询、可视化展示和分析。通过这种方式，Sleuth 助你洞悉服务间的调用以及其中潜在的瓶颈，帮助迅速定位服务间的问题。
1.2 Sleuth在分布式跟踪中扮演什么角色？
Spring Cloud Sleuth 是 Spring Cloud 的一个项目，它在 Spring Boot 应用程序中提供了分布式跟踪的功能。Sleuth 主要扮演的角色是为微服务架构中的请求调用添加追踪数据，帮助开发者了解请求在多个服务实例之间的流转路径，在分布式跟踪中的具体功能如下：
-
标准化跟踪信息：
Sleuth 生成标准化的跟踪信息，例如 Trace ID 和 Span ID。Trace ID 用于识别从客户端发起的请求并贯穿完整的事务或工作单元，而 Span ID 表示事务中的一个工作单元或某个特定调用链路的部分。 -
上下文传播：
Sleuth 在微服务架构中的服务调用之间传播这些 Trace ID 和 Span ID。它将上下文信息包装在传输层级，如 HTTP 请求的头信息中，确保从一个服务到另一个服务的调用能够被关联起来。 -
日志关联：
Sleuth 自动集成到微服务的日志系统，将 Trace ID 和 Span ID 放入日志条目中，使得通过日志来关联和追踪请求变得更加容易。 -
兼容性：
Sleuth 兼容其他的分布式跟踪系统，如 Zipkin 和 Kafka Streams，允许开发者使用这些系统来存储、可视化和分析跟踪信息。 -
数据收集与报告：
在请求完成或遇到错误时，Sleuth 会报告收集到的跟踪信息给具备数据持久化能力的系统，例如 Zipkin，它可以以可视化的方式展示服务调用链路。 -
导出跟踪数据：
Sleuth 可以导出跟踪数据和指标到不同的后端，比如 ELK 堆栈，提供额外的根因分析和监控功能。 -
无侵入性：
Sleuth 能够在不改变现有服务代码的情况下，通过添加简单的依赖和配置为应用程序提供分布式跟踪的能力。 -
异步和同步通信支持：
Sleuth 支持同步 RESTful 调用和异步消息传递系统（如 Spring Cloud Stream、RabbitMQ 和 Kafka）中的分布式跟踪。
Spring Cloud Sleuth 通过为请求调用添加跟踪上下文，并确保这些上下文在整个分布式系统中传播，从而使开发者能够跨服务边界追踪请求的路径、分析性能瓶颈或跟踪系统里的异步流程。这对于分布式微服务环境中的调试、监控和优化至关重要。
1.3 Sleuth的工作原理是什么？
Spring Cloud Sleuth 是 Spring Cloud 生态系统中的一个分布式跟踪解决方案，它的工作原理依赖于请求跟踪和段落（spans）分配。Sleuth 主要用于跟踪请求在微服务架构系统中的全链路传递过程，为了实现这一点，Sleuth 采取了以下的工作原则：
-
Trace ID：
每个外部请求到达系统时，Sleuth 会为其分配一个唯一的跟踪ID（Trace ID），整个请求的处理流程将共享这一跟踪ID，无论请求经过多少微服务。 -
Span ID：
对于某次请求的每个微服务调用，Sleuth 会生成一个跨度ID（Span ID），用于标识请求在单个服务内部的处理过程。Span 可以包含其他信息，比如事件时间戳、事件名称以及键值对注解等。 -
父子Span关系：
通过跟踪父Span ID和Span ID的关系，Sleuth 能够了解请求跨服务调用的层级关系结构，也就是谁调用了谁。 -
传播机制：
在分布式系统的服务调用过程中，Trace ID和Span ID等跟踪信息通过HTTP请求的Header传播到各服务。这种传播机制通过已集成的库来自动实现，比如使用了 Spring MVC、Feign、RestTemplate 等进行HTTP调用的情况。 -
支持异步通讯：
Sleuth 还支持异步消息传递场景，例如RabbitMQ或Kafka的消息传递，它会跟踪消息相关的队列发送和接收。 -
数据记录和输出：
Sleuth 与日志系统（如Logback）集成，自动在日志条目中添加Trace ID和Span ID，这使得在日志文件中查看请求全链路跟踪变得更容易。 -
与Zipkin集成：
Sleuth 还可以集成Zipkin，把跟踪信息发送给Zipkin服务器，让Zipkin进行更进一步的分析和持久化存储，同时在Zipkin UI中以可视化的形式展示请求链路。
通过实施这一系列的跟踪机制，Spring Cloud Sleuth 使我们能够对分布式系统的请求流程有全局性的理解，并且有助于定位性能问题和故障问题。它对于处理复杂的服务间调用、性能优化和问题诊断都非常关键。
1.4 如何在项目中集成Spring Cloud Sleuth？
Spring Cloud Sleuth是Spring Cloud的一个子项目，它提供了分布式追踪的功能，可以帮助你跟踪微服务架构中的请求流程。为了在项目中集成Spring Cloud Sleuth，请按照以下步骤操作：
-
添加Spring Cloud Sleuth依赖：
首先，你需要在项目的pom.xml或build.gradle文件中添加Spring Cloud Sleuth的依赖。以下是pom.xml中的Maven依赖：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>或者在
build.gradle中的Gradle依赖：implementation 'org.springframework.cloud:spring-cloud-starter-sleuth' -
确保启用了Spring Boot自动配置：
确保你的主应用类上使用了@SpringBootApplication注解，Spring Boot会自动配置Sleuth：@SpringBootApplication public class MyApplication { public static void main(String[] args) { SpringApplication.run(MyApplication.class, args); } } -
应用额外配置（如果需要的话）：
Sleuth提供了几乎零配置的追踪功能，但如果你需要的话，还可以调整Sleuth的一些配置。例如，调整日志模式或服务名称等。这些配置通常在application.yml或application.properties文件中完成：# application.yml spring: sleuth: sampler: probability: 1.0 # 采样率，1.0表示追踪所有请求 baggage-keys: userId,sessionId # 定义你需要传递的跟踪数据或者在
application.properties中：# application.properties spring.sleuth.sampler.probability=1.0 spring.sleuth.baggage-keys=userId,sessionId -
运行你的应用程序：
运行你的Spring Boot应用程序。Sleuth将自动嵌入支持追踪的库中，如Spring Web、Feign客户端、RestTemplate等。 -
查看日志输出：
当你的应用程序处理请求时，现在应该能在日志输出中看到Sleuth提供的Trace和Span信息。日志中的信息可能会类似于[appname,traceId,spanId,exportable]。 -
（可选）与分布式追踪系统集成：
如果你想将追踪信息发送到Zipkin等分布式追踪系统，你也需要添加相应的Spring Cloud Sleuth集成库。例如，对于Zipkin，<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-sleuth-zipkin</artifactId> </dependency>
这就是在项目中集成Spring Cloud Sleuth的基本步骤。Sleuth会协同其他Spring Cloud组件一起工作，并利用已有的Spring Boot自动配置特性以尽可能少的努力提供分布式追踪功能。一旦集成，你就可以更容易地追踪和调试微服务应用中的复杂数据流。
2. 跟踪和日志增强
2.1 Sleuth中Trace和Span的概念是什么？
在分布式追踪系统中，如 Spring Cloud Sleuth，Trace 和 Span 是两个核心概念，用于标识和记录跨服务调用的请求链路。
Trace
Trace（追踪）代表一个完整的事务或工作单元的执行过程。在微服务环境中，一个用户请求通常会涉及多个服务，这些服务之间的交互构成了一次完整的 Trace。Trace 通过一个唯一的 Trace ID 来标识，该 ID 在一次完整的用户请求中保持不变，即使请求在多个不同的服务间传递。
Trace 使得开发人员可以将整个请求流的日志关联起来，从而更容易地诊断跨服务边界的问题。
Span
Span（跨度）代表在一个 Trace 中，单个服务中对一个请求处理的时间片段。每当一个请求到达一个服务，就开始一个 Span；当请求离开服务时，Span 结束。Span 包含了必要的元数据，如操作名称（一般是 HTTP 方法和路径）、开始和结束时间、Span ID 和父 Span 的 ID 等。
Span 可能表示一个 HTTP 请求处理的时间，也可能是更细粒度的业务逻辑或数据库访问。在整个 Trace 中，所有 Span 汇总起来代表了请求的完整生命期。
在一个具体实例中，一个 Span 被创建来表示从用户微服务接收到一个用户请求的时刻，直到响应发回客户端为止的过程。这个 Span 包括 HTTP 请求的处理、可能调用的任何下游服务以及所需的任何数据库访问。每个下游服务调用也会创建一个新的 Span，这个 Span 将被标记为原始 Span 的子 Span。
对于父子 Span，通常在服务调用时将父 Span 的信息加入到请求中，而下游服务会从请求中取得这些信息，创建一个新的子 Span，并将其与父 Span 联结起来。
Spring Cloud Sleuth 自动为 Spring Boot 应用程序管理 Trace 和 Span，整合了诸如 Zipkin 这样的后端服务，以便于追踪信息的收集、存储和可视化。利用 Trace ID 和 Span ID，Sleuth 可以在整个分布式系统中跟踪并记录每个请求的详细路径，帮助开发者在出现问题时能够快速定位到问题发生的上下文。
2.2 Sleuth是如何对日志信息进行增强的？
Spring Cloud Sleuth 是一个分布式跟踪解决方案，它可以将跟踪信息添加到微服务应用中的日志条目中，以便更容易地关联和分析服务之间的请求链。Sleuth 主要通过在日志信息中增加跟踪ID（Trace ID）和跨度ID（Span ID）来达到增强日志的目的。
当 Sleuth 集成到 Spring Boot 应用中时，它会自动为日志条目添加以下信息：
- Trace ID：一个全局唯一的ID，表示一整个请求链路的ID，可以将整个请求链路中的所有日志条目关联起来。
- Span ID：一个特定请求操作的ID，表示一个基本的工作单元。一个 Trace 可能包含多个 Span，每个 Span 都会有自己的 Span ID。
- Parent Span ID（可选）：如果当前 Span 是在更大的 Trace 上下文中的一个子 Span，Parent Span ID 表示该 Span 的父 Span 的ID。
例如，一个集成了 Sleuth 的日志条目可能看起来像这样：
2019-04-12 15:55:36.712 INFO [order-service,a9b8c0aff3ef1eca,a9b8c0aff3ef1eca,false] 44377 --- [nio-8082-exec-2] c.e.o.OrderService : Order created: 12345
在这个例子中：
order-service是服务的应用名。a9b8c0aff3ef1eca是 Trace ID，同一条请求链上的所有日志都会有相同的 Trace ID。a9b8c0aff3ef1eca是当前 Span ID，标识了请求链中的一个特定工作单元。false表示这是否是出口 span（通常用于消息生产者），这里是false意味着不是出口 span。
Sleuth 的这些增强信息对于逐步调试和问题诊断非常有价值，因为它们允许开发人员和运维人员追踪日志条目中发生的特定用户请求，以及它们是如何穿过整个分布式系统的。
除此以外，Sleuth 还提供了其他特性，如跟踪系统间的异步消息传输、与 Zipkin 等分布式跟踪系统的集成，以及对日志框架的协同工作，比如与 Logback 的集成进一步增强日志条目等。
要使 Sleuth 生效，你需要在 Spring Boot 项目的依赖管理中加入 Sleuth 的依赖：
<!-- Maven 示例 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
通过上述配置，Spring Boot 的自动配置功能会初始化 Sleuth，从而在日志中包含 Trace ID 和 Span ID。如果你使用的是非 Spring Boot 的应用，那么你可能需要进行额外的配置。
2.3 如何在Sleuth中添加自定义Tag或Logs？
在 Spring Cloud Sleuth 中添加自定义 Tag 或 Logs，可以帮助你丰富分布式追踪信息，并提供更多上下文数据以便于分析和故障排查。在Spring Cloud Sleuth 2.x及更高版本，通常使用SpanCustomizer或Tracer接口来实现这一点。
1. 添加自定义Tag
自定义Tag通常是键值对，它可以在 Span 的上下文中提供额外的元信息。
以下是一个使用SpanCustomizer在控制器中添加自定义 Tag 的例子：
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import brave.SpanCustomizer;
@RestController
public class CustomController {
private final SpanCustomizer spanCustomizer;
public CustomController(SpanCustomizer spanCustomizer) {
this.spanCustomizer = spanCustomizer;
}
@GetMapping("/custom")
public String customMethod() {
// 添加自定义Tag
spanCustomizer.tag("custom.tag", "custom value");
return "hello";
}
}
2. 添加自定义Logs
在 Sleuth 中，Logs 可以用来记录一些重要的事件。这可以是简单的标记，比如表示一个重要步骤的开始或结束。
以下是如何在服务组件中使用Tracer添加自定义 Log 的例子：
import org.springframework.stereotype.Service;
import brave.Tracer;
@Service
public class CustomService {
private final Tracer tracer;
public CustomService(Tracer tracer) {
this.tracer = tracer;
}
public void doSomething() {
// 添加自定义Logs
tracer.currentSpan().annotate("custom.event");
// your logic here
}
}
高级用法 - 使用brave.Span进行更复杂的操作
如果你需要进行更复杂的自定义操作，你可能需要直接操作 Brave 库中的brave.Span对象。你可以通过Tracer来访问当前 Span 并进行修改：
import brave.Span;
import brave.Tracer;
@Service
public class AdvancedCustomService {
private final Tracer tracer;
public AdvancedCustomService(Tracer tracer) {
this.tracer = tracer;
}
public void doAdvancedThings() {
Span span = tracer.currentSpan();
if (span != null) {
// 在 Span 中添加自定义Tag
span.tag("advanced.tag", "advanced value");
// 记录一个自定义的事件时间戳
span.annotate("advanced.event");
}
// your logic here
}
}
在对分布式追踪信息进行自定义时，务必确保标签名和事件注释在你的应用程序中保持唯一性和一致性，以便它们在整个追踪中易于识别和理解。正确使用自定义 Tag 和 Logs 提供了额外的上下文，能够极大地帮助理解追踪数据并确定系统性能问题的根本原因。
2.4 Sleuth在日志中添加的信息如何帮助故障排查？
Spring Cloud Sleuth 通过在日志中添加跟踪和跨度标识符，帮助开发者快速定位和排查在微服务架构中出现的问题。每条日志信息中都包含了这些标识符，可以将日志条目与特定的服务请求调用关联起来。这些信息在故障排查时的具体帮助如下：
-
请求追踪：
日志中的 Trace ID 可用于识别整个分布式系统中的一个完整请求链路。这使开发者可以追踪一个请求经过的所有服务，以及在系统中它所执行的路径。 -
局部调用信息：
Span ID 提供了一个请求链路中特定局部调用的信息。这有助于开发者了解一个请求在特定服务或处理步骤中的表现。 -
分析日志关联性：
通过 Trace ID 和 Span ID 的关联，开发者可以查询和汇总涉及特定请求或工作单元的所有相关日志。这对于构造请求执行的故事线很有帮助。 -
并行处理和异步操作：
Sleuth 支持并行处理和异步消息传递日志条目的聚合。即使在复杂的消息驱动处理中，开发者同样可以追踪请求的执行情况。 -
错误定位：
当系统发生错误时，追踪信息能帮助开发者迅速找到问题发生的服务和执行点，因为 Trace ID 和 Span ID 能够标记出异常发生的具体位置。 -
性能监控：
通过分析 Trace ID 和 Span ID 的时间戳，开发者可以衡量请求的响应时间和服务的处理时间，从而评估系统的性能。 -
跨服务异常传播：
如果一个异常由链路上的一个服务引起并沿着调用链传播，Trace ID 有助于追溯异常的源头。 -
日志筛选和聚合：
在使用日志管理和分析工具（如 ELK Stack、Splunk）时，Trace ID 可以作为强大的筛选条件，将注意力集中在特定部分的日志数据上。 -
日志上下文信息：
Sleuth 还可以添加其他上下文信息，如标签和注解，为日志提供更详细的上下文，便于理解和分析请求的行为。
通过提供这些关键信息，Sleuth 显著提高了在分布式系统中日志的可用性和故障排查的效率。开发者可以利用这些信息构建问题的完整画面，更快地找到并解决故障。
3. Sleuth的配置和使用
3.1 如何配置Sleuth的采样策略？
在 Spring Cloud Sleuth 中，采样策略 (Sampling Policy) 决定了哪些请求将会被跟踪。在高流量的生产系统中，进行全量采样 (100% trace sampling) 可能会生成大量的跟踪数据，这可能会对性能产生影响，同时增加存储跟踪数据的成本。因此，配置适当的采样策略非常重要，以确保在可接受的性能损失范围内，捕获足够的数据执行有效的问题分析。
Spring Cloud Sleuth 提供了两种设置采样策略的方式：
-
百分比采样：
百分比采样允许你指定一个从0到1的采样率，这个数字表示一部分流量的比例将被采集跟踪信息。例如，0.1的采样率表示系统将记录大约10%的请求。你可以在配置文件中，通过’spring.sleuth.sampler.probability’ 属性来配置。spring: sleuth: sampler: probability: 0.1 # 指定采样率为10% -
自定义采样器：
如果标准的概率采样策略不满足具体需求，你也可以创建并配置自定义采样器。自定义采样器必须实现Sampler接口，并在 Spring 应用上下文中注册它。import brave.sampler.Sampler; @Configuration public class SleuthConfig { @Bean public Sampler defaultSampler() { return new CustomSampler(); } } public class CustomSampler extends Sampler { @Override public boolean isSampled(long traceId) { // 在这里编写自定义的采样逻辑 // 如果返回true，请求将被记录 // 如果返回false，请求将不被记录 } }在自定义采样器中，可以根据业务逻辑、特定的请求属性，比如来源、用户类型或请求路径等来决定是否执行采样。
Sleuth的采样决策是在请求的最初发起时做出。一旦请求被一个采样器标记为要记录，这个决定就会跟随请求流经各个微服务。因此，配置采样率是在服务网格中进行服务跟踪的一个重要决策点，应该事先充分考虑。适当的采样策略能够确保你能够收集到有代表性的数据，同时减轻系统的负担。
3.2 Sleuth可以整合哪些日志框架？
Spring Cloud Sleuth 可以整合主流的 Java 日志框架，这样日志中就可以显示追踪信息，例如 trace id 和 span id，便于开发者追踪和诊断问题。支持的日志框架包括：
-
Logback：
Logback 是 SLF4J 的一个实现，它是默认被 Spring Boot 支持的日志框架。Spring Cloud Sleuth与Logback的整合非常简单，不需要额外配置。在日志文件中使用预定义的转换词（例如%X{X-B3-TraceId},%X{X-B3-SpanId}）就可以在日志中输出追踪信息。 -
Log4j2：
Log4j2 也是 SLF4J 的一个实现，可以通过配置日志模式这些转换词来集成 Sleuth 的追踪信息。需要在日志配置文件（如log4j2.xml或log4j2.yaml）中指定 Sleuth 提供的 PatternLayout 转换器。 -
JUL（Java Util Logging）：
对于使用 Java 原生日志系统的应用，Sleuth 也能够提供支持，尽管这通常需要更多的配置来同步日志记录器的状态，因为 JUL 不是 SLF4J 的直接实现。
示例配置
以下是一些配置 Sleuth 与日志框架整合的示例：
对于 Logback (默认的 Spring Boot 日志框架)：
在 logback-spring.xml 文件中配置 PatternLayout:
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36}: %msg %X{X-B3-TraceId} %X{X-B3-SpanId} %n</pattern>
</encoder>
</appender>
对于 Log4j2：
在 log4j2.xml 文件中配置 PatternLayout:
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5level %logger{36} - %msg %X{X-B3-TraceId} %X{X-B3-SpanId}%n"/>
</Console>
在 Spring Cloud Sleuth 中，X-B3-TraceId 和 X-B3-SpanId 已经预先定义好了，可以在日志配置中直接使用。当启用 Sleuth 后，日志中会显示示例中 pattern 配置的格式，包含追踪 ID 和跨度 ID，这有助于诊断请求在分布式系统中的流转情况。
总之，Spring Cloud Sleuth 允许灵活整合不同的日志框架，通过在日志中输出关键的追踪信息，这使得在复杂的微服务体系中追踪请求成为可能。要实现这一点，通常只需要简单地修改你的日志配置文件，添加 Sleuth 提供的转换词即可。
3.3 Sleuth对性能有什么影响？如何最小化？
Spring Cloud Sleuth 是为了在分布式系统中提供透明的服务追踪而设计的工具。虽然它带来了对请求跟踪的有价值见解，但任何追踪系统都可能会对应用性能产生一定影响。Sleuth 的性能影响主要体现在：
-
附加网络负载：Sleuth 自动生成追踪数据（如 Span 和 Trace 信息），并可能将这些数据发送到远程追踪服务或追踪服务器（如 Zipkin）进行存储和分析。这需要额外的网络通信。
-
资源消耗：Sleuth 需要消耗内存和CPU资源来创建和管理追踪数据。
-
数据存储和处理：存储和处理追踪信息需要额外的存储资源和处理能力，尤其是高流量的系统。
为了最小化 Sleuth 对性能的影响，可以采取以下措施：
精细化采样
在 Sleuth 中，使用采样策略可以减少采集的追踪信息。通过设置采样率来控制记录多少请求的追踪数据。例如，通过配置只跟踪一定百分比的请求，可以显著减少对系统的影响。
异步和延迟写入
为了不阻塞业务处理流程，选择异步发送追踪数据到远程服务器。不要在主业务逻辑线程中立即处理追踪信息，而是推迟到业务逻辑完成后再发送追踪信息。
采用轻量级追踪服务
选择一个高效、轻量级的追踪系统，例如 Zipkin 或其他兼容的后端服务，以减少处理和存储追踪数据带来的负担。
追踪服务部署优化
为追踪服务（如 Zipkin）选择合适的部署架构和强大的硬件支持，可以增强处理收集到的追踪数据的能力。
系统资源管理
监控 Sleuth 和追踪系统占用的资源，并根据应用的负载情况适时提供必要的资源。
配置调优
深入了解 Sleuth 和追踪后端配置选项，根据具体需求进行调整。例如，可以优化存储时间、调整追踪数据的清理策略等。
避免冗余追踪
检查配置和代码，确保没有重复或不必要的追踪点。使用更加明智的追踪策略，以减少不必要的性能损耗。
性能测试和监控
进行性能测试以了解 Sleuth 在不同配置和负载下的性能表现，并监控生产环境中的实际影响。
通过采取这些措施，您可以将 Sleuth 对性能的影响降到最低，并从分布式追踪中获得最大的益处而不牺牲系统性能。
3.4 在使用Sleuth时，有哪些常见的配置问题？
在使用 Spring Cloud Sleuth 进行分布式跟踪时，你可能会遇到一些常见的配置问题。下面列举了一些典型问题和建议解决方法：
1. 依赖管理问题
确保项目依赖中包含了正确的 Sleuth 库。如果你使用了 Spring Boot，则添加 spring-cloud-starter-sleuth 依赖即可：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
2. 自定义日志配置冲突
如果你的应用程序使用了自定义的日志配置文件，比如 logback-spring.xml，必须确保不要覆盖 Sleuth 提供的配置，这些配置通常负责添加追踪信息到日志输出中。
3. 采样率设置
默认情况下，Sleuth 会对所有请求进行采样。如果你只想采样一部分请求，可以通过设置 spring.sleuth.sampler.probability 来调整采样率：
spring:
sleuth:
sampler:
probability: 0.5 # 表示50%的请求会被采样
4. 向 Zipkin 报告跟踪数据
如果你希望将跟踪数据报告给 Zipkin，必须在项目中添加 Zipkin 的依赖，并配置 Zipkin 的服务地址：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
配置 Zipkin 地址：
spring:
zipkin:
base-url: http://localhost:9411/
5. 异步通信跟踪
对于异步通信，比如使用了 Kafka 或 RabbitMQ 等消息中间件，确保消息头中的 Sleuth 跟踪信息不会丢失。
6. 服务名配置
如果你希望每个服务的日志中包含服务的名称，确保 spring.application.name 已经在配置文件中设置：
spring:
application:
name: my-service-name
7. 日志格式
通过 Sleuth 增加的日志跟踪信息（如 Trace ID 和 Span ID）可能会使你的日志格式看起来与之前不同。确保所有团队成员都了解这些改变，并按需调整日志解析工具和报警规则。
8. 跟踪信息的日志级别
确保应用程序的日志级别设置得当，以便在生产环境中收集足够的跟踪信息，但不要太详细以免产生过多日志。
9. 服务路由问题
如果你使用了服务发现和注册中心，如 Eureka，确保 Sleuth 可以正确解析服务实例间的请求链路。
10. 版本兼容性问题
如果你的服务使用不同版本的 Spring Cloud 或 Sleuth，请检查各版本之间的兼容性，并查阅文档了解需要进行哪些配置更改。
总结
当遇到关于 Sleuth 的配置问题时，阅读官方文档总是一个好的起点。同时，也可以参考社区支持、GitHub Issues 或者 Stack Overflow 上的类似问题和解决方案。
4. 与追踪系统的整合
4.1 Sleuth如何与Zipkin整合？
Spring Cloud Sleuth 与 Zipkin 的整合允许将追踪数据（Spans）发送到 Zipkin 服务器，这样可以利用 Zipkin 提供的存储、搜索、可视化和分析追踪数据的功能。整合过程涉及添加 Zipkin 客户端库的依赖、配置 Sleuth 以将数据发送到 Zipkin 以及可能需要配置Zipkin服务器。
添加依赖
首先，确保在项目的pom.xml中添加了用于Zipkin整合的Sleuth依赖。
<dependencies>
<!-- 更多依赖... -->
<!-- Zipkin和Sleuth整合的起步依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
</dependencies>
如果是使用Gradle，则在build.gradle中添加：
dependencies {
// 更多依赖...
// Zipkin和Sleuth整合的起步依赖
implementation 'org.springframework.cloud:spring-cloud-starter-zipkin'
}
配置 Sleuth
接着，你需要在application的配置文件（application.properties或application.yml）中指定 Zipkin 服务器的位置。
例如：
# application.properties
spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability=1.0 # 采样率（这里设置为1.0意味着采集所有追踪信息）
或使用yaml格式：
# application.yml
spring:
zipkin:
base-url: http://localhost:9411/
sleuth:
sampler:
probability: 1.0 # 采样率（这里设置为1.0意味着采集所有追踪信息）
上述配置告诉Sleuth将追踪数据发送到运行在本地9411端口的Zipkin服务器。
配置 Zipkin 服务器
确保你的环境中已经运行了Zipkin服务器。Zipkin可以作为独立的服务器运行，并提供了许多安装选项，包括Java jar文件、Docker镜像等。
测试追踪集成
当配置完成后，你可以通过触发应用程序中的请求操作来生成一些追踪数据，然后前往Zipkin UI查看追踪数据是否已经成功发送和可视化。
使用自定义端点（可选）
如果需要，你也可以配置自定义的端点来发送追踪数据，而不只是使用Zipkin的默认端点。
整合Sleuth和Zipkin后，你的微服务架构将拥有一个强大的追踪分析和查错能力。你将能够在Zipkin UI中看到由Sleuth自动生成的追踪信息，包括调用链路、时序图和详细的追踪数据。这极大地提升了开发和运维团队面对错误发现和性能优化任务时的效率。
4.2 如何配置Sleuth发送跟踪数据到追踪服务器？
Spring Cloud Sleuth 配合追踪服务器如Zipkin可以用于存储和可视化分布式追踪数据。配置 Sleuth 将追踪数据发送到追踪服务器通常涉及以下几个步骤：
1. 添加Zipkin依赖
首先，确保你的服务添加了 Zipkin 周边的依赖。在你的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>
2. 配置连接到追踪服务器
在你的application.properties或application.yml配置文件中，指定 Zipkin 服务的地址：
spring:
zipkin:
base-url: http://localhost:9411/
sleuth:
sampler:
probability: 1.0 # 设置为1.0表示采样所有请求，设置为较低值例如0.1来减少采样频率
或者在application.properties中配置：
spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability=1.0
这个配置示例会将所有请求的跟踪数据发送到运行在本地，端口为9411的Zipkin服务。采样概率为1.0表示对所有请求进行跟踪。
3. 启动Zipkin服务器
确保 Zipkin 服务器已启动，并且处于上述配置的spring.zipkin.base-url指定的地址和端口上。你可以自己搭建 Zipkin 服务器，或使用预打包的 Zipkin JAR启动。Zipkin 服务器通常用 Java 运行，但也可以运行在Docker容器中。
4. 监控和可视化
一旦完成配置并重新启动了应用，Sleuth 就会开始将追踪数据发送到 Zipkin 服务器。你可以打开 Zipkin 的 Web UI 在浏览器中查看和分析追踪数据。
例如，Zipkin Web UI默认地址为：http://localhost:9411/zipkin/
5. 进阶配置
你可以根据需求来进行更进一步的配置，例如设置不同的采样策略，只追踪特定的请求等等。
spring:
sleuth:
sampler:
probability: 0.5 # 例如，只采样50%的请求
Sleuth 和 Zipkin 的组合提供了强大的分布式系统隐踪能力，有助于迅速定位和解决跨微服务的问题。通过正确的配置，可以优化追踪数据的存储和查询，从而提升应用和服务的监控以及故障排查效率。
4.3 Sleuth支持哪些远程跟踪系统 besides Zipkin？
Spring Cloud Sleuth 是一个分布式跟踪解决方案，用于在Spring Cloud环境中跟踪消息的处理和传播。虽然Sleuth常与Zipkin结合使用，便于存储、查看和查询跟踪数据，但它也支持与其他远程跟踪系统集成。除了Zipkin，Sleuth还可以与以下系统配合使用：
-
Elastic APM：
Elastic APM（Application Performance Monitoring）是Elastic Stack（Elasticsearch、Logstash和Kibana）的一部分，提供了一套监控解决方案。Spring Cloud Sleuth 可以将跟踪数据发送到 Elastic APM 上，以便进行展示和分析。 -
Jaeger：
Jaeger 是由 Uber 开发的一个开源分布式追踪系统。Spring Cloud Sleuth 支持将跟踪数据发送至 Jaeger，为用户提供对分布式事务监控的功能。 -
Wavefront：
Wavefront 是一个度量分析平台，提供云应用实时监控。通过集成，Spring Cloud Sleuth 可以将指标和跟踪数据推送到 Wavefront，利用其数据分析和可视化能力。 -
Datadog：
Datadog 是一种监控和分析平台，用于在云时代扩展的基础设施上。Datadog Trace Agent 可以接收 Sleuth 生成的跟踪数据，并集成至 Datadog 的监控平台中。 -
Honeycomb：
Honeycomb 提供了强大的查询语言和分析功能，针对复杂系统中的性能问题和故障提供了实时洞察。 -
Dynatrace：
Dynatrace 是一款提供全栈监控的软件，它可以接收 Sleuth 搜集的数据并在其平台上进行分析。
为了与这些系统集成，可能需要使用或者创建相关的跟踪数据发送者库，或者利用被称为brave的跟踪库的相关发送组件（如果它们有提供的话）。这些发送组件负责将 Sleuth 中的跟踪信息格式化为特定于远程跟踪系统的格式，并发送到它们的接收端点上。
每种远程跟踪系统都有其独特的特点和优势，选择哪个系统应根据特定的监控需求、扩展性、成本和现有的监控基础设施来决定。通过整合 Sleuth 到这些系统，可以更好地监控、分析和优化微服务架构的性能与健康状况。
4.4 当无法连接到跟踪服务器时，Sleuth会如何处理数据？
Spring Cloud Sleuth 是一个监控和记录应用间请求的库，它在分布式系统中生成追踪信息，包括 trace id 和 span id 等。当不能连接到追踪服务器（如 Zipkin）时，Sleuth 的处理方式取决于所使用的追踪库（例如 Zipkin、Brave）以及相关配置。
-
本地日志记录：
如果 Sleuth 无法将追踪数据发送到追踪服务器，它会继续运行，并且根据配置决定是否将追踪数据记录到本地日志中。默认情况下，Sleuth 使用日志框架（如 SLF4J 和 Logback）记录追踪信息。 -
缓冲和重试：
在某些配置下，追踪客户端（如 Brave）可能缓存跟踪数据，并在追踪服务器可用时重试发送。这意味着只有在缓存空间被填满或重试次数达到限制时，追踪信息才会丢失。 -
采样策略：
Sleuth 支持可配置的采样策略。如果服务端有问题，可以通过设置采样率来减少发送给追踪服务器的数据量，临时缓解问题。 -
掉线策略和自我保护：
在 Sleuth 和 Zipkin 集成的情况下，如果 Zipkin 服务器宕机，Sleuth 会停止向其发送请求，这是自我保护的一种形式，以免过多的重试请求影响应用性能。 -
清理策略：
如果在一段时间内跟踪服务器持续不可用，Sleuth 或其底层库（如 Brave）可能会清理掉缓存的跟踪数据，以便释放内存资源。 -
控制策略：
依赖于所使用的追踪库，你可能能配置它们的连接超时、重试间隔和清理策略，从而在追踪服务器不可用时保持一定的数据安全。
一般来说，Spring Cloud Sleuth 设计得足够鲁棒，不会因为暂时的追踪服务器问题而影响应用程序的正常运行。然而，最佳实践是监控追踪服务器的健康状况和与 Sleuth 的连接状态，以确保追踪数据不会在出现问题时丢失。
为了处理无法连接跟踪服务器的情况，你应该决定如何配置追踪库以及本地日志记录是用于开发调试还是可选项。在生产环境中，推荐设置合理的缓冲、重试和清理策略，以及合理的监控和告警机制。在选用追踪服务器时，你也可以考虑它们的高可用性架构和故障转移能力，以提高整个系统的稳定性。
5. 异步通信和消息跟踪
5.1 Sleuth如何跟踪异步请求？
Spring Cloud Sleuth 提供了跟踪异步请求的能力，从而使开发者能够在分布式系统或微服务架构中追踪和记录异步操作中的调用链。Sleuth 通过在异步操作的上下文中传递 Trace 和 Span 信息来实现这一点。以下是 Sleuth 跟踪异步请求的主要方式：
使用 @Async 注解
如果你在 Spring 应用中使用 @Async 注解来执行异步方法调用，Sleuth 自动传递 Trace 和 Span 的上下文。例如：
@Async
public Future<String> asyncMethod() {
// 自动追踪该异步方法的执行
return new AsyncResult<>(someAsyncOperation());
}
在这个例子中，asyncMethod 被声明为异步方法，任何对该方法的调用都会在独立的线程中异步执行，并且 Sleuth 会自动创造一个新的 Span 继承父 Span 的信息。
使用 CompletableFuture
对于使用 CompletableFuture 或其他类似机制的异步操作，Sleuth 会将 Trace 和 Span 的上下文信息移交给在 CompletableFuture 中执行的代码块。例如：
CompletableFuture.supplyAsync(() -> {
// 嵌入在 CompletableFuture 中的逻辑也会被 Sleuth 自动追踪
return someAsyncOperation();
})
自定义线程池
如果您使用定制的 Executor 或 ExecutorService 来处理异步任务，需要确保 Sleuth 能够装饰它以传递跟踪上下文。你可以使用 TraceableExecutorService，它是 Sleuth 提供的 ExecutorService 的包装，以支持跟踪：
ExecutorService executorService = Executors.newFixedThreadPool(5);
ExecutorService traceExecutorService = new TraceableExecutorService(beanFactory, executorService);
CompletableFuture.runAsync(runnable, traceExecutorService); // runnable 的执行将会被跟踪
自定义异步组件
对于自定义异步组件（如消息监听器、WebSocket 处理器等），你可能需要手动创造新的 Span 或将现有 Span 的信息传递给异步执行代码块。Sleuth 提供了一系列的工具来在异步操作前后操作 Span 的信息。
Span newSpan = this.tracer.nextSpan().name("custom-operation").start();
try (Tracer.SpanInScope ws = this.tracer.withSpan(newSpan.start())) {
// 执行自定义异步操作的逻辑
}
finally {
newSpan.end();
}
在使用 Sleuth 时，务必确保系统中的所有异步组件都考虑到了跟踪上下文的传递，这样才能在整个调用链中保持跟踪的完整性。在 Sleuth 的官方文档中，也可能找到更多关于如何处理复杂异步情况的指导和最佳实践。
5.2 Sleuth对RabbitMQ或Kafka消息跟踪提供了哪些支持？
Spring Cloud Sleuth 提供了 RabbitMQ 和 Kafka 消息跟踪支持，以便在分布式消息系统中跟踪消息的流动。
RabbitMQ 消息跟踪
使用 Spring Cloud Sleuth 对 RabbitMQ 消息进行跟踪时，Sleuth 集成了 Spring AMQP，通过在消息 headers 中添加特定的跟踪信息，如 Trace ID 和 Span ID，来跟踪消息事件。当一个消息从生产者发送到 RabbitMQ 时，Sleuth 会将跟踪信息添加到 AMQP 消息属性中。消息消费者接收消息时，同样会读取这些跟踪信息，并将其关联到相关的追踪和 Span 中。
在发送和接收消息时，Sleuth 会自动创建新的 Span 或将消息关联到现存的 Trace 中，确保消息的发送和接收可以在跟踪系统中正确显示。
Kafka 消息跟踪
类似地，Sleuth 对 Kafka 的支持涉及将跟踪信息和 Span 上下文嵌入到 Kafka 消息的 headers 中。通过使用 Spring Kafka，Sleuth 可以在生产和消费消息时维护跟踪上下文。这样，每个消息相关的处理过程都会被追踪和记录，跟踪信息可以随着消息在 Kafka 主题（topics）间的流动而同步传播。
消息跟踪的启动和配置
要启用 RabbitMQ 或 Kafka 的消息跟踪，你需要在你的 Spring Boot 应用中包含 Sleuth 的依赖以及 Spring Cloud Stream Binder (对于 Kafka 或 RabbitMQ) 的依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-binder-rabbit</artifactId>
</dependency>
<!-- 或者 Kafka 消息跟踪 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-binder-kafka</artifactId>
</dependency>
一般来说，Sleuth 会自动配置消息跟踪，如果你使用了 Spring Cloud Stream，那么无需额外配置跟踪和 Span 传播。
消息跟踪的自定义和调整
如果需要自定义消息跟踪，例如调整采样率或添加额外的标签，你可以在 Sleuth 配置中进行设置。
注意事项
- 确保 Sleuth 能够和你的消息中间件集成。某些复杂的场景，如消息头过滤或自定义序列化、反序列化可能会影响 Sleuth 的跟踪信息传播。
- 对于分区消息、重试机制和消息顺序等高级消息特性，应该了解 Sleuth 是如何跟踪和处理这些情况的。
- 在开发和测试过程中，调查消息产生的 Log Spans，确认 Trace ID 和 Span ID 被正确嵌入和提取。
整体而言，通过使用 Spring Cloud Sleuth 进行消息跟踪，可以更容易地理解和调试微服务架构中消息的传递流程，从而改善系统的可观测性和问题诊断能力。
5.3 在使用Spring Integration时，Sleuth如何维护跟踪上下文？
当使用Spring Integration框架进行消息传递时，Spring Cloud Sleuth 自动集成其追踪功能以确保追踪上下文在消息通道和服务消费者之间得以维护。Sleuth通过向消息头中添加追踪信息（例如trace id、span id、sampling flags等）确保整个消息流程的每一步都可以被追踪。
这样，无论消息是通过消息队列，还是直接通过应用内通道进行传递，Sleuth都能够追踪整个消息的处理过程，并且与整体链路追踪信息整合。以下是Spring Cloud Sleuth如何实现的一些关键点：
1. 拦截消息
Sleuth使用Spring Integration的ChannelInterceptor来在消息发送（即output channel）和接收（即input channel）时对消息进行拦截。这样能够在消息发送之前为其添加相关的追踪信息，同时在消息接收时从消息头提取并重建追踪上下文。
2. 消息头的追踪信息
Sleuth确保在消息头中添加以下追踪信息：
- Trace ID：整个请求链路的唯一标识符。
- Span ID：表示当前消息处理步骤的唯一标识符。
- Parent Span ID：前一个处理步骤的Span ID。
- Sampling Decision：是否应该采集当前链路的信息。
3. 传播上下文
当消息在不同服务或系统间发送时，Sleuth负责维护传递追踪上下文。这意味着进入消息通道的每条消息都会携带追踪信息，无论这些消息是在单个应用内部传递，还是跨越多个服务传递。
4. 追踪聚合服务
当使用Spring Integration的聚合器模式时（例如聚合多条消息或拆分消息），Sleuth能够为每一个聚合或拆分的过程创建单独的Span。这样可以很清楚地看到追踪过程中的消息处理变化。
5. 实时更新追踪信息
Sleuth也确保对于那些可能被修改或增加信息的消息（例如转换器或者链式处理器中的消息）追踪信息能够被实时更新，确保追踪的连贯性。
通过这些机制，Sleuth能够在基于Spring Integration的消息传递中维护和传播追踪上下文，这对于复杂的数据流和消息驱动的服务之间的追踪和调试是至关重要的。
5.4 如何确保在使用多线程时，Sleuth的上下文正确传递？
在使用Spring Cloud Sleuth 进行跟踪时，它通过在调用链中传递一个唯一的trace ID和多个span ID来追踪请求，以实现分布式跟踪。在多线程环境中，为了确保Sleuth跟踪上下文（包括 trace ID 和 span ID）能从父线程正确地传递到子线程，需要采取一定的措施来维护和传播这些上下文信息。以下是一些确保Sleuth上下文在多线程应用中正确传递的策略：
-
使用Spring’s
@Async注解：
Spring框架提供@Async注解在新线程中异步执行方法。Sleuth已与@Async集成，能自动传播trace上下文。@Async public void asyncMethod() { // Trace上下文会从调用线程自动传播到这里 } -
使用TraceableExecutorService:
对于手动创建的线程或ExecutorService，可以使用Sleuth提供的TraceableExecutorService包装器来装饰ExecutorService，从而使trace上下文得以传入新的线程。ExecutorService executorService = Executors.newCachedThreadPool(); // 包装你的ExecutorService ExecutorService traceableExecutorService = new TraceableExecutorService(beanFactory, executorService); -
利用
@Scope("prototype")和Tracer:
如果需要在新线程中手动创建bean，并希望Sleuth的trace上下文关联这些bean，可以考虑使用prototype作用域和Sleuth的Tracer对象来建立上下文。 -
继承InheritableThreadLocal:
如果你手动管理线程而不是用Spring的执行器服务，可以考虑使用InheritableThreadLocal来存储trace信息，因为它可以自然地将本地属性传递给子线程。 -
自定义工具类:
使用Spring Cloud Sleuth提供的工具类，如Span和Tracer来手动管理和传递trace上下文。@Autowired private Tracer tracer; public void createThread() { Span span = tracer.nextSpan().name("newThread").start(); try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) { // 开始执行异步代码，trace上下文会传递到子线程中 } finally { span.finish(); // 完成span的追踪 } } -
Hystrix并发策略:
对于使用了Hystrix线程隔离的应用，需要设置自定义的Hystrix并发策略，确保trace上下文在Hystrix命令执行时也能传递。
使用这些策略，能够确保trace上下文在多线程或异步编程环境中得以正确传递，让Sleuth的跟踪功能充分运作，为分布式跟踪提供了全面的支持。
6. 高级特性和自定义
6.1 如何扩展Sleuth的功能，比如添加新的Span导出器？
Spring Cloud Sleuth 是一个分布式追踪解决方案，其设计允许用户通过扩展点定制和扩展功能。例如，如果需要添加新的 Span 导出器来发送追踪数据到一个专属的追踪系统或分析服务，可以按照以下步骤进行扩展：
-
实现 SpanReporter 接口：
Spring Cloud Sleuth 提供了SpanReporter接口，可以实现该接口来创建自定义的 Span 导出逻辑。import brave.handler.SpanHandler; import brave.Span; import brave.propagation.TraceContext; public class CustomSpanReporter extends SpanHandler { @Override public boolean end(TraceContext context, MutableSpan span, Cause cause) { // 对Span数据进行转换和发送 MyCustomSpanFormat customSpan = convertToCustomFormat(span); sendSpanToExternalSystem(customSpan); return true; // true 表示Span已处理完毕 } private MyCustomSpanFormat convertToCustomFormat(MutableSpan span) { // 转换Sleuth的Span为自定义格式 } private void sendSpanToExternalSystem(MyCustomSpanFormat customSpan) { // 将转换后的Span发送到外部系统 } } -
注册你的 SpanReporter：
应用的 Spring 配置中需要注册这个新实现的 SpanReporter。import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class TracingConfig { @Bean SpanHandler customSpanReporter() { return new CustomSpanReporter(); } } -
使用你的 SpanReporter：
一旦注册，Sleuth 的 Spring Boot 自动配置就会将你的 CustomSpanReporter 用作发送追踪数据的组件。每当一个 Span 完成时，这些信息就会通过 CustomSpanReporter 发送到你的目的地。 -
测试：
确保测试自定义的 SpanReporter，在测试环境中验证Span的收集和发送工作正常。 -
性能优化和异常处理：
在导出 Span 数据时，考虑到性能的影响，可能需要使用异步机制进行 Span 数据的传输，同时也要确保合适的错误处理和异常安全。 -
集成追踪系统的客户端库：
如果外部追踪系统提供了Java客户端库，可以在 CustomSpanReporter 中整合使用，以便利用系统自带的传输优化和数据格式化功能。
通过这种方式，Sleuth 允许开发者添加自定义的数据导出方式，以与任意追踪系统集成。开发者可以完全控制数据如何被转换和发送出去。扩展 Sleuth 与引入新技术栈或组件的兼容性一定要谨慎，以确保不会对现有系统的稳定性和性能产生负面影响。
6.2 Sleuth提供了哪些钩子来自定义跟踪行为？
Spring Cloud Sleuth 提供多种机制来自定义跟踪行为，包括其生命周期内的各个点进行定制、插入自定义逻辑或修改现有行为。以下是一些扩展和自定义Sleuth跟踤行为的钩子：
-
Sampler：
一个Sampler决定了某个请求是否会被跟踪。你可以自定义一个Sampler来决定什么样的请求应该被采样。场景可能包括基于请求类型、来源、负载或其他自定义标准进行采样。@Bean public Sampler customSampler() { // 自定义逻辑来决定是否要采样 return traceId -> ... ; } -
Span Customizer：
SpanCustomizer用于向当前活跃的Span添加自定义标签或注解。这个接口通常用于无法访问Span实例的情况下添加附加信息。@Autowired private SpanCustomizer spanCustomizer; public void doSomething() { this.spanCustomizer.tag("my.tag", "value"); this.spanCustomizer.annotate("my.annotation"); // ... 执行业务逻辑 } -
Baggage Fields：
Baggage 字段可以携带跨服务调用的信息。如果你需要在微服务架构中传递某个特定信息（如用户ID、会话信息等），可以使用 Baggage API 自定义字段。@Bean BaggageField userIdField() { return BaggageField.create("userId"); } -
SpanHandler：
SpanHandler拦截 Span 报告的周期。可以使用它来修改、重写、添加或者丢弃某些 Span。@Bean SpanHandler myCustomSpanHandler() { return new SpanHandler() { @Override public boolean end(TraceContext context, MutableSpan span, Cause cause) { // 自定义逻辑 return true; // 返回false将丢弃Span } }; } -
Tracer：
如果你需要在代码中手动创建新的跟踪或操作当前的跟踪，可以注入Tracer对象，并使用它来自定义跟踪逻辑。@Autowired private Tracer tracer; public void doWork() { Span newSpan = tracer.nextSpan().name("new_span").start(); try (Tracer.SpanInScope ws = tracer.withSpanInScope(newSpan)) { // ... 执行带有新Span的操作 } finally { newSpan.finish(); } }
自定义跟踪行为的时候，重要的是要确保准确理解了 Spring Cloud Sleuth 的数据模型和生命周期，防止不正确的自定义逻辑影响跟踪数据的准确性和系统的性能。另外，保持跟踪标签的一致性也是很重要的，因为这些标签会被搜集并可能显示在追踪数据分析平台（如 Zipkin）上，标签的一致性有助于保持数据的清晰和易于理解。
总的来说，Spring Cloud Sleuth 提供了强大的扩展能力和灵活性，以适应不同的监控和跟踪需求。通过利用上述钩子，可以构建出满足你的特定业务需求的分布式追踪解决方案。
6.3 在不修改代码的情况下，如何在Sleuth中忽略某些路径的跟踪？
在使用 Spring Cloud Sleuth 追踪请求时，有时你可能想要排除某些路径不被跟踪，尤其是一些健康检查、静态资源或者内部管理端点。Sleuth 提供了配置选项来实现这一点，而不需要修改任何代码。
在 application.yml 或者 application.properties 配置文件中，可以使用 spring.sleuth.web.skip-pattern 属性来设定匹配模式，以忽略特定的路径。以下是在 application.yml 中配置的示例：
spring:
sleuth:
web:
skip-pattern: '/actuator/.*|/static/.*'
在这个例子中，所有访问 /actuator/* 和 /static/* 路径的请求将不被 Sleuth 追踪。多个路径模式间使用管道符号 | 分隔。
这种配置方式特别有助于降低 Sleuth 对系统的性能影响，避免对业务无关的请求进行跟踪。这也可以帮助减少产生的跟踪数据量，仅关注对问题诊断有帮助的路径和端点。
从 Spring Cloud 2020.0.0 版本开始（与 Spring Boot 2.4.x 配套使用），spring.sleuth.web.skip-pattern 被弃用，由 spring.sleuth.web.ignored-paths 替代。新的配置方式允许直接列出需要忽略的路由列表：
spring:
sleuth:
web:
ignored-paths: /actuator/health, /actuator/info, /static/**, /favicon.ico
在这个配置中，所有匹配指定列表内的路径都将不会被 Sleuth 所追踪。
请注意，具体的配置名称和使用方式可能会随着不同版本的 Spring Cloud Sleuth 发布而有所变动，所以应该参考对应版本的官方文档来确定正确的配置方式。
6.4 如何在Sleuth中自定义Span命名策略？
在 Spring Cloud Sleuth 中，默认情况下，Span 的命名通常基于请求的 HTTP 路径或方法名称等自动生成。但有时候根据实际需求，你可能需要自定义 Span 的名称以便更清楚地表达业务逻辑或操作内容。可以通过以下方法自定义 Span 命名策略：
对于 HTTP 请求
你可以实现 SpanCustomizer 接口，以编程方式在请求处理流程中自定义 Span 名称：
import org.springframework.cloud.sleuth.SpanCustomizer;
import org.springframework.stereotype.Component;
@Component
public class MyCustomSpanDecorator implements SpanCustomizer {
@Override
public void customize(org.springframework.cloud.sleuth.Span span) {
// 自定义逻辑来设置 Span 名称
span.name("custom-span-name");
}
}
上述例子中，通过调用 span.name("custom-span-name") 设置了 Span 的名称。
注意： 请根据要处理的类或方法的不同，在合适的地方调用 SpanCustomizer 的实现。
对于注解
如果你的请求处理方法使用了 @NewSpan 或 @ContinueSpan 注解，可以通过注解属性来自定义 Span 名称：
import org.springframework.cloud.sleuth.annotation.NewSpan;
public class MyClass {
@NewSpan(name = "custom-method-span")
public void myMethod() {
// 与 Span 关联的业务逻辑
}
}
在上述例子中，myMethod 的执行会产生一个名为 custom-method-span 的新 Span。
使用 AOP
你也可以使用 Spring AOP 在切点（pointcut）上创建通知（advice），在通知中访问 Sleuth 的 Tracer 来定制 Span 名称：
import brave.Tracer;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
@Aspect
@Component
public class CustomSpanAspect {
private final Tracer tracer;
public CustomSpanAspect(Tracer tracer) {
this.tracer = tracer;
}
@Around("execution(* com.example.MyService.*(..))")
public Object aroundAdvice(ProceedingJoinPoint pjp) throws Throwable {
// 获取当前的 Span
brave.Span span = tracer.currentSpan();
if (span != null) {
// 设置自定义 Span 名称
String spanName = "custom-" + pjp.getSignature().getName();
span.name(spanName);
}
try {
return pjp.proceed();
} finally {
if (span != null) {
span.finish(); // 手动结束 Span
}
}
}
}
在上述代码中，切点指定了一个方法执行模式，切面的环绕通知中访问当前 Span 并自定义了其名称，并在方法执行结束时手动结束 Span。
注意事项
- 确保自定义的 Span 名称符合业务上的语义，便于识别和查询。
- 尽量不要在 Span 名称中包含敏感数据或者高基数的参数（如用户ID），以免影响存储和查询效率。
- 自定义 Span 名称时请注意不要产生命名冲突或覆盖预定义的重要 Span 名称。
使用自定义的 Span 名称策略可能需要在不同的地方调整配置或添加逻辑，根据你的应用情况和 Sleuth 版本，选择最适合的方法来实现。对于不同的业务场景和需求，自定义的逻辑可能会有很大差异。
在开发和测试中，请验证自定义 Span 名称是否按预期工作，并通过 Sleuth 的日志和 Zipkin 等跟踪系统进行确认。
7. 实践和最佳实践
7.1 使用Sleuth有哪些实战技巧？
在实践中使用 Spring Cloud Sleuth 时，可以应用下面的一些技巧来更好地跟踪和理解分布式系统中的请求流：
1. 合理配置采样策略
- 通过定制采样策略，比如基于请求类型或是频率配置针对性采样，来减少日志量并提高性能。
- 设置适当的采样率以平衡监控需求与系统开销。
2. 使用日志关联
- 在日志中加上Sleuth提供的 trace 和 span id，这样在查看日志文件时，可以轻松追踪到请求跨服务的路径。
- 通过日志模式（如使用
logging.pattern.level）在日志中包含 Sleuth 的追踪标识符。
3. 自定义Span信息
- 使用
SpanCustomizer或 Spring Cloud Sleuth 注解来添加自定义Span信息，以记录更丰富的业务逻辑信息。 - 对关键业务逻辑添加额外的Span，并合理命名，以便在追踪时更易于理解。
4. 同步与异步处理
- 明确区分同步与异步处理的追踪方式，确保异步处理中的上下文不会丢失，尤其在
@Async操作中。
5. 使用Baggage
- 利用Baggage API共享跨进程数据，比如用户的Session ID或租户ID，但要避免在跨服务调用中Share过多的信息，避免产生不必要的网络开销。
6. 整合Zipkin
- 将Sleuth与Zipkin或其他追踪系统结合，用来保存、搜索和可视化追踪信息。
- 配置Zipkin服务器地址，确保追踪数据能够正常发送。
7. 模拟追踪和问题解决
- 在开发阶段，对关键应用路径进行追踪模拟和测试，以熟悉追踪数据的格式和涉及的服务。
- 当发生问题时，使用追踪数据作为起点进行问题调查和研究。
8. 处理追踪数据
- 对接收到的追踪数据进行恰当处理，尤其是在生产环境中收集的数据可能非常庞大。
- 如果追踪信息存储在日志中，确保使用适当的日志滚动策略来管理这些数据。
9. 性能优化
- 关注Sleuth对系统性能的影响，特别是在高并发和请求量大的生产环境中，密切观察系统性能指标。
- 如果发现性能瓶颈，可以通过异步追踪或调整采样率来优化。
10. 持续学习与改进
- 定期审查追踪数据，借此识别模式、优化性能和改进错误处理。
- 根据系统迭代和情况变化，适时调整追踪策略与相关配置。
通过上述实战技巧，你可以更有效地利用Spring Cloud Sleuth来提高分布式系统的透明度和可维护性，在必要时快速定位和解决问题。
7.2 在微服务架构中引入Sleuth的最佳实践是什么？
在微服务架构中引入Spring Cloud Sleuth 的最佳实践可以帮助开发者更有效地管理和跟踪分布式服务间的请求，以及优化应用程序的性能。以下是一些推荐的最佳实践：
-
启用默认设置：
在大多数情况下，Sleuth的默认配置会满足基本的分布式跟踪需求。仅在发现性能问题或有特殊需求时才进行调整。 -
追踪ID规范：
使用 Sleuth 自动生成的 Trace ID 和 Span ID，保持这些ID在整个跟踪链中的一致性。 -
一致的日志记录：
确保所有的微服务都使用一致的日志记录格式，包括 Trace ID 和 Span ID，以便能在分布式环境中轻易追踪事件。 -
集成其他追踪系统：
将 Sleuth 集成到 Zipkin 或其他追踪系统中，以便更容易地存储、查询和可视化追踪数据。 -
异步及多线程操作：
对于在新线程或异步操作中进行的后续调用，确保 Trace ID 和 Span ID 能正确传递。使用 Sleuth 提供的 TraceableExecutorService 或其它交由 Sleuth 管理的组件以确保上下文传递。 -
边缘服务追踪：
在 API 网关或边缘服务（如 Spring Cloud Gateway）上启用 Sleuth ，以确保从用户请求开始就能够进行追踪。 -
高级采样策略：
根据需要配置采样策略，你可以调整它们来进行选择性跟踪以减少性能开销。 -
异常处理：
将异常和错误信息包含在跟踪数据中，这为故障排除提供了关键信息。 -
在CI/CD中集成Sleuth：
在持续集成和持续部署的流程中包含 Sleuth 的设置和部署，以确保全部服务能配合 Sleuth 工作。 -
Sleuth与Actuator的结合：
利用 Spring Boot Actuator 来公开 Sleuth 的度量和信息。 -
调整日志级别：
为了减少生产中的性能开销，只在需要时（如故障排除阶段）将日志级别设置为 DEBUG 或 TRACE。 -
性能监控：
监测 Spring Cloud Sleuth 引入后对系统性能的影响，及时调整配置以优化性能。 -
文档与培训：
为团队成员提供关于 Sleuth 的文档，培训他们如何利用 Sleuth 追踪分布式系统的信息。
通过遵循这些最佳实践，团队可以最大化地利用 Spring Cloud Sleuth 提供的分布式追踪功能，优化微服务架构的监控和维护工作。
7.3 使用Sleuth时应该如何管理Span的生命周期？
在使用 Spring Cloud Sleuth 进行分布式追踪时，正确管理 Span 的生命周期是至关重要的。Span 是对一次逻辑请求的追踪或一项工作的描述，可以代表一个 HTTP 请求、一个数据库查询或者是内部过程调用。Span 的生命周期从创建（被创建时会被赋予一个唯一的ID和可能的父ID）开始，以完成结束。
以下是在使用 Sleuth 时管理 Span 的生命周期的一些最佳实践：
-
使用自动配置：
通过自动配置，Spring Cloud Sleuth 可以为你的 Spring Boot 应用自动启动和结束 Spans。例如，Sleuth 会为每个 HTTP 请求创建一个新的 Span，并在请求结束时自动完成 Span。 -
显式创建和关闭 Span：
有些情况下，你可能需要手动创建和结束 Span，特别是在异步工作流或者非请求驱动类型的处理中。import brave.Span; import brave.Tracer; Tracer tracer; // Autowired 或通过构造函数注入 Span newSpan = tracer.nextSpan().name("customSpan").start(); try (Tracer.SpanInScope ws = tracer.withSpanInScope(newSpan.start())) { // 执行操作 } finally { newSpan.finish(); } -
在异步操作中传递 Span 上下文：
如果工作被派发到了另一个线程，那么需要将当前的 Span 上下文正确地传递给执行工作的线程。@Autowired private Tracer tracer; public void asyncMethod() { Span span = tracer.currentSpan(); executorService.submit(() -> { try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) { // 异步操作 } finally { span.finish(); } }); } -
避免使用延长的 Span：
一个 Span 应当代表一个逻辑上的工作单位。尽量避免创建长时间运行的 Span，因为它们可能会导致内存泄漏或追踪日志难以解读。 -
Span 标签和注解：
在 Span 生命周期内，添加标签（也称为 tags）和注解（annotations），以丰富追踪信息，可以附带记录请求的元数据，比如HTTP参数、响应状态码等。 -
异常处理：
确保在 Span 的生命周期内正确处理异常。如果一个操作抛出了异常，该异常应当被记录在那个 Span 内，并且 Span 应当被正确结束。Span span = ...; try { // protected logic } catch (Exception e) { span.error(e); // 记录异常 throw e; } finally { span.finish(); // 确保Span始终被结束 }
正确的管理 Span 的生命周期可以确保在有限的性能代价下，提供可靠和可读的追踪数据。如果处理不当，可能会导致追踪数据丢失或不准确，甚至出现性能问题。在实际使用中，你应该结合应用的具体情况，合理设计和规划 Span 的生命周期管理。
7.4 集成Sleuth后，对微服务应用的监控和运维有哪些影响？
集成了 Spring Cloud Sleuth 后，对微服务应用的监控和运维有着积极的影响：
-
提高了可见性：
Sleuth 通过添加 span 和 trace ID，使得分布式系统的请求能够在不同的微服务之间被追踪。这提高了系统可见性，使监控和追踪用户请求在整个系统中的流动成为可能。 -
简化问题排查：
当系统出现延迟或错误时，Sleuth 提供的分布式追踪信息可以帮助快速定位问题所在的服务或应用，这大大简化了故障排查和根因分析的过程。 -
性能监控：
Sleuth 收集的时间戳和持续时间数据可以用于分析微服务的性能，识别潜在的瓶颈和优化点，这对于性能监控和调优至关重要。 -
集成追踪系统：
Sleuth 可以与 Zipkin、Jaeger 等分布式追踪系统集成，提供一个详细的、可视化的追踪数据展示平台。 -
增强日志有效性：
Sleuth 在日志中加入了追踪信息，使得在微服务环境中生成的日志不再是孤立的，日志分析工具可以利用这些信息关联各服务日志。 -
自动化和一致性：
Sleuth 的自动化跟踪减少了开发人员的额外编码工作，也为分布式系统建立了一致的追踪方式。 -
便于理解的交易流程：
Sleuth 提供的数据可以帮助理解复杂的事务流程，包括哪些组件被调用，以及它们是如何被调用的。 -
促进微服务架构的优化：
随着对系统行为和性能的洞见增强，Sleuth 可以帮助架构师和开发人员做出更明智的架构决策，促进系统架构的不断优化。 -
改善告警系统：
有了准确的分布式追踪信息，可以设计更精确的告警规则，减少误报，并快速响应系统中的异常。
尽管集成了 Sleuth 改善了监控和运维，但你也需要意识到潜在的性能开销，尤其是在高流量的生产环境中。应合理设置采样策略和日志记录等级，确保不会对应用响应性能造成过大影响。
总体来说，Spring Cloud Sleuth 为微服务架构带来了一系列的监控和运维优势，特别是有助于在分布式系统中保持高可用性和弹性。通过Sleuth，可以在不同的服务和微服务间保持上下文，为运维团队提供了宝贵的追踪和诊断信息。
扫一扫
45万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
