【Spring Cloud】Spring Cloud之Spring Cloud Sleuth,分布式服务跟踪(1)

一、Spring Cloud Sleuth组件的作用

  为微服务架构增加分布式服务跟踪的能力,对于每个请求,进行全链路调用的跟踪,可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等。

二、项目中如何引入Spring Cloud Sleuth组件
1)增加spring-cloud-starter-sleuth依赖

            <!-- sleuth-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-sleuth</artifactId>
                <version>2.0.3.RELEASE</version>
            </dependency>

2)增加相应的项目配置

# 知道服务名称
spring.application.name: service-order
# 指定leuth的抽样比例,1代表全部,该参数用于控制跟踪信息是否发送到第三方服务上入zipkin
sleuth.sampler.probability: 1

3)修改项目日志的打印格式,目的就是打印跟踪相关的信息,入traceid,spanid等等

console-pattern:控制台输出的日志格式
file-pattern: 文件输出的日志格式
console-pattern:  ‘%d{yyyy-MM-dd HH:mm:ss.SSS} [${spring.application.name:-},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}] %boldYellow([%thread]) %highlight(%-5level) %boldGreen(%logger{50}.%M\(%F:%L\)) - %msg%n‘
file-pattern: ‘%d{yyyy-MM-dd HH:mm:ss.SSS} [${spring.application.name:-},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}] [%thread] %-5level %logger{50} - %msg%n‘

4)controller方法增加日志输出并启动项目,用于查看日志打印的效果,比如

log.info("test sleuth log");

三、Sleuth相关概念介绍

1)Trace ID、SpanId等值介绍

运行项目并请求,你会看到这样的日志,如下:

2019-09-10 00:37:15.585  INFO [service-order,313fe940c4574c66,313fe940c4574c66,true] 5687 --- [io-10850-exec-1] c.zbq.order.controller.OrderController   : test sleuth log

其中红色标出的为跟踪日志:[service-order,313fe940c4574c66,313fe940c4574c66,true]

这些元素正是实现分布式服务跟踪的重要组成部分,每个值的含义如下所述。

  • 第一个值:service-order,它记录了应用的名称,也就是application.yml或bootstrap.yml中spring.application.name参数配置的属性。
  • 第二个值:f410ab57afd5c145,Spring Cloud Sleuth生成的一个ID,称为Trace ID,它用来标识一条请求链路。一条请求链路中包含一个Trace ID,多个Span ID。
  • 第三个值:a9f2118fa2019684,Spring Cloud Sleuth生成的另外一个ID,称为Span ID,它表示一个基本的工作单元,比如发送一个HTTP请求。
  • 第四个值:false,表示是否要将该信息输出到Zipkin等服务中来收集和展示。

上面四个值中的Trace ID和Span ID是Spring CloudSleuth实现分布式服务跟踪的核心。在一次服务请求链路的调用过程中,会保持并传递同一个Trace ID,从而将整个分布于不同微服务进程中的请求跟踪信息串联起来。若多个服务同属于一个前端服务请求来源,那么它们的Trace ID是相同的,处于同一条请求链路中。

·X-B3-TraceId:一条请求链路(Trace)的唯一标识,必需的值。·X-B3-SpanId:一个工作单元(Span)的唯一标识,必需的值。·X-B3-ParentSpanId:标识当前工作单元所属的上一个工作单元,Root Span(请求链路的第一个工作单元)的该值为空。·X-B3-Sampled:是否被抽样输出的标志,1表示需要被输出,0表示不需要被输出。·X-Span-Name:工作单元的名称。

2)sleuth日志信息的抽样收集

Sleuth中的抽样收集策略是通过Sampler接口实现的
默认情况下,Sleuth会使用ProbabilityBasedSampler实现的抽样策略,以请求百分比的方式配置和收集跟踪信息。我们可以通过在application.properties中配置下面的参数对其百分比值进行设置,它的默认值为0.1,代表收集10%的请求跟踪信息。比如我们配置中指定的:

sleuth.sampler.probability: 1

在开发调试期间,通常会收集全部跟踪信息并输出到远程仓库,我们可以将其值设置为1。

