Spirng Cloud Sleuth 为微服务架构增加分布式服务跟踪能力。
在引入 Sleuth 之前,我们先按照之前章节学习的内容来做一些准备工作,构建一些基础的设施和应用。
服务注册中心:eureka-server
微服务应用:trace-1,实现一个 REST 接口/trace-1,调用该接口将触发对trace-2应用的调用。具体实现如下所述。
org.springframework.boot
spring-boot-starter-web
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
org.springframework.cloud
spring-cloud-starter-netflix-ribbon
org.springframework.cloud
spring-cloud-starter-sleuth
org.springframework.boot
spring-boot-starter-test
test
org.springframework.cloud
spring-cloud-dependencies
${spring-cloud.version}
pom
import
@RestController
@EnableDiscoveryClient
@SpringBootApplication
public class Trace1Application {
private final Logger logger = Logger.getLogger(getClass());
@Bean
@LoadBalanced
RestTemplate restTemplate(){
return new RestTemplate();
}
@RequestMapping(value = "/trace-1",method = RequestMethod.GET)
public String trace(){
logger.info("===call trace-1===");
return restTemplate().getForEntity("http://trace-2/trace-2",String.class).getBody();
}
public static void main(String[] args) {
SpringApplication.run(Trace1Application.class, args);
}
}
@RestController
@EnableDiscoveryClient
@SpringBootApplication
public class Trace2Application {
private final Logger logger = Logger.getLogger(getClass());
@RequestMapping(value = "/trace-2",method = RequestMethod.GET)
public String trace(){
logger.info("===call trace-2===");
return "Trace";
}
public static void main(String[] args) {
SpringApplication.run(Trace2Application.class, args);
}
}
在完成了以上的准备工作以后,我们现在为上面的trace-1 和 trace-2 添加服务跟踪功能。 在trace-1 和 trace-2 的pom中增加 spring-cloud-starter-sleuth
org.springframework.cloud
spring-cloud-starter-sleuth
启动 trace-1、 trace-2 及 注册中心,发送请求:http://localhost:9101/trace-1 ,可在控制台上看到
[trace-2,19b2514d0d448a55,008d2ee22da9b5c8,false] 22524 --- [nio-9102-exec-3] com.gildata.trace2 : ===call trace-2===
从上面的控制台输出内容中,我们看到多了一些日志信息。 每个值的含义如下所述 :
上面四个值中的 Trace ID 和 Span ID 是 Spring Cloud Sleuth 实现分布式服务跟踪的核心。在一次服务请求链路的调用过程中,会保持并传递同一个 Trace ID, 从而将整个分布于不同微服务进程中的请求跟踪信息串联起来。 Trace-1 和 trace-2 同属于一个前端服务请求来源,所以他们的 Trace ID 是相同的,处于同一条请求链路中.
Logstash 是ELK 平台的一个开源工具,可以对日志进行收集、过滤、并将其存储供以后使用。
Spring Cloud Sleuth 在于 ELK 平台整合使用时,实际上只要实现与负责日志收集的Logstash 完成数据对接即可。所以我们需要为Logstash准备JSON格式的日志输出。由于 Spring Boot 应用默认使用logback 来记录日志,而Logstash 自身也有对logback日志工具的支持工具,所以我们可以直接通过在logback的配置中增加对 Logstash 的 Appender,就能方便地将日志转换成以 JSON 的格式存储和输出了。
下面我们来详细介绍一下 在快速入门的基础上,如何实现面向Logstash的日志输出配置。
net.logstash.logback
logstash-logback-encoder
4.6
很多时候我们追溯请求链路的一个原因是为了找出整个调用链路中出现延迟过高的瓶颈源,或为了实现对分布式系统做延迟监控等与时间消耗相关的需求,这时候 ELK 这样的日志分析系统就显得有些乏力了。
Zipkin 是 Twitter 的一个开源项目。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的 REST API 接口来辅助查询跟踪数据以实现对分布式系统的监控程序。 除了 面向开发的API接口之外,它还提供了方便的 UI组件来帮助我们直观搜索跟踪信息和分析请求链路明细。
下图展示了 Zipkin 的基础架构,它主要由 4 个核心组件构成。
我们来详细介绍下 Sleuth 与 Zipkin 的基础整合过程,主要分为以下两步:
第一步,搭建 Zipkin Server
org.springframework.boot
spring-boot-starter-web
io.zipkin.java
zipkin-server
2.12.1
io.zipkin.java
zipkin-autoconfigure-ui
2.12.1
org.springframework.boot
spring-boot-starter-test
test
@EnableZipkinServer
@SpringBootApplication
public class ZipkinServerApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinServerApplication.class, args);
}
}
spring.application.name=zipkin-server
server.port=9411
第二步:为应用引入和配置 Zipkin 服务。
org.springframework.cloud
spring-cloud-sleuth-zipkin
2.1.0.RELEASE
我们将 eureka-server、trace-1、trace-2 启动起来。
我们向 trace-1 的接口发送几个请求 http://localhost:9101/trace-1.
查看 Zipkin Server 的管理页面
测试成功。