Spring Cloud Sleuth 全链路日志跟踪解决方案（强烈推荐）

最新推荐文章于 2024-03-10 13:36:53 发布
最新推荐文章于 2024-03-10 13:36:53 发布
阅读量266 收藏 2
点赞数
文章标签： java 开发语言
原文链接：https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247533012&idx=1&sn=2c23c4ea98f069bb5c3265a8e4d3ddf2&chksm=ebd57ef8dca2f7eeee67bb7b6a019f091e4df712c5e7a8a72320e9d71a526cbd2aad01dcb450&scene=126&sessionid=0
版权

点击关注公众号，实用技术文章及时了解6abb4aa3f5f4f9f7fae0c728ac3dc5ac.png

  • 概述

    • 分布式系统面临的问题

    • Sleuth是什么

    • Zipkin是什么

    • 链路监控相关术语

  • 实战练习

    • 入门练习

    • Zipkin下载与启动

    • 搭建链路监控步骤

    • sleuth相关配置

    • 向Zipkin发送消息的方式

    • Sleuth到底给Zipkin都发送了哪些数据？

    • Zipkin配置持久化

  • 引入sleuth是怎么输出traceId的

  • logback日志问题

  • 除了Zipkin还有哪些链路跟踪

本篇文章所涉及到的demo练习 使用的 cloud 2021.0.3+ springboot2.6.8

一、概述

1.1. 分布式系统面临的问题

在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个次请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。

0d2d6266598b941380e67b649c5c8486.png

1.2. Sleuth是什么

官网：

  • https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/

Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。他会将服务与服务之间的调用给记录起来。可以快速的知道调用 用户服务，到底涉及到了哪些微服务，方便我们快速排查问题！

具体的功能如下几点：

  • 将跟踪和跨度 ID 添加到 Slf4J，因此您可以从日志聚合器中的给定跟踪或跨度中提取所有日志。

  • 检测来自 Spring 应用程序的公共入口和出口点（servlet filter, rest template, scheduled actions, message channels, feign client）。

  • 如果spring-cloud-sleuth-zipkin可用，则应用程序将通过 HTTP生成和报告与Zipkin兼容的跟踪。默认情况下，它将它们发送到 localhost（端口 9411）上的 Zipkin 收集器服务。使用spring.zipkin.baseUrl配置Zipkin 服务的位置。

00e807d761809cd7bb45d0de3e2efc26.png

1.3. Zipkin是什么

Spring Cloud Sleuth对于分布式链路的跟踪仅仅是生成一些数据，这些数据不便于人类阅读，所以我们一般把这种跟踪数据上传给Zipkin Server，由Zipkin通过UI页面统一进行数据的展示。

1.4. 链路监控相关术语

这些术语在官方文档当中也可以看到的！

  • span（跨度）：工作的基本单位。例如，发送 RPC 是一个新的跨度，发送响应到 RPC 也是如此。Span还有其他数据，例如描述、时间戳事件、键值注释（标签）、导致它们的 Span 的 ID 和进程 ID（通常是 IP 地址）。跨度可以启动和停止，并且它们会跟踪它们的时间信息。创建跨度后，您必须在将来的某个时间点停止它。

  • Trace：一组跨度形成树状结构。

  • Annotation/Event：用于及时记录某个事件的存在，有如下事件类型：

    • cs：客户端发送。客户已提出请求。此注释指示跨度的开始。

    • sr：Server Received：服务器端收到请求并开始处理它。cs从此时间戳中减去时间戳揭示了网络延迟。

    • ss：服务器发送。在请求处理完成时注释（当响应被发送回客户端时）。从这个时间戳中减去sr时间戳，可以看出服务器端处理请求所需的时间。

    • cr: 客户收到。表示跨度的结束。客户端已成功收到服务器端的响应。cs从这个时间戳中减去时间戳，可以看出客户端从服务器接收响应所需的全部时间。

下图显示了Span和Trace在系统中的外观： 音符的每种颜色表示一个跨度（有七个跨度 - 从A到G）。

e9edb35d85b1072e3ce5d420367b20e3.png

下图显示了 span 的父子关系的外观：

您可以继续创建跨度（带有no custom span指示的示例），也可以手动创建子跨度（带有custom span指示的示例）。

d3b2c86e654e1417d069dc3f90969b6f.png

二、实战练习

2.1. 入门练习

