（七）日志采集工具sleuth--分布式链路跟踪（zipkin）

 

 

微服务架构上经过业务来划分服务的，经过REST调用，对外暴露的一个接口，可能须要不少个服务协同才能完成这个接口功能，若是链路上任何一个服务出现问题或者网络超时，都会造成致使接口调用失败。随着业务的不断扩张，服务之间互相调用会愈来愈复杂，在项目中引入sleuth能够方便程序进行调试。

Spring Cloud Sleuth为服务之间调用提供链路追踪。经过Sleuth能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长。从而让咱们能够很方便的理清各微服务间的调用关系。此外Sleuth能够帮助咱们：

• 耗时分析: 经过Sleuth能够很方便的了解到每一个采样请求的耗时，从而分析出哪些服务调用比较耗时;
• 可视化错误: 对于程序未捕捉的异常，能够经过集成Zipkin服务界面上看到;
• 链路优化: 对于调用比较频繁的服务，能够针对这些服务实施一些优化措施。

改造前面的feign、service（服务）

pom增长：

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

feign增长日志：

@Autowired
    private IFeignService feignService; private static Logger log = LoggerFactory.getLogger(FeignController.class); @RequestMapping("/index") public String index(){ log.info("feign info"); return feignService.index();　　　　// @FeignClient(value = "service-hello")

}

 

service增长日志：

private static Logger log = LoggerFactory.getLogger(HelloController.class);

@RequestMapping("/index")
public String index() {
    log.info("service info");
    System.err.println("服务提供者client:" + name + "服务端口：" + port);
    return "服务提供者client:" + name + "服务端口：" + port;
}

启动测试，打开eureka、feign、service

打开页面，正常

显示的日志以下：

2018-12-29 16:24:26.048  INFO [service-feign,1d270312e94cab85,1d270312e94cab85,false] 10692 --- [nio-8886-exec-8] c.e.fegin.controller.FeignController     : feign info

2018-12-29 16:24:26.056  INFO [service-hello,1d270312e94cab85,5e23c30b75ee6755,false] 6560 --- [nio-8883-exec-5] c.e.e.controller.HelloController         : service info

日志中相似   [appname,traceId,spanId,exportable]，也就是Sleuth的跟踪数据。其中：

• appname: 为微服务的服务名称;
• traceId\spanId: 为Sleuth链路追踪的两个术语，后面咱们再仔细介绍;
• exportable 是不是发送给Zipkin

 

整合Zipkin服务

Zipkin是一个致力于收集分布式服务的时间数据的分布式跟踪系统。其主要涉及如下四个组件：

• collector: 数据采集;
• storage: 数据存储;
• search: 数据查询;
• UI: 数据展现.

Zipkin提供了可插拔数据存储方式：In-Memory、MySql、Cassandra以及Elasticsearch。接下来的测试为方便直接采用In-Memory方式进行存储，我的推荐Elasticsearch，特别是后续当咱们须要整合ELK时。

 

构建zipkin项目

用的springboot2，因此构建zipkin没有找到适合的方法（@EnableZipkinServer....失效），因此直接在官网https://zipkin.io/下载了jar包运行：

打开http://localhost:9411

 

修改feign、service：

<!--sleuth跟踪-->
<!--<dependency>-->
    <!--<groupId>org.springframework.cloud</groupId>-->
    <!--<artifactId>spring-cloud-starter-sleuth</artifactId>-->
<!--</dependency>-->
<!-- Zipkin 已包含spring-cloud-starter-sleuth -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

　properties配置：

spring.zipkin.base-url=http://localhost:9411

 spring.sleuth.sampler.percentage=1.0 # 默认

　　

 

咱们在浏览器中访问几回服务http://localhost:8886/index，而后转到Zipkin服务器

 该界面对本次请求进行了更详细的展示。一样咱们还能够再点击，以查看更为详细的数据，能够看到以下界面

 

 

在Zipkin界面中咱们还能够查看各服务之间的依赖关系

 

错误信息

Zipkin能够在跟踪记录中显示错误信息。当异常抛出而且没有捕获，Zipkin就会自动的换个颜色显示。在跟踪记录的清单中，当看到红色的记录时，就表示有异常抛出了。

关掉service-hello

 

点击进去以获取更详细的错误信息。

采样率

在生成环境中，因为业务量比较大，所产生的跟踪数据可能会很是大，若是所有采集一是对业务有必定影响，二是对存储压力也会比较大，因此采样变的很重要。通常来讲，咱们也不须要把每个发生的动做都进行记录。

Spring Cloud Sleuth有一个Sampler策略，能够经过这个实现类来控制采样算法。采样器不会阻碍span相关id的产生，可是会对导出以及附加事件标签的相关操做形成影响。 Sleuth默认采样算法的实现是Reservoir sampling，具体的实现类是PercentageBasedSampler，默认的采样比例为: 0.1(即10%)。

咱们能够经过spring.sleuth.sampler.percentage来设置，所设置的值介于0.0到1.0之间，1.0则表示所有采集。

也能够经过实现bean的方式来设置采样为所有采样(AlwaysSampler)或者不采样(NeverSampler)

 

 

连接：https://www.jianshu.com/p/c3d191663279 來源：简书