Spring cloud系列十四 分布式链路监控Spring Cloud Sleuth

1. 概述

Spring Cloud Sleuth实现对Spring cloud 分布式链路监控
本文介绍了和Sleuth相关的内容,主要内容如下:

  • Spring Cloud Sleuth中的重要术语和意义:Span、Trance、Annotation
  • Zipkin中图形化展示分布式链接监控数据并说明字段意义
  • Spring Cloud集成Sleuth + Zipkin 的代码demo: Sleuth集成Zipkin, Zipkin数据持久化等

2. 术语

Span
Span是基本的工作单元。Span包括一个64位的唯一ID,一个64位trace码,描述信息,时间戳事件,key-value 注解(tags),span处理者的ID(通常为IP)。
最开始的初始Span称为根span,此span中span id和 trace id值相同。

Trance
包含一系列的span,它们组成了一个树型结构

Annotation
用于及时记录存在的事件。常用的Annotation如下

  • cs - Client Sent:客户端发送一个请求,表示span的开始
  • sr - Server Received:服务端接收请求并开始处理它。(sr-cs)等于网络的延迟
  • ss - Server Sent:服务端处理请求完成,开始返回结束给服务端。(ss-sr)表示服务端处理请求的时间
  • cr - Client Received:客户端完成接受返回结果,此时span结束。(cr-sr)表示客户端接收服务端数据的时间

如果一个服务的调用关系如下:
这里写图片描述

那么此时将Span和Trace在一个系统中使用Zipkin注解的过程图形化:
这里写图片描述

每个颜色的表明一个span(总计7个spans,从A到G),每个span有类似的信息

Trace Id = X
Span Id = D
Client Sent

此span表示span的Trance Id是X,Span Id是D,同时它发送一个Client Sent事件

spans 的parent/child关系图形化如下:
这里写图片描述

3. 在Zipkin中图形化展示分布式链接监控数据

3.1 spans在zipkin界面的信息解读

在Zipkin中展示了上图的跟踪信息,红框里是对上图调用span的跟踪
这里写图片描述

但是你点击这个trace时,我们只看到4个span
这里写图片描述

为什么两个界面显示的span数量不同,一个是7,一个4.

  • 1 个 spans:来自servier1的接口http:/start 被调用,分别是Server Received (SR) 和 Server Sent (SS) annotations.
  • 2 个 spans:来自 service1 调用service2 的 http:/foo 接口。service1 端有两个span,分别为 Client Sent (CS) 和 Client Received (CR) annotations。service2 端也有两个span,分别为Server Received (SR) 和Server Sent (SS) 。物理上他有2个span,但是从逻辑上说这个他们组成一个RPC调用的span。
  • 2个span:来自 service2 调用 service3 的 http:/bar 接口,service2 端有两个span,分别为Client Sent (CS) 和 Client Received (CR) annotations。service3 端也有两个span,分别为Server Received (SR) 和Server Sent (SS) 。物理上他有2个span,但是从逻辑上说它们都是同一个RPC调用的span。
  • 2个span:来自 service2 调用 service4 的 http:/bar 接口,service2 端有两个span,分别为Client Sent (CS) 和 Client Received (CR) annotations。service4 端也有两个span,分别为Server Received (SR) and Server Sent (SS) 。物理上他有2个span,但是从逻辑上说这个它们都是同一个RPC调用的span。

所以我们计算物理spans有7个:

  • 1个来自 http:/start 被请求
  • 2个来自 service1调用service2
  • 2个来自 service2调用service3
  • 2个来自 service2调用service4.

从逻辑上说,我们只看到4个span:

  • 1个来自 service1 的接口http:/start 被请求
  • 3个来自 服务之前的RCP接口调用

3.2. Zipkin可视化错误

如果调用链路中发生接口调用失败,zipkin会默认使用红色展示信息,如下图:
这里写图片描述
点击红色的span,可以看到详细的失败信息:
这里写图片描述

4. Spring Cloud集成Sleuth + Zipkin

本节演示在Spring Cloud中集成Sleuth并将链路监控数据传送到Zipkin,使用Zipkin展示数据,并配置mysql进行数据持久化

4.1. 相关工程

cloud-registration-center
注册中心

cloud-service-zipkin
提供测试服务接口,对外提供有两个接口:
- 调用成功后,马上返回一个结果: http://127.0.0.1:17602//zipkin/simple
- 调用成功后,服务sleep 5s后再返回: http://127.0.0.1:17602//zipkin/sleep

cloud-consumer-zipkin
消费服务
此服务会通过Feign调用cloud-service-zipkin里提供的两个接口(/zipkin/sleep和/zipkin/simple),我们访问如下URL会调用的对应的接口:
http://127.0.0.1:17603//zipkin/simple
http://127.0.0.1:17603//zipkin/sleep

以上3个服务的代码比较简单,这里代码略,可以自己看github里的代码。下文中只列出和Sleuth和Zipkin相关的配置。

