Sleuth+Zipkin 服务链路追踪

官方文档：https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.3.RELEASE/single/spring-cloud

-sleuth.html

一、为什么要用链路追踪

1）为了更好的定位异常

2）分析耗时操作，配合sentinel进行限流等优化

二、基本术语

Span（跨度）：基本工作单元，发送一个远程调度任务 就会产生一个 Span，Span 是一

个 64 位 ID 唯一标识的，Trace 是用另一个 64 位 ID 唯一标识的，Span 还有其他数据信

息，比如摘要、时间戳事件、Span 的 ID、以及进度 ID。

 Trace（跟踪）：一系列 Span 组成的一个树状结构。请求一个微服务系统的 API 接口，

这个 API 接口，需要调用多个微服务，调用每个微服务都会产生一个新的 Span，所有

由这个请求产生的 Span 组成了这个 Trace。

 Annotation（标注）：用来及时记录一个事件的，一些核心注解用来定义一个请求的开

始和结束 。这些注解包括以下：

 cs - Client Sent -客户端发送一个请求，这个注解描述了这个 Span 的开始

 sr - Server Received -服务端获得请求并准备开始处理它，如果将其 sr 减去 cs 时间戳

便可得到网络传输的时间。

 ss - Server Sent （服务端发送响应）–该注解表明请求处理的完成(当请求返回客户

端)，如果 ss 的时间戳减去 sr 时间戳，就可以得到服务器请求的时间。

 cr - Client Received （客户端接收响应）-此时 Span 的结束，如果 cr 的时间戳减去

cs 时间戳便可以得到整个请求所消耗的时间。

那么用以上概念完整的表示出来如下：

Span 之间的父子关系如下：

三、Seuth+zipkin整合

整合之间zipkin 要先安装，利用docker安装

docker run -d -p 9411:9411 openzipkin/zipkin
           

http://192.168.56.10:9411/zipkin/

Seuth 时链路追踪

zipkin 是可视化工具

3.1 在gullimall-common中导入依赖

<!-- 引入链路追踪sleuth -->
        <!--        <dependency>-->
        <!--            <groupId>org.springframework.cloud</groupId>-->
        <!--            <artifactId>spring-cloud-starter-sleuth</artifactId>-->
        <!--            <version>2.1.0.RELEASE</version>-->
        <!--        </dependency>-->

        <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-zipkin -->
        <!-- spring-cloud-starter-zipkin 中包含了上面sleuth-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>
           

3.2 添加配置

为每一个微服务配置以下配置

#服务追踪
spring.zipkin.base-url=http://192.168.56.10:9411/
#关闭服务发现，否则 Spring Cloud 会把 zipkin 的 url 当做服务名称
spring.zipkin.discovery-client-enabled=false
#设置使用 http 的方式传输数据
spring.zipkin.sender.type=web
# 设置抽样采集率为 100%，默认为 0.1，即 10%
spring.sleuth.sampler.probability=1
# 开启链路最终的日志 上线后记得关闭，由于我们当前有zipkin的可视化，所以下面这两个配置建议不要开启，没什么用。
#发起一次远程调用，观察控制台
#DEBUG [user-service,541450f08573fff5,541450f08573fff5,false]
#user-service：服务名
#541450f08573fff5：是 TranceId，一条链路中，只有一个 TranceId
#541450f08573fff5：是 spanId，链路中的基本工作单元 id
#false：表示是否将数据输出到其他服务，true 则会把信息输出到其他可视化的服务上观察
logging.level.org.springframework.cloud.openfeign: debug
logging.level.org.springframework.cloud.sleuth: debug
           

3.3 测试

3.4 持久化

持久化时最好放在Elasticsearch

Zipkin 默认是将监控数据存储在内存的，如果 Zipkin 挂掉或重启的话，那么监控数据就会丢

失。所以如果想要搭建生产可用的 Zipkin，就需要实现监控数据的持久化。而想要实现数据

持久化，自然就是得将数据存储至数据库。好在 Zipkin 支持将数据存储至：

 内存（默认）

 MySQL

 Elasticsearch

 Cassandra

Zipkin 数据持久化相关的官方文档地址如下：

https://github.com/openzipkin/zipkin#storage-component

四、zipkin的数据分析

查找所有链路

首页列表信息

链路详细信息

依赖关系