1.创建项目

2.引入依赖

<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <springboot.version>2.6.8</springboot.version>
    <springcloud.version>2021.0.3</springcloud.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-dependencies</artifactId>
           <version>${springboot.version}</version>
           <type>pom</type>
           <scope>import</scope>
       </dependency>
        <dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-dependencies</artifactId>
           <version>${springcloud.version}</version>
           <type>pom</type>
           <scope>import</scope>
       </dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>
</dependencies>

3.添加yml配置

server:
  port: 8989

spring:
  application:
    name: sleuth-demo

4.添加控制器

@RestController
public class ExampleController {
    private static final Logger log = LoggerFactory.getLogger(ExampleController.class);
    
    @RequestMapping("/")
    public String home() {
        log.info("Hello world!");
        return "Hello World!";
    }
}

5.测试访问：http://localhost:8989/ 访问后观察打印的日志

5243ee9facbfc6afa8f40237ba15d1c4.png

[sleuth-demo,a79df4de56426209,a79df4de56426209]此条目对应于[application name,trace id, span id]

设置DispatcherServlet日志级别过后可以看到如下日志：

logging.level.org.springframework.web.servlet.DispatcherServlet=DEBUG
af2c7710e874c9501425b447ecea8ed9.png

如果您对这一步还不是很了解他是干什么的，没关系，可以接着往下看，下面你就会明白的！学知识要循序渐进，不可急躁！！！

2.2. Zipkin下载与启动

下载最新版本2.23.18：

  • https://repo1.maven.org/maven2/io/zipkin/zipkin-server/2.23.18/zipkin-server-2.23.18-exec.jar

官网：

  • https://zipkin.io/pages/quickstart.html

Zipkin的gihub地址：

  • https://github.com/openzipkin/zipkin

下载好jar包后直接java -jar启动：

77932caedab292550a95625b5866eb5e.png

然后访问：http://localhost:9411/zipkin/

2d4c97d478d847c17cbc0279dc4221fc.png

2.3. 搭建链路监控步骤

首先我们要至少准备两个服务，并且是调用关系。这样我们才可以通过zipkin来查看调用链。

这里我会搭建两个服务，一个是8989服务，一个是8990服务，然后8989服务的一个接口当中调用了8990当中的接口！

远程调用的时候我这里使用的是openfeign，openfeign和RestTemplate都是远程调用框架，如果您对RestTemplate熟悉，用RestTemplate也是可以的。

openfeign教程：

  • https://blog.csdn.net/weixin_43888891/article/details/126171740

第一步：搭建8990提供者

1.创建项目

2.添加pom依赖

这块有一个点需要注意一下，有的springcloud版本当中是没有对spring-cloud-starter-zipkin进行版本控制的，所以这时候我们需要自己去声明版本号，2.2.8.RELEASE是截止到现在最新的版本！spring-cloud-starter-zipkin依赖是集成了spring-cloud-starter-sleuth依赖的，所以我们引用了zipkin就可以不引用sleuth了。

<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <springboot.version>2.6.8</springboot.version>
    <springcloud.version>2021.0.3</springcloud.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-dependencies</artifactId>
           <version>${springboot.version}</version>
           <type>pom</type>
           <scope>import</scope>
       </dependency>
        <dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-dependencies</artifactId>
           <version>${springcloud.version}</version>
           <type>pom</type>
           <scope>import</scope>
       </dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-zipkin</artifactId>
        <version>2.2.8.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-openfeign</artifactId>
    </dependency>
</dependencies>

3.添加yml配置

server:
  port: 8990

spring:
  application:
    name: sleuth-provide

logging:
  level:
    org.springframework.web.servlet.DispatcherServlet: DEBUG

4.添加控制器，主要是为了测试调用链路，这个接口就随便写一下就可以了！

@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/getUserList")
    public String getUserList() {
        return "user";
    }
}

5.启动后测试访问：http://localhost:8990/user/getUserList

f9bc720d45d052fbc51de029876f5ed2.png

访问两次后打开：http://localhost:9411/zipkin

43fd6f04ca194c883972651a68857df3.png
第二步：搭建8989消费者

1.创建项目

2.添加pom依赖（这块跟上面提供者的依赖一样即可，当然消费者用不到openfeign，可以选择把openfeign的依赖去掉）

3.添加yml配置

server:
  port: 8989

