Spring Cloud Sleuth 全链路日志跟踪

可视化全链路日志追踪 传统的ELK方案是一种滞后的业务追踪,需要事后从大量离散的日志中搜集和筛选出需要的日志,并人工进行日志的串联分析,其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时,实时地完成了链路的动态串联,但由于是会话级别且仅关注于调用关系等问题,导致其无法很好地应用于业务追踪。因此,无论是传统的ELK方案还是分布式会话跟踪方案,都难以满足日益复杂的业务追踪需求。 阅读详情

1.为什么要使用sleuth?

在微服务框架中,一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果,每一个次请求都会形成一条复杂的分布式服务调用链路,链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。sleuth则将服务之间的调用记录起来,使服务之间的调用关系清晰明了,方便排查问题(主要是生成一个traceId,表示这次请求的id)

2.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 服务的位置。

3.zipkin是做什么的?

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

4.使用

三个子模块,consumer provider, consumer调用provider

父pom文件

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.levi</groupId>
    <artifactId>sleuth</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <modules>
        <module>provider</module>
        <module>consumer</module>
        <module>third</module>
    </modules>

    <properties>
        <java.version>1.8</java.version>
        <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>
        <lombok.version>1.18.24</lombok.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>
            <dependency>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>${lombok.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>


    <build>
        <finalName>${project.artifactId}</finalName>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                    <encoding>${project.build.sourceEncoding}</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

每个子模块的依赖

<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>
        <!-- 引入 rabbitmq 依赖 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-amqp</artifactId>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
    </dependencies>

yml配置文件,注意修改应用名称和端口,sleuth给zipkin发送数据使用的是http,并发量大的话可能会占用大量线程,这里使用rabbitmq,sleuth先把数据发送到rabbitmq,zipkin从rabbitmq进行消费

server:
  port: 8082

spring:
  application:
    name: sleuth-consumer
  zipkin:
    base-url: http://ip:9411/ # 指定zipkin地址
    sender:
      type: rabbit  #指定sleuth发送到rabbitmq,zipkin从rabbitmq进行消费
    sleuth:
      sampler:
        # 采样率值介于 0 到 1 之间,1 则表示全部采集
        probability: 1
        # 每秒采集的数量,默认是10,通过设置这个可以有效的避免消息过大
        rate: 10
  rabbitmq:
    host: ip
    port: 5672
    username: admin
    password: admin
    listener: # 这里配置了重试策略
      direct:
        retry:
          enabled: true
logging:
  level:
    org.springframework.web.servlet.DispatcherServlet: DEBUG

provider

@SpringBootApplication
@RestController
@Slf4j
@EnableFeignClients
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
    @GetMapping("/provider")
    public String provider() {
        log.info("provider");
        return "provider";
    }
}

consumer

@SpringBootApplication
@RestController
@EnableFeignClients
@Slf4j
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }

    @Autowired
    private ProviderService providerService;

    @GetMapping("/consumer")
    public String consumer() {
        providerService.provider();
        log.info("consumer>>>>>>>>>>>");
        return "consumer";
    }
}

rpc接口

@FeignClient(value = "providerService",url = "http://localhost:8081")
public interface ProviderService {

    @GetMapping("/provider")
    String provider();

}

启动zipkin服务,这里使用docker启动,把数据持久化到es(指定es的地址),不然的话zipkin服务重启之后数据就没了
注意:zipkin,rabbitmq,es要在同一个docker网络下

docker run \
--network mynet \
--name zipkin-server -d \
--restart=always \
-p 9411:9411 \
-e RABBIT_ADDRESSES=rabbitMQ:5672 \
-e RABBIT_USER=admin \
-e RABBIT_PASSWORD=admin \
-e STORAGE_TYPE=elasticsearch \
-e ES_HOSTS=elasticsearch:9200 \
openzipkin/zipkin:2.21.7

在这里插入图片描述
启动成功

访问zipkin的ui界面,http://ip:9411/zipkin/(云服务器要要在安全组吧9411端口放开),这时候没有数据
在这里插入图片描述
访问几次consumer接口 http://localhost:8082/consumer,在zipkin的ui界面点击run query就会有数据
在这里插入图片描述
随便点击一个,会显示服务之间的调用链,
在这里插入图片描述
也可以通过右上角traceId搜索
在这里插入图片描述

使用logback打印traceId

logback配置文件

<?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>

在这里插入图片描述
服务名,traceId,spanId都打印出来了

全链路日志追踪traceId(http、dubbo、mq) 一、概述 1、目的 目前许多系统项目之间的调用,有基于微服务的,有通过HTTP请求的,还有通过mq的。那么在处理一次请求的时候,可能会调用多个服务或者调用多个其他系统功能,这样就会产生很多的日志,此时,如果想查看这一次调用的完整的请求链路的日志时,就会变得比较困难,虽然我们有一些集中的日志收集工具比如ELK,我们需要把这一些日志串联起来,这个问题很关键,因为如果没有串联起来,排查日志就是一件很困难的事情。 2、解决办法 一般来说,系统之间的调用不外乎两种:http和dubbo。当然还有通过中间. 阅读详情