cloud-dashboard-zipkin
配置Zipkin服务,提供可视化链路监控
Zipkin首页:http://127.0.0.1:17601/zipkin/

4.2. 在工程中使用sleuth+zipkin+http配置

在cloud-service-zipkin和cloud-consumer-zipkin中启动sleuth,sleuth会收集spans信息,并使用http异步地将spans 信息发送到Zipkin,然后Zipkin展示信息

cloud-service-zipkin和cloud-consumer-zipkin配置Sleuth+Zipkin
2个工程中为了集成Sleuth和Zipkin,需要在普通工程基础上增加如下配置:

  • pom.xml增加sleuth和zipkin相关的jar

    org.springframework.cloud spring-cloud-starter-sleuth org.springframework.cloud spring-cloud-starter-zipkin
  • application-zipkin.yml
    Zipkin+Sleuth配置参数:

    • spring.zipkin.baseUrl:指定cloud-dashboard-zipkin的服务地址,本例子中使用真实的IP。在新的版本spring-cloud-sleuth-core-1.3.0.RELEASE中,可以实现通过服务名称进行访问
    • spring.sleuth.sampler.percentage:设置采样率,为了测试设置100%采集

    spring:
    zipkin:
    enabled: true
    # zipkkin dashboard的地址:通过真实IP地址访问
    baseUrl: http://localhost:17601/
    # 通过cloud-dashboard-zipkin注册到注册中心的服务名称访问,本版本(spring-cloud-sleuth-core-1.2.5.RELEASE)不支持,需要从spring-cloud-sleuth-core-1.3.0.RELEASE开始支持这个功能
    # 配置如下:
    # baseUrl: http://cloud-dashboard-zipkin/
    sleuth:
    sampler:
    # 默认值为0.1f,现在为了测试设置100%采集
    percentage: 1

cloud-dashboard-zipkin
配置zipkin服务

  • pom.xml

    org.springframework.cloud spring-cloud-starter-zipkin io.zipkin.java zipkin-autoconfigure-ui io.zipkin.java zipkin-server
  • 配置参数
    bootstrap-zipkin-http.yml

    port

    server:
    port: 17601

    spring:
    application:
    # 本服务注册到注册到服务器的名称, 这个名称就是后面调用服务时的服务标识符
    name: cloud-dashboard-zipkin
    eureka:
    client:
    serviceUrl:
    # 服务器注册/获取服务器的zone
    defaultZone: http://127.0.0.1:10761/eureka/
    # defaultZone: http://192.168.21.3:10761/eureka/,http://192.168.21.4:10761/eureka/
    instance:
    prefer-ip-address: true

  • application-zipkin-http.yml
    关闭本工程的推送到zipkin服务的功能

    spring:
    zipkin:
    enabled: false

启动类
@EnableZipkinServer:注解此类为Zipkin服务

@EnableEurekaClient // 配置本应用将使用服务注册和服务发现
@SpringBootApplication
@EnableZipkinServer // 启动Zipkin服务
public class ZipkinDashboardCloudApplication {

    public static void main(String[] args) {
        args = new String[1];
        args[0] = "--spring.profiles.active=zipkin-http";
        SpringApplication.run(ZipkinDashboardCloudApplication.class, args);
    }

4.3. 测试

启动zipkin服务,提供可视化链路监控
Zipkin访问地址: http://127.0.0.1:17601/zipkin/

我们演示链路跟踪,访问以下两个请求:
http://127.0.0.1:17603/zipkin/simple :正常方法
http://127.0.0.1:17603/zipkin/sleep :访问超时

进入zipkin,访问成功为蓝色,失败为红部。同时显示各个服务花费的时间
这里写图片描述

点击蓝色记录,进入详细界面
可知整个接口花费约19ms,cloud-zipkin-service的业务执行15ms,cloud-zipkin-consumer访问cloud-zipkin-service的 网络延迟为2ms,返回结果给cloud-zipkin-service的网络延迟是4s
这里写图片描述

点击cloud-zipkin-service得到更精确的数据

这里写图片描述

4.4. Zipkin数据持久化

默认情况,zipkin存储记录到内存,如果服务重启,则所有记录丢失。为了保证持久性,zipkin支持Mysql、Elasticsearch、Cassandra存储。我们演示为zipkin配置MYSQL数据库,其它两种配置类似,本文略
pom.xml为cloud-dashboard-zipkin引入新jar