spring:
  application:
    name: sleuth-demo

logging:
  level:
    org.springframework.web.servlet.DispatcherServlet: DEBUG

4.使用openfeign就需要开启openfeign的注解支持，在启动类添加@EnableFeignClients

5.添加openfeign远程调用接口

@FeignClient(value = "userService", url = "http://localhost:8990")
public interface UserService {

    @GetMapping("/user/getUserList")
    String getUserList();
}

6.添加控制器

@RestController
public class ExampleController {

    private static final Logger log = LoggerFactory.getLogger(ExampleController.class);

    @Resource
    private UserService userService;

    @RequestMapping("/")
    public String home() {
        log.info("Hello world!");
        return userService.getUserList();
    }
}
第三步：测试访问

访问：http://localhost:8989/

首先我们观察两个服务的日志：会发现一个问题trace id是一致的！原因就是8989调用了8990服务，他们属于是一个链路的。记住这一切并不是zipkin帮我们实现的，而是Sleuth。

您也可以通过将zipkin的依赖改为sleuth然后执行链路，他id仍然是一样的。zipkin可以把它当做就是一个带有可视化界面的jar包，项目当中集成zipkin依赖主要是将sleuth链路跟踪的数据，上传到zipkin，由zipkin对数据进行整理并在页面上展示了出来，真正实现链路跟踪的是sleuth

a85628f002bd3ec6893a5fd8e808eb3d.png ed83427fddfcbd339c20e4a719edfb5c.png

然后我们再观察一下zipkin的日志：

ed7401c0db32c7b4adc538511f1e8dde.png
第四步：故意制造异常

在消费服务的接口上故意制造异常：

@GetMapping("/getUserList")
public String getUserList() {
    int i = 1/0;
    return "user";
}

制造完异常后重启，再进行访问http://localhost:8989/，然后观察日志：可以很直观的看到是哪些链路出现了问题。

通过这里我们可以拿到Trace ID，有了Trace ID我们可以去日志文件当中搜索Trace ID快速定位bug原因！

9e112ea88cfa1f2bcb70813709ec7bf6.png

然后我们还可以查看链路详情：通过下图可以很直观的看到是由SLEUTH-DEMO调用SLEUTH-PROVIDE服务的时候，SLEUTH-DEMO服务接口产生的异常！

c9f048cdc521c7722581585b879be5cb.png

假如不使用Sleuth，在我们进行远程调用的时候报错了，实际上我们是看不到他是因为什么报错的，我们只知道调用他报错了，日志如下，要想真正知道报的什么异常还得去查看远程调用的服务日志，而且还得比对服务调用时间，来查看当时报错的日志。

d62c28873dfae298edb96ee70dcc07dd.png

2.4. sleuth相关配置

问题： 默认情况下，它将它们发送到 localhost（端口 9411）上的 Zipkin 收集器服务，假设我们微服务并不是都部署在一台机器，那应该怎么办呢？使用spring.zipkin.baseUrl配置Zipkin 服务的位置。

spring:
  application:
    name: sleuth-demo
  zipkin:
    base-url: http://localhost:9411/ # 指定zipkin地址
  sleuth:
    sampler:
      # 采样率值介于 0 到 1 之间，1 则表示全部采集
      probability: 1
      # 每秒采集的数量，默认是10，通过设置这个可以有效的避免消息过大 
      rate: 10

关于sleuth的其他相关配置属性，可查看官网：

  • https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/appendix.html#appendix

2.5. 向Zipkin发送消息的方式

官网：

  • https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/howto.html#howto

705b9786b09eca4a9c0d1b28fe12c11f.png

这个是什么意思呢？首先我们要明白一点，zipkin当中所展示的数据实际上都是由我们服务发送给zipkin他才将数据清洗，并展示出来的。默认采用的是HTTP请求方式来进行向zipkin发送的。

在实际开发当中HTTP请求方式，有时候势必会给我们服务器带来一些压力，并发量特别大的情况下，会占用大量线程。HTTP请求讲究的是，我发送给你，然后并且收到你的消息回复，这条连接才算结束。

所以基于这一点zipkin也给我们提供了可以通过消息中间件来进行发送，发送给消息中间件我们就不用管了，这样可以避免线程拥堵，目前支持RabbitMQ和Kafka、ActiveMQ！

我这里直接使用rabbitmq来进行演示 其他同理，不懂可以看官网！