相关推荐

【Nginx日志关联由Sleuth产生的微服务traceid】

这里写自定义目录标题背景描述问题描述解决思路思路一思路二解决方案(思路二) 背景描述 系统采用了前后端分离的架构搭建: 前端是采用Vue 2.X+elementUI开发,构建的安装包部署到Nginx服务上。 后端业务采用Java+spring cloud微服务架构,前置spring cloud gateway网关接入,后置各种业务微服务应用构成,通过alibaba Nacos做服务发现和应用配置。 问题描述 需求是想把系统从Vue前端到Java后端的每一次访问日志通过唯一ID全链路跟踪起来。在Java

大料哈哈的博客 885

微服务—链路追踪(Sleuth+Zipkin)

这里写自定义目录标题1、链路追踪介绍2、为什么需要链路追踪?2.1、那该如何解决呢?2.2、常见的链路追踪技术有下面这些:3、Sleuth3.1、Sleuth介绍3.2、相关术语3.3、Sleuth入门4、Zipkin4.1、ZipKin介绍4.2、ZipKin服务端安装4.3、Zipkin客户端集成4.4、ZipKin数据持久化4.4.1使用mysql实现数据持久化 1、链路追踪介绍 在大型系统的微服务化构建中,一个系统被拆分成了许多模块。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种

shi_AXing_a的博客 1万+

Spring Cloud及微服务(十):分布式服务跟踪Spring Cloud Sleuth

出现背景 随着业务的发展,系统规模也会变得越来越大,各微服务间的调用关系也变越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一条复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。 所以,对于每个请求,全链路调用的跟踪可以帮助我们快...

YETA的博客 273

【SpringCloud Alibaba】(十一)学习 Sleuth 链路追踪

随着互联网业务快速扩展,企业的业务系统变得越来越复杂,不少企业开始向分布式、微服务方向发展,将原本的单体应用拆分成分布式、微服务。这也使得当客户端请求系统的接口时,原本在同一个系统内部的请求逻辑变成了需要在多个微服务之间流转的请求。单体架构中可以使用 AOP 在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间,使用 AOP 捕获异常也可知道是哪里的调用导致的异常。

sco5282的博客 2128

Spring Cloud Sleuth链路追踪

Spring Cloud Sleuth是 Spring Cloud生态系统中的一个微服务组件,用于实现分布式请求链路追踪(Distributed tracing),它能够帮助开发人员查看每一次远程调用的详细信息。本文将对Spring Cloud Sleuth链路追踪进行详细分析,并给出实践案例。Spring Cloud Sleuth是一个开源的Spring Cloud组件,提供了分布式请求跟踪解决方案。

AI天才研究院 1610

K-means在关键词聚类中的尝试

K-means在文本聚类中的尝试 K-means算法是无监督的聚类算法。它的算法思想是:先随机选取K个对象作为初始的聚类中心。然后计算每个对象与各个种子聚类中心之间的距离,把每个对象分配给距离它最近的聚类中心。聚类中心以及分配给它们的对象就代表一个聚类。一旦全部对象都被分配了,每个聚类的聚类中心会根据聚类中现有的对象被重新计算。 K-means算法的关键点在于: 初始k个聚类中心的选择 距离的计...

BigPig_LittleTail的博客 5572

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

点击关注公众号,实用技术文章及时了解概述分布式系统面临的问题Sleuth是什么Zipkin是什么链路监控相关术语实战练习入门练习Zipkin下载与启动搭建链路监控步骤sleuth相关配置向Zipkin发送消息的方式Sleuth到底给Zipkin都发送了哪些数据?Zipkin配置持久化引入sleuth是怎么输出traceId的logback日志问题除了Zipkin还有哪些链路跟踪本篇文章所涉及到的d...

好好学java 7026

5.1 Tessent Atpg系列 第八章 Test Pattern Generation - Verify Test Pattern

为什么要做基于timing的仿真,意义在于可以比较ATPG工具和simulator工具的差异性。因为时序的差异导致不同的结果。首先你需要通过write_patern 这句cmd来写出pattern,默认是parallel 模式,除非你用-serial 指定写出serial, 因为serial 文件非常大,所以你可以使用-sample 开关写出部分pattern即可,工具会根据每一种pattern 类型都会至少保存一只。 另外,你也可以使用-start -end 开关来减少文件大小,但是这样的截取,是不可靠的

ciscomonkey的博客 7760

一个现网bug让我彻底弄懂微服务日志链路追踪

一个现网bug让我彻底弄懂微服务日志链路追踪 需求: 异步帮批量用户订购话费套餐,成功发送短信,失败记录信息。 问题描述: 根据运营人员及测试反馈最近有一批500个账户的套餐开通中,失败数+成功数=499,还有一笔订单凭空消失了...

honger_hua的博客 906

1. 基于STM32的1.28寸圆形IPS屏(GC9A01)驱动移植实战:软件SPI与硬件SPI双方案详解

