Sleuth是Spring cloud的分布式跟踪解决方案。
-
span(跨度)，基本工作单元。一次链路调用，创建一个span，
span用一个64位id唯一标识。包括：id，描述，时间戳事件，spanId,span父id。
span被启动和停止时，记录了时间信息，初始化span叫：root span，它的span id和trace id相等。
-
trace(跟踪)，一组共享“root span”的span组成的树状结构 称为 trace，trace也有一个64位ID，trace中所有span共享一个trace id。类似于一颗 span 树。
-
annotation（标签），annotation用来记录事件的存在，其中，核心annotation用来定义请求的开始和结束。
- CS(Client Send客户端发起请求)。客户端发起请求描述了span开始。
- SR(Server Received服务端接到请求)。服务端获得请求并准备处理它。SR-CS=网络延迟。
- SS（Server Send服务器端处理完成，并将结果发送给客户端）。表示服务器完成请求处理，响应客户端时。SS-SR=服务器处理请求的时间。
- CR（Client Received 客户端接受服务端信息）。span结束的标识。客户端接收到服务器的响应。CR-CS=客户端发出请求到服务器响应的总时间。
其实数据结构是一颗树，从root span 开始。
使用
Sleuth单独
-
pom
每个需要监控的系统
<!-- 引入sleuth依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
测试点：
- 启动eureka 7900，service-sms 8002，api-driver 9002.
- 访问一次。看日志结果。
[api-driver,1a409c98e7a3cdbf,1a409c98e7a3cdbf,true]
[服务名称，traceId（一条请求调用链中 唯一ID），spanID（基本的工作单元，获取数据等），是否让zipkin收集和展示此信息]
看下游
[service-sms,1a409c98e7a3cdbf,b3d93470b5cf8434,true]
traceId， 是一样的。
服务名必须得写。zipkin
上面拍错看日志，很原始。刀耕火种，加入利器 zipkin。
zipkin是twitter开源的分布式跟踪系统。
原理收集系统的时序数据，从而追踪微服务架构中系统延时等问题。还有一个友好的界面。
由4个部分组成：
Collector、Storage、Restful API、Web UI组成
采集器，存储器，接口，UI。
原理：
sleuth收集跟踪信息通过http请求发送给zipkin server，zipkin将跟踪信息存储，以及提供RESTful API接口，zipkin ui通过调用api进行数据展示。
默认内存存储，可以用mysql，ES等存储。
操作步骤：
- 每个需要监听的服务的pom中添加。
<!-- zipkin -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
- 每个需要监听的服务yml中
spring: #zipkin zipkin: base-url: http://localhost:9411/ #采样比例1 sleuth: sampler: rate: 1
- 启动zipkin。
jar包下载：curl -sSL https://zipkin.io/quickstart.sh | bash -s
我放到了 目录：C:\github\online-taxi-demo 下面。
java -jar zipkin.jar
或者docker：
docker run -d -p 9411:9411 openzipkin/zipkin