第一步：添加依赖

<dependency>
    <groupId>org.springframework.amqp</groupId>
    <artifactId>spring-rabbit</artifactId>
</dependency>

第二步：添加rabbitmq配置

spring:
  application:
    name: sleuth-demo
  zipkin:
    base-url: http://localhost:9411/
    sender:
      type: rabbit
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    username: guest
    password: guest
    listener: # 这里配置了重试策略
      direct:
        retry:
          enabled: true
  sleuth:
    sampler:
      #采样率值介于 0 到 1 之间，1 则表示全部采集
      probability: 1
      rate: 10

第三步：修改Zipkin启动命令

关于Zipkin启动相关命令可查看：

  • https://github.com/openzipkin/zipkin/tree/master/zipkin-server

ac31e3f91545dd94511fef42ea7feed6.png 
java -jar zipkin-server-2.23.18-exec.jar --RABBIT_ADDRESSES=127.0.0.1:5672 --RABBIT_USER=guest --RABBIT_PASSWORD=guest

docker启动：

docker  run \
--name zipkin-server2 -d \
--restart=always \
-p 9411:9411 \
-e RABBIT_ADDRESSES=162.14.115.18:5672 \
-e RABBIT_USER=admin \
-e RABBIT_PASSWORD=admin \
openzipkin/zipkin:2.21.7

第四步：测试，启动我们的服务，然后访问接口http://localhost:8989/

zipkin就是自动创建的队列，通过这个队列进行发送消息的！

ba3a92daf902a7b15d35d76f9fc6411d.png

打开zipkin仍然可以看到调用信息。

8aed4240d8cfbfd695c8f009df461281.png

2.6. Sleuth到底给Zipkin都发送了哪些数据？

想知道这个其实非常简单，我们只需要将zipkin给停止掉，然后调用我们的服务接口即可。这时候队列当中的消息就没有人消费了，然后我们就可以通过RabbitMQ管理页直接获取消息。

33b2b7d0fd120e4557d1d815e08ed599.png

2.7. Zipkin配置持久化

假如不配置zipkin持久化，当我们把jar包给停止后，所有收集到的消息会直接清除！针对于数据持久化zipkin提供了好几种种方式，常用的有两种，一种存储到mysql，另一种是Elasticsearch。

方式一：持久化到mysql

SQL文件：

  • https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysql-v1/src/main/resources/mysql.sql

官网配置：

  • https://github.com/openzipkin/zipkin/tree/master/zipkin-server

9560163383ef674ecda703bfa062f6c5.png

配置持久化相当简单，只需要在mysql创建一个库和表，然后zipkin启动的时候指定持久化方式为mysql即可。

java -jar zipkin-server-2.23.18-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=root --RABBIT_ADDRESSES=127.0.0.1:5672 --RABBIT_USER=guest --RABBIT_PASSWORD=guest
方式二：持久化到Elasticsearch

这一种我就不再演示了，教程可以看官网：

  • https://github.com/openzipkin/zipkin/tree/master/zipkin-server

278e3ea990bfef5c9121e7683d85bece.png

三、引入sleuth怎么输出traceId

首先我们要找到SpringBoot默认的logback配置

389a692c61631ecd94b64ba3f0473d9e.png 5d339093ef1e8033bc96b4b0223b1ff3.png

base.xml引用了console-appender.xml和defaults.xml

497c92ad690353c4c95bac86cdd0e8fa.png

我们之所以不配置日志，springboot也可以控制打印日志主要是以下：

3c1d18dcb94f18d000611645fc59a16b.png

CONSOLE_LOG_PATTERN就是springboot默认的日志格式：日志格式当中使用到了一个LOG_DATEFORMAT_PATTERN变量

e1a5c3d304b0199c407d870f74122e0e.png c421d0748db89713aedef2d5fb3a1254.png

主要是由TraceEnvironmentPostProcessor类当中的postProcessEnvironment方法在启动的时候判断是否开启了sleuth，假如开启了会直接设置LOG_DATEFORMAT_PATTERN变量。

ca568a9c9dc4a5658e361f220179fbd1.png

四、logback日志问题

分布式系统中，如何快速定位某个用户的请求日志？

据我了解 zikpin并没有提供详细报错日志，例如是哪行报错，通过zipkin我们可以知道是链路中哪个服务报错，这时候我们可以通过traceid去日志文件当中查看详细报错信息！

