传送门：SpringCloud版本Hoxton SR5 --- 第一讲：认识 先看Sleuth、Zipkin、Elasticsearch 可以完成的功能，或者说他在项目中的定位和作用。
Sleuth比较正式的一些功能描述：（上面那篇文章也有举例说明）
spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案，它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的设计，先来了解一下 Sleuth的术语， Sleuth借用了 Dapper的术语。
span（跨度）：基本工作单元。 span用一个64位的id唯一标识。除ID外，span还包含其他数据，例如描述、时间戳事件、键值对的注解（标签）， spanID、span父 ID等。 span被启动和停止时，记录了时间信息。初始化 span被称为"rootspan"，该 span的 id和 trace的 ID相等。
trace（跟踪）：一组共享"rootspan"的 span组成的树状结构称为 traceo trac也用一个64位的 ID唯一标识， trace中的所有 span都共享该 trace的 ID
annotation（标注）： annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。
CS（ Client sent客户端发送）：客户端发起一个请求，该 annotation描述了span的开 始。
SR（ server Received服务器端接收）：服务器端获得请求并准备处理它。如果用 SR减去 CS时间戳，就能得到网络延迟。c)
SS（ server sent服务器端发送）：该 annotation表明完成请求处理（当响应发回客户端时）。如果用 SS减去 SR时间戳，就能得到服务器端处理请求所需的时间。
CR（ Client Received客户端接收）： span结束的标识。客户端成功接收到服务器端的响应。如果 CR减去 CS时间戳，就能得到从客户端发送请求到服务器响应的所需的时间
上面的这些功能，不是很理解，暂时就不说了。
最上面的那个链接其实已经说了Sleuth 和 Zipkin分别完成的功能，这里就再详细的提一嘴：
都知道，当我们再单体项目中一台服务器跑遍整个项目，日志这一块可以直接查看。但是微服务架构不行，因为相同功能的项目，可能会部署到10台服务器上，然后调用的时候，通过Ribbon负载均衡决定到底调用哪一台服务器完成调用功能。这时候如果要看日志，通常情况下，是不是A服务调B服务，但是B服务有10台服务器，你怎么知道调用的是哪台服务器？日志也可以看，但是微服务更多呢？频繁的切换服务器查看日志，你不吐，我都要看吐。
所以这时候出现一个技术：Spring Cloud Sleuth(链路跟踪)，他有一个Trace Id，当第一个调用传入服务器的时候，他就给这个调用设置一个Trace ID，然后当这个调用继续访问其他服务器的时候，Sleuth就让这个Trace ID跟着这个调用接口传递下去，这样就能清晰的获取到每一个请求经过了哪些服务器，调用了哪些接口。
还没完，还有一个Span ID，当所有的微服务都整合了SpringCloud Sleuth之后，一个请求过来，调用到的每个服务器接口的时候都会生成一个Span ID,如果每个Span ID的生成时间相减，是不是就可以获取调用过程的时间 ？程序员就可以通过展示的时间，来判断某个接口是不是需要优化。
所以：Sleuth的作用主要就是标记请求的调用链、获取每个请求调用开始时间。
上面我们知道了每个请求的调用经过的服务器和调用的接口，还有每个调用开始的时间，但是上面仅仅是采集数据。当我们采集到数据之后，我们还需要将这些数据通过Zipkin的客户端发送给Zipkin服务端。而Zipkiin服务端拿到数据之后，就通过Trace ID开始整合，将Trace ID相同的数据整合到一起，并根据Span ID创建的时间，计算出每个服务、组件之间调用的时间，然后通过Zipkiin提供的UI界面，提供查询功能，显示出来。你以为就大功告成了 ？还没有。
作为程序员都知道，健壮性、高可用是必不可少的。Zipkin虽然整合了数据，并提供了UI界面，但是所有数据都是保存在内存中的。他没有持久化到硬盘。所以当Zipkin重启之后，所有数据都会立即清空。所以需要将这些日志信息保存到硬盘中，这时候使用官方提供的Elasticsearch持久化日志信息。（Zipkiin整合Elasticsearch很简单，将Elasticsearch的连接地址交给Zipkini，然后启动Zipkin就好了）
到这里，几乎可以说，大功告成了，但是实际开发中，通常会用到rabbitmq、kafka这种通讯工具。所以需要打印使用mq的日志，就需要Zipkin整合mq（Zipkin自己提供了整合，但是mq的连接地址、用户名、密码，你需要交给Zipkin）
现在就正式开始：
客户端：
每一个调用的需要打印日志的微服务都需要做如下操作：
添加依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
每一个调用的需要打印日志的微服务都需要在配置文件添加如下配置：
spring:
##################################################### zipkin ########################################################
zipkin:
base-url: http://47.**.1**.61:9411/ #指定Zipkin server地址
############################################### Spring cloud sleuth #################################################
sleuth:
sampler:
probability: 1.0 #request采样的数量 默认是0.1 也即是10% 顾名思义 采取10%的请求数据 因为在分布式系统中，数据量可能会非常大，因此采样非常重要。这里暂时设置为全部采集。
好了没有，就这么简单。
服务端：Zipkin的服务端，官网建议直接使用它提供的jar包，或者他提供的docker镜像进行部署。
我是使用的Docker'镜像，下面的链接直接跳转Docker运行Zipkin的服务端：
Zipkin服务端部署及整合RabbitMq传送门：Docker运行Zipkin-Server、整合rabbitmq
为了将日志信息持久化，提供下面的链接：
Zipkin整合Elasticsearch传送门：docker之Elasticsearch镜像安装及运行、整合Zipkin
到这里Spring Cloud Sleuth 的使用，就完成了。