原文地址:https://www.cnblogs.com/756623607-zhang/p/11518683.html

时间: 2024-10-08 07:32:30

【Spring Cloud】Spring Cloud之Spring Cloud Sleuth,分布式服务跟踪(1)的相关文章

第11章 分布式服务跟踪: Spring Cloud Sleuth

通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果, 在复杂的微服务架构系统中, 几乎每一个前端请求都会形成一条复杂的分布式服务调用链路, 在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败.这时候,对于每个请求, 全链路调用的跟踪就变得越来越重要, 通过实现对请求调用的跟踪可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等.Spring Cloud Sleuth 提供了 一套完整的解决的分布式服务跟踪问题的方案

Spring Cloud构建微服务架构 分布式服务跟踪(跟踪原理)【Dalston版】

通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一些要点. 分布式系统中的服务跟踪在理论上并不复杂,它主要包括下面两个关键点: 为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的Trace ID.

Spring Cloud构建微服务架构 分布式服务跟踪(抽样收集)【Dalston版】

通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比如:预警延迟过长的请求链路.查询请求链路的调用明细等.此时,我们在对接分析系统时就会碰到一个问题:分析系统在收集跟踪信息的时候,需要收集多少量的跟踪信息才合适呢? 理论上来说,我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况,并给出更精准的预警和分析,但是在高并发的分布式系统运行时,大量的请求调用会产生海量的跟踪日志信息,如果我

【Dubbo实战】 Dubbo+Zookeeper+Spring整合应用篇-Dubbo基于Zookeeper实现分布式服务(转)

Dubbo与Zookeeper.Spring整合使用 Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载. 一:单机模式安装zookeeper 1,下载zookeeper注册中心,下载地址:http://www.apache.org/dyn/closer.cgi/zookeeper/ 下载后解压即可,进入E:\zookeeper-3.3.6\zookeeper-3.3.6

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin【Finchley 版】

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin[Finchley 版] 发表于 2018-04-24 | 随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何快读定位服务故障点,以对症下药.于是就有了分布式系统调用跟踪的诞生. 现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文<Dapper, a Larg

跟我学SpringCloud | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪

SpringCloud系列教程 | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 在分布式服务架构中,需要对分布式服务进行治理--在分布式服务协同向用户提供服务时,每个请求都被哪些服务处理?在遇到问题时,在调用哪个服务上发生了问题?在分析性能时,调用各个服务都花了多长时间?哪些调用可以并行执行?-- 为此,分布式

Spring Cloud第十三篇 | Spring Boot Admin服务监控

本文是Spring Cloud专栏的第十三篇文章,了解前十二篇文章内容有助于更好的理解本文: Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 Spring Cloud第三篇 | 搭建高可用Eureka注册中心 Spring Cloud第四篇 | 客户端负载均衡Ribbon Spring Cloud第五篇 | 服务熔断Hystrix Spring Cloud第六篇 | Hystrix仪表盘监控

Spring Cloud 分布式链路跟踪 Sleuth + Zipkin + Elasticsear

随着业务越来越复杂,系统也随之进行各种拆分,特别是随着微服务架构的兴起,看似一个简单的应用,后台可能很多服务在支撑:一个请求可能需要多个服务的调用:当请求迟缓或不可用时,无法得知是哪个微服务引起的,这时就需要解决如何快速定位服务故障点,Zipkin 分布式跟踪系统就能很好的解决这样的问题. 那么到底怎么使用呢?接下来完成一个具体的实例来体会一把微服务链路追踪: 本文使用的 Spring Cloud Finchley 版本,和其他版本会有不同 我们使用user-service,order-serv

Spring Cloud 微服务分布式链路跟踪 Sleuth 与 Zipkin

Zipkin 是一个开放源代码分布式的跟踪系统,由 Twitter 公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集.存储.查找和展现.它的理论模型来自于Google Dapper 论文. 每个微服务向 Zipkin 报告计时数据,Zipkin 会根据调用关系通过 Zipkin UI 生成依赖关系图,显示了多少跟踪请求通过每个服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如用户每次请求服务的处理时间等,可方便的监测系统中存在的瓶颈. Zip