 <!-- zipkin 存储到数据库需要引入此类 -->
<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-storage-mysql</artifactId>
</dependency>

<!--保存到数据库需要如下依赖-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>6.0.6</version>
</dependency>

配置参数
application-zipkin-http.yml:
配置启动时会根据classpath:/mysql.sql初始化数据库

spring:
  zipkin:
    enabled: false
  # 配置mysql
  datasource:
    schema: classpath:/mysql.sql
    # url: jdbc:mysql://127.0.0.1/test
    url: jdbc:mysql://127.0.0.1:3306/test?zeroDateTimeBehavior=convertToNull&serverTimezone=GMT%2b8
    username: root
    password: root
# Switch this on to create the schema on startup:
    initialize: true
    continueOnError: true
  sleuth:
    enabled: false
zipkin:
  storage:
    type: mysql

重启服务,服务成功后,查看数据库,自动生成数据库
这里写图片描述

如此数据库配置完毕,所有的spans信息存储到数据库中,重启服务,也不会丢失记录

4.5 在工程中使用sleuth+zipkin+ Spring Cloud Stream配置

本版本(spring-cloud-sleuth-core-1.2.5.RELEASE)支持集成spring-cloud-sleuth-stream,但是在新版本从spring-cloud-sleuth-core-1.3.0.RELEASE开始不支持spring-cloud-sleuth-stream。推荐直接使用通过集成RabbitMQ 或 Kafka。关于集成RabbitMQ 或 Kafka,关键是引入spring-rabbit 或 spring-kafka依赖包。默认的目的名称为zipkin.
对于这个的使用demo。这里暂时略

5. 代码

以上的详细的代码见下面
github代码,请尽量使用tag v0.11,不要使用master,因为我不能保证master代码一直不变

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Spring Cloud Sleuth是一个分布式跟踪解决方案,它可以帮助开发人员在微服务架构中追踪请求的流程和调用链。它通过为每个请求生成唯一的跟踪ID和跨服务的调用ID来实现这一目标。这些ID可以用于跟踪请求的流程和调用链,从而帮助开发人员快速诊断和解决问题。Spring Cloud Sleuth还提供了一些可视化工具,如Zipkin,可以帮助开发人员更好地理解和分析跟踪数据。 ### 回答2: SpringCloud Sleuth是一个基于日志的分布式跟踪方案,它可以用于解决微服务架构下的分布式系统的链追踪问题。在分布式系统中,一个请求经常会穿越多个服务,从而会形成一条复杂的链,如果有一台或多台机器对此进行记录,那么将能够轻松地查看和理解一个请求的完整径。这些信息能够帮助我们更快地定位问题所在,提高系统可靠性和稳定性。 Sleuth使用了Zipkin的架构和数据模型,通过在每个请求的Header中添加Trace Id和Span Id来实现链追踪。Trace Id表示整个请求链,Span Id表示每一个服务的一个简单步骤。使用这两个 Id,我们就可以将整个链追踪下来,使得对请求的监测、记录和分析变得更加容易。 Sleuth结合了Spring Cloud日志管理和Zipkin的功能,能够自动收集各个微服务的请求跟踪信息,并将其发送到Zipkin服务器进行聚合分析,视图展现。通过Sleuth的ChainInvoker,可以实现对所有链的统一管理。当一条请求跨越多个服务时,Sleuth会为每个服务实例生成唯一的spanId,并将这个spanId沿用到下一个服务实例,从而使得整条链保留了完整的信息。此外,Sleuth还支持基于日志的采样策略和数据比较高效的存储,保证了高性能的分布式追踪。 Sleuth的主要应用场景是微服务架构下的链跟踪和性能监控。微服务架构中有大量的服务,服务之间的关系错综复杂,因此链追踪对于排查问题、优化性能非常重要。Sleuth能够方便地实现链追踪和监测,并帮助我们快速定位问题所在,提高系统的可靠性和稳定性。 ### 回答3: Spring Cloud Sleuth追踪是 Spring Cloud 微服务架构中的一项重要的功能模块。通过 Sleuth追踪,我们可以跟踪整个分布式系统中的请求链,从而了解每个操作所花费的时间、调用的服务以及调用顺序。在微服务架构中,服务调用会涉及到多个服务之间的协作,使用 Sleuth追踪可以帮助我们很好地理解系统在内部的调用过程。 Sleuth追踪的原理是在每个服务的请求中添加唯一的追踪 ID,通过这个追踪 ID,Sleuth 可以实现将每个请求相关的服务调用串联起来,形成完整的请求链。追踪 ID 通常被称为 Trace ID,它作为请求的一部分,从前端发起请求的服务开始一直传递到最后一个服务。 通过 Sleuth追踪,我们可以了解每个调用的服务名和 IP 地址,以及请求的耗时情况,在调试分布式系统时非常实用。此外,Sleuth 还支持将链追踪信息集成到日志系统中,从而更好地协助开发人员进行故障排查。 Sleuth追踪还提供了 Zipkin 集成,Zipkin 是一个开源的分布式追踪系统,可以将链数据可视化显示,并提供了一些分析工具,帮助开发人员更好地理解系统的调用情况。 总之,Spring Cloud Sleuth追踪是一个非常实用的工具,可以帮助我们更好地理解分布式系统中服务调用的情况,有效地解决微服务架构中的复杂度和故障排查的问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值