要实现spring cloud sleuth的链路追踪,需按以下步骤操作:1. 引入依赖开启基础追踪能力;2. 查看日志中的traceid和spanid用于识别请求链路;3. 实现跨服务链路追踪确保上下文自动透传;4. 可选配合zipkin进行可视化展示。通过这些步骤可提升微服务架构下的问题排查与性能优化能力。
在微服务架构下,一个请求往往会经过多个服务的协作处理。要排查问题、优化性能,链路追踪就成了必不可少的能力。Spring Cloud Sleuth 是 Spring 提供的一套轻量级分布式链路追踪方案,它可以自动为每个请求生成唯一标识,并记录调用链中的各个阶段。下面我们就来看看如何一步步实现它。
要在项目中使用 Sleuth,首先得引入相关依赖。如果你使用的是 Spring Boot 2.6 或更高版本,可以直接添加如下依赖:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
添加完成后,Sleuth 就会自动生效了。你不需要额外写任何代码,它会在日志中输出 traceId 和 spanId,帮助你识别每一次请求的完整链路。
注意:Sleuth 默认不会把数据上报到外部系统,只负责生成和传递链路信息。如果想做可视化展示,还需要配合 Zipkin 等工具。
Sleuth 的核心功能之一就是在每次请求开始时生成一个唯一的 traceId,并在每个操作单元(比如一次 HTTP 请求或方法调用)中生成一个 spanId。这些信息会自动打印在你的日志里。
比如你在控制台看到这样的日志:
[order-service,8e95b7a4d0f5c3a0,8e95b7a4d0f5c3a0,true] ...
这里的字段含义分别是:
这样你就可以通过日志来追踪整个调用链了。如果你使用 ELK 或者类似的日志分析系统,可以基于 traceId 把所有相关日志聚合在一起。
Sleuth 的一大优势是能自动将链路信息透传到下游服务。也就是说,当你从 A 服务调用 B 服务时,Sleuth 会自动把当前的 traceId 和 spanId 放到 HTTP 请求头中,B 服务接收到后就能继续沿用这条链路。
目前支持自动注入的场景包括:
如果你自己封装了远程调用逻辑,就需要手动设置请求头,例如:
HttpHeaders headers = new HttpHeaders(); sleuthTracer.getCurrentSpan().context().forEach((key, value) -> headers.set(key, value));
这样才能保证链路不中断。
虽然 Sleuth 能提供完整的链路数据,但直接看日志还是不够直观。你可以把它和 Zipkin 结合起来,实现图形化展示。
步骤大致如下:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-sleuth-zipkin</artifactId> </dependency>
spring: zipkin: base-url: http://localhost:9411
这样,Sleuth 会自动将 span 数据发送给 Zipkin,你就可以通过 Zipkin 的 Web 页面查看请求的完整调用路径、耗时分布等信息。
基本上就这些。Spring Cloud Sleuth 的使用并不复杂,但确实能大大提升微服务下的可观测性。只要注意日志收集方式和上下游服务之间的上下文传递,就能轻松实现全链路追踪。
以上就是Spring Cloud Sleuth实现分布式链路追踪详细教程的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号