但是有时候我们项目当中使用了logback.xml，日志格式里面并没有设置traceid。那到底应该如何设置呢？

我们可以参考springboot默认的日志配置，然后配置如下：

<?xml version="1.0" encoding="UTF-8"?>

<configuration scan="true" scanPeriod="60 seconds" debug="false">
    <!-- 参考SpringBoot默认的logback配置，增加了error日志文件 -->
    <!-- org/springframework/boot/logging/logback/base.xml  -->

    <conversionRule conversionWord="clr" converterClass="org.springframework.boot.logging.logback.ColorConverter" />
    <conversionRule conversionWord="wex" converterClass="org.springframework.boot.logging.logback.WhitespaceThrowableProxyConverter" />
    <conversionRule conversionWord="wEx" converterClass="org.springframework.boot.logging.logback.ExtendedWhitespaceThrowableProxyConverter" />

    <property name="LOG_PATH" value="./logs"/>
    <property name="CONSOLE_LOG_PATTERN" value="${CONSOLE_LOG_PATTERN:-%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>
    <property name="FILE_LOG_PATTERN" value="${FILE_LOG_PATTERN:-%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd HH:mm:ss.SSS}} ${LOG_LEVEL_PATTERN:-%5p} ${PID:- } --- [%t] %-40.40logger{39} : %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

    <!-- 控制台日志 -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
        </encoder>
    </appender>

    <!--获取比info级别高(包括info级别)但除error级别的日志-->
    <appender name="file_info" class="ch.qos.logback.core.rolling.RollingFileAppender">
     <file>${LOG_PATH}/sys-info.log</file>
        <!-- 循环政策：基于时间创建日志文件 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 日志文件名格式 -->
            <fileNamePattern>${LOG_PATH}/sys-info.%d{yyyy-MM-dd}.log</fileNamePattern>
            <!-- 日志最大的历史 60天 -->
            <maxHistory>60</maxHistory>
  </rollingPolicy>
  <encoder>
   <pattern>${FILE_LOG_PATTERN}</pattern>
  </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>DENY</onMatch>
            <onMismatch>ACCEPT</onMismatch>
        </filter>
 </appender>

 <appender name="file_error" class="ch.qos.logback.core.rolling.RollingFileAppender">
     <file>${LOG_PATH}/sys-error.log</file>
        <!-- 循环政策：基于时间创建日志文件 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 日志文件名格式 -->
            <fileNamePattern>${LOG_PATH}/sys-error.%d{yyyy-MM-dd}.log</fileNamePattern>
            <!-- 日志最大的历史 60天 -->
            <maxHistory>60</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>${FILE_LOG_PATTERN}</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <!-- 过滤的级别 -->
            <level>ERROR</level>
            <!-- 匹配时的操作：接收（记录） -->
            <onMatch>ACCEPT</onMatch>
            <!-- 不匹配时的操作：拒绝（不记录） -->
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 异步输出 -->
    <appender name="ASYNC-INFO" class="ch.qos.logback.classic.AsyncAppender">
        <!-- 不丢失日志.默认的,如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志 -->
        <discardingThreshold>0</discardingThreshold>
        <!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
        <queueSize>512</queueSize>
        <!-- 添加附加的appender,最多只能添加一个 -->
        <appender-ref ref="file_info"/>
    </appender>

    <appender name="ASYNC-ERROR" class="ch.qos.logback.classic.AsyncAppender">
        <!-- 不丢失日志.默认的,如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志 -->
        <discardingThreshold>0</discardingThreshold>
        <!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
        <queueSize>512</queueSize>
        <!-- 添加附加的appender,最多只能添加一个 -->
        <appender-ref ref="file_error"/>
    </appender>

    <!-- 日志总开关 -->
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
        <appender-ref ref="ASYNC-INFO" />
        <appender-ref ref="ASYNC-ERROR" />
    </root>

    <!-- 日志过滤 -->
    <logger name="org.apache.catalina.startup.DigesterFactory" level="ERROR"/>
    <logger name="org.apache.catalina.util.LifecycleBase" level="ERROR"/>
    <logger name="org.apache.coyote.http11.Http11NioProtocol" level="WARN"/>
    <logger name="org.apache.sshd.common.util.SecurityUtils" level="WARN"/>
    <logger name="org.apache.tomcat.util.net.NioSelectorPool" level="WARN"/>
    <logger name="org.eclipse.jetty.util.component.AbstractLifeCycle" level="ERROR"/>
    <logger name="org.hibernate.validator.internal.util.Version" level="WARN"/>
