一、背景
随着微服务的数量增长，一个业务接口涉及到多个微服务的交互，在出错的情况下怎么能够快速的定位错误
二、简介
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
三、入门
1.准备2个服务
trace-1和trace-2，并且在trace-1中调用trace-2（可以通过resttemplate或fegin方式去调用），并通过日志log进行输出信息
2.实现跟踪
只需要在trace-1和trace-2的pom.xml依赖管理中增加spring-cloud-starter-sleuth依赖即可，具体如下：
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
在方法中记录日志我们会发现在日志的最前面对了一部分内容，这部分内容就是Sleuth为什么提供的链路信息
-- trace-1 INFO [trace-1,f410ab57afd5c145,a9f2118fa2019684,false] 25028 --- [nio-9101-exec-1] ication$$EnhancerBySpringCGLIB$$d8228493 : ===<call trace-1>=== -- trace-2 INFO [trace-2,f410ab57afd5c145,e9a377dc2268bc29,false] 23112 --- [nio-9102-exec-1] ication$$EnhancerBySpringCGLIB$$e6cb4078 : ===<call trace-2>===
关键字：[appname,traceId,spanId,exportable]， 具体含义如下：
- appname：服务的名称，也就是spring.application.name的值，这边要注意下，如果需要输出正确的服务名称，需要将spring.application.name的配置写在bootstrap.properties中
- traceId：整个请求的唯一ID，它标识整个整个请求的链路
- spanId：基本的工作单元，发起一起远程调用就是一个span
- exportable：是否导入数据到Zipkin中
分析：[trace-1,f410ab57afd5c145,a9f2118fa2019684,false]
- 第一个值：
trace-1，它记录了应用的名称，也就是application.properties中spring.application.name参数配置的属性。 - 第二个值：
f410ab57afd5c145，Spring Cloud Sleuth生成的一个ID，称为Trace ID，它用来标识一条请求链路。一条请求链路中包含一个Trace ID，多个Span ID。 - 第三个值：
a9f2118fa2019684，Spring Cloud Sleuth生成的另外一个ID，称为Span ID，它表示一个基本的工作单元，比如：发送一个HTTP请求。 - 第四个值：
false，表示是否要将该信息输出到Zipkin等服务中来收集和展示。
上面四个值中的Trace ID和Span ID是Spring Cloud Sleuth实现分布式服务跟踪的核心。在一次服务请求链路的调用过程中，会保持并传递同一个Trace ID，从而将整个分布于不同微服务进程中的请求跟踪信息串联起来，以上面输出内容为例，trace-1和trace-2同属于一个前端服务请求来源，所以他们的Trace ID是相同的，处于同一条请求链路中。
参考：http://blog.didispace.com/spring-cloud-starter-dalston-8-1/
日志的分析系统：ELK平台（ELK平台主要有由ElasticSearch、Logstash和Kiabana三个开源免费工具组成）
分布式服务跟踪（整合logstash）：http://blog.didispace.com/spring-cloud-starter-dalston-8-3/