本文详细介绍了如何在STM32平台上为1.28寸圆形IPS屏(GC9A01驱动芯片)移植驱动程序,涵盖软件SPI与硬件SPI两种实现方案。内容从引脚定义、工程搭建、GPIO配置到SPI外设初始化逐步详解,并提供了完整的测试代码,帮助开发者根据项目需求(灵活性或性能)选择合适的通信方式,快速点亮屏幕并集成到智能手表等嵌入式项目中。

weixin_42300144的博客 203

IMA知识库:从0到1的架构设计与实践

本文探讨了AI时代知识库系统的架构设计与演进路径。通过分析知识入库、知识管理和知识应用三大核心业务流程,提出了应对数据多样性、处理标准化、流量洪峰等挑战的解决方案。重点介绍了基于统一数据格式的解耦设计、异步处理架构、服务拆分策略以及权限安全体系,构建了一个稳定、高效且可扩展的知识库系统。文章强调优秀架构需要持续演进,通过识别薄弱点不断优化,最终实现技术方案与业务需求的平衡。

lovehu6686的博客 1736

引入Springcloud--Sleuth-链路追踪中MDC是如何获取到traceid和何时放入traceid的

而CurrentTraceContext类型的bean是通过SleuthLogAutoConfiguration这个配置类注入的,可以看到以下代码,下面的代码通过后置处理器对CurrentTraceContext类型的bean进行处理,如果该CurrentTraceContext类型的bean不是Slf4jCurrentTraceContext类型的,则对该类型的bean通过代理的方式向spring容器中注入了Slf4jCurrentTraceContext类型的bean。在该类中通过以下代码。

xl649138628的专栏 1807

STM32F103C8T6+HX711实战:从零打造智能体重秤(附OLED显示与语音播报)

本文详细介绍了基于STM32F103C8T6微控制器和HX711称重模块,从零构建智能体重秤的完整实战教程。内容涵盖硬件选型、系统架构、驱动编写、数据滤波校准算法,并实现了OLED显示与语音播报功能。该项目是嵌入式学习的综合性实践,尤其适合作为毕业设计课题,帮助开发者掌握传感器应用、数据处理及人机交互等核心技能。

weixin_28285943的博客 517

SpringCloud实战|9.SpringCloud 整合sleuth,实现全链路追踪

SpringCloud实战|9.SpringCloud 整合sleuth,实现全链路追踪

1252

从零解析:富斯i6遥控器与STM32的IBUS协议通信实战

本文详细解析了富斯i6遥控器与STM32通过IBUS协议通信的实战指南,涵盖硬件准备、协议解析、驱动实现及常见问题解决。特别适合机器人及智能小车开发者,提供低成本、高可靠性的无线控制方案,助力快速实现多通道控制功能。

weixin_29193359的博客 439

14、5G物理层的灵活解决方案:广义频分复用(GFDM)

广义频分复用(GFDM)作为一种高度灵活的5G物理层多载波调制方案,能够满足多样化应用场景的需求,包括高吞吐量的比特管道通信、低功耗高连接数的物联网、超低延迟的触觉互联网以及广覆盖的无线区域网。通过参数化配置,GFDM可适配LTE资源网格,实现与现有系统的兼容与共存。其支持多种解调方式、干扰消除技术、OQAM映射及预编码机制,兼具低带外发射、高频谱效率和强鲁棒性。GFDM还能统一描述OFDM、FBMC、FTN等多种经典与先进波形,成为5G及未来通信系统中极具潜力的通用波形框架。

gold8的专栏 108

spring-cloud-sleuth 3.x的版本传递traceId和自定义属性

为了简化后续做类似功能的童鞋操作,故整理一篇针对traceId和自定义属性全链路传递的处理操作,整体调试流程还是耽误了不少时间的。 要做的目标 实现全链路traceId传递,自定义全链路traceUrl标记(traceUrl的规则是比如:比如A-》B-》 C 这样得到的就是 traceUrl=/A/B/C) 思路 1.依赖sleuth传递各种信息 ,使用方式遵循它的规则 2.feign调用处增加处理标记逻辑 3.web服务入口处增加拦截处理标记逻辑 4.异步线程池处理逻辑(sleuth自带功能

幸运小侯子 3699

FPGA 学习笔记:解决FPGA程序固化重新上电程序不运行的问题

FPGA 学习笔记:解决FPGA程序固化重新上电程序不运行的问题

坚韧与专注 1万+

分布式服务跟踪Sleuth

一、Sleuth前言 随着业务的发展,系统规模也会变得越来越大,各微服务间的调用关系也变得越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一条复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候, 对于每个请求,全链路调...

gr32442187do的博客 162

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

# Spring Cloud Trace 示例:使用 Spring Cloud Sleuth 和 Zipkin 实现分布式链路追踪

Spring Cloud Sleuth 是一个分布式链路追踪工具,用于在微服务架构中追踪请求的完整调用链路。结合 Zipkin,可以实现链路数据的收集和可视化展示。

[Blog][Domain] programb.blog.youkuaiyun.com 835

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

上一篇: 使用MDC跟踪日志
下一篇: springcloud接入dynamic-tp动态线程池
livel_java
博客等级 码龄9年 2916粉丝 29原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值