</configuration>

五、除了Zipkin还有哪些链路跟踪

0a30b5393ea4acec6b214fc2a5a86fba.png

  • CAT是一个更综合性的平台,提供的监控功能最全面，国内几个大厂生产也都在使用。但研发进度及版本更新相对较慢。

  • Zipkin由Twitter开源，调用链分析工具，基于spring-cloud-sleuth得到广泛使用，非常轻量，使用部署简单。

  • Skywalking专注于链路和性能监控，国产开源，埋点无侵入，UI功能较强。能够加入Apache孵化器，设计思想及代码得到一定认可，后期应该也会有更多的发展空间及研发人员投入。目前使用厂商最多。版本更新较快。

  • Pinpoint专注于链路和性能监控，韩国研发团队开源，埋点无侵入，UI功能较强，但毕竟是小团队，不知道会不会一直维护着，目前版本仍在更新中

a4dd5d44a12a9d2c830737929fd30a4b.png

支持的存储：

43b858d09215662c3c09baa36f9565a5.png

感谢阅读，希望对你有所帮助 :) 

来源：blog.csdn.net/weixin_43888891/article/

details/126594260

推荐
Java面试题宝典
技术内卷群，一起来学习！！


PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!
Java知音_
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SpringCloud链路追踪组件Sleuth配置方法解析
08-19
主要介绍了SpringCloud链路追踪组件Sleuth配置方法解析,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
spring cloud sleuth 全链路追踪 demo
10-25
spring cloud sleuth 全链路追踪
spring cloud sleuth入门使用
最新发布
weixin_43811057的博客
03-10 1130
详细介绍Spring Cloud 系列之 Sleuth 链路追踪（一）Spring Cloud Sleuth 为 Spring Cloud 实现了分布式跟踪解决方案。兼容 Zipkin，HTrace 和其他基于日志的追踪系统，例如 ELK（Elasticsearch 、Logstash、 Kibana）。链路追踪：通过 Sleuth 可以很清楚的看出一个请求都经过了那些服务，可以很方便的理清服务间的调用关系等。性能分析。
spring cloud sleuth 全链路追踪数据表
10-25
spring cloud sleuth 全链路追踪数据表
09Spring Cloud Sleuth：分布式请求链路跟踪1
08-04
09Spring Cloud Sleuth：分布式请求链路跟踪1
浅谈Spring-cloud 之 sleuth 服务链路跟踪
08-28
本篇文章主要介绍了浅谈Spring-cloud 之 sleuth 服务链路跟踪，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
Spring Cloud Sleuth介绍以及简单示例
记录并分享一些日常工作和学习笔记
10-23 2281
Spring Cloud Sleuth是一个分布式追踪系统，用于在分布式系统中跟踪和解决请求的性能问题。它提供了一套API和工具，帮助开发人员在微服务架构中跟踪请求的流程，并可以追踪请求在不同微服务之间的传递。Spring Cloud Sleuth通过在请求的不同环节中添加唯一的标识符，称为Trace ID和Span ID，来追踪请求的路径和性能。Trace ID是整个请求的唯一标识符，Span ID是每个环节中的唯一标识符。通过这些标识符，开发人员可以分析请求的流程和性能瓶颈，并进行优化。
Spring Cloud Sleuth使用简介
热门推荐
楠倏的博客
09-08 5万+
Spring-Cloud Spring Cloud为开发者提供了在分布式系统(如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话和集群状态)操作的开发工具。使用SpringCloud开发者可以快速实现上述这些模式。   SpringCloud Sleuth Distributed tracing for Spring Clo
SpringCloud (十) ---------- Sleuth 分布式链路跟踪
在森林里麋了鹿
05-05 2292
目录一、分布式链路跟踪概述二、Spring Cloud Sleuth三、整合 Zipkin 实现分布式链路跟踪1. Zipkin 概述2. 搭建 Zipkin Server3. Sleuth 微服务整合 Zipkin四、Zipkin Server 数据持久化1. 使用 Elastic Search 做数据持久化2. zipkin 与 Elastic Search 整合 一、分布式链路跟踪概述 前面我们接触过几种微服务的监控方式，比如 Spring Boot Actuator 监控微服务，Spring Bo
SpringCloud Sleuth入门介绍
波波烤鸭的博客
06-30 2万+
案例代码:https://github.com/q279583842q/springcloud-e-book 一、Sleuth介绍   为什么要使用微服务跟踪?它解决了什么问题？ 1.微服务的现状？ 微服务的现状   随着业务的发展，单体架构变为微服务架构，并且系统规模也变得越来越大，各微服务间的调用关系也变得越来越复杂。 多服务协同工作   在微服务的应用中，一个由客户端发起的请求在后端系统中会...
Spring Cloud Sleuth在分布式中进行日志跟踪
怪咖@的博客
09-01 2034
Sleuth是什么？Zipkin是什么？他们两个是什么关系？Sleuth怎么用？Zipkin怎么用？Zipkin怎么配置持久化？怎么修改Sleuth发消息方式？引入sleuth是怎么输出traceId的？除了Zipkin还有哪些链路跟踪？针对于这些问题本篇文章会一一讲解！
springboot整合netty和sleuth和MDC生成traceId
qq_40907704的博客
11-29 1952
springboot整合netty，利用slf4j的MDC来生成traceId做链路追踪，sleuth配合使用【sleuth和MDC可选择不使用，那就不需要编写aop和注解，不需要引入aop和sleuth】。 1：所需要依赖的jar（根据自己需求选择） <!-- 版本管理 --> <dependencyManagement> <dependencies> <dependency>
微服务笔记02
Ernie_linyerun的博客
03-05 361
01. Hystrix断路器 1. 概述 分布式系统面临的问题 分布式系统面临的问题 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。 服务雪崩 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”. 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器
使用Spring Cloud Sleuth在应用中进行日志跟踪
王浩的技术博客
04-16 1万+
Spring Cloud Sleuth是一个在应用中实现日志跟踪的强有力的工具。使用Sleuth库可以应用于计划任务 、多线程服务或复杂的Web请求，尤其是在一个由多个服务组成的系统中。当我们在这些应用中来诊断问题时，即使有日志记录也很难判断出一个请求需要将哪些操作关联在一起。 如果想要诊断复杂操作，通常的解决方案是在请求中传递唯一的ID到每个方法来识别日志。而Sleuth可以与日志框架Logb...
引入sleuth zipkin依赖打印traceId
https://blog.csdn.net/sinat_36710456
03-11 1714
引入sleuth zipkin是怎么打印traceId的？ <!--包含了sleuth+zipkin--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> 一直有个疑问，为什么引入sleuth+zipkin之后，日志
slf4j日志MDC输出格式问题
阿呆的专栏
08-20 2201
配置使用 // 自动配置模板 ... <Property name="layout">%d %p %X{traceId} [%t] %c{10}:%M:%L %m%n</Property> ... <PatternLayout pattern="${layout}"/> ... // 具体项目覆盖配置的格式 <Property name="layout"&...
Spring cloud系列十四 分布式链路监控Spring Cloud Sleuth
不积跬步无以至千里; 不积小流无以成江海
12-26 3万+
1. 概述Spring Cloud Sleuth实现对Spring cloud 分布式链路监控 本文介绍了和Sleuth相关的内容，主要内容如下： Spring Cloud Sleuth中的重要术语和意义：Span、Trance、Annotation Zipkin中图形化展示分布式链接监控数据并说明字段意义 Spring Cloud集成Sleuth + Zipkin 的代码demo: Sleuth
Spring Cloud Sleuth 的实现和使用
wzxue1984的博客
06-18 480
它基于 OpenTracing 和 Zipkin 实现，可以跟踪分散在不同微服务中的请求，生成一条完整的分布式事务链路。Spring Cloud Sleuth 可以跟踪分散在不同微服务中的请求，生成一条完整的分布式事务链路，通过集成 Zipkin 服务器可以实现分布式链路跟踪和日志聚合，方便开发者快速定位和解决分布式应用中的问题。在 Spring Boot 应用程序中，Spring Cloud Sleuth 会自动为每个请求生成一个唯一的跟踪 ID，并将跟踪 ID 添加到日志信息中。表示唯一跟踪 ID，
springcloud sleuth链路追踪
06-28
### 回答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、付费专栏及课程。

余额充值