精华内容
下载资源
问答
  • 链路追踪】sleuth链路追踪+Zipkin分析
    多人点赞 热门讨论
    2022-03-30 15:06:31

    一、前言:首先,我们来了解一下为什么要使用链路追踪

            微服务架构是一个分布式架构,它按业务划分服务单元,一个分布式系统往往有很多个服务单元。由于服务单元数量众多,业务的复杂程度不同,如果出现了错误和异常 , 很难去定位。主要体现在, 一个请求可能需要调用很多个服务,而内部服务的调用复杂性,决定了问题难以定位。

            所以微在服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与,参与的顺序又是怎样的,从而达到每个请求的步骤清晰可见,出了问题,很快定位。链路追踪组件有 Google 的 Dapper,Twitter 的 Zipkin,以及阿里的 Eagleeye (鹰眼)等,它们都是非常优秀的链路追踪开源组件。


    二、基本术语

    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 时间戳便可以得到整个请求所消耗的时间

    三、项目整合Zipkin

    1、docker 安装 zipkin

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

    2、在pom中添加依赖

     <!--zipkin 依赖也同时包含了 sleuth,可以省略 sleuth 的引用-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

    3、在application.yml添加如下配置

    spring:
      zipkin:
        base-url: http://192.168.2.190:9411/	# zipkin 服务器的地址
        discovery-client-enabled: false # 关闭服务发现,否则 Spring Cloud 会把 zipkin 的 url 当做服务名称
        sender:
          type: web # 设置使用 http 的方式传输数据
      sleuth:
        sampler:
          probability: 1  # 设置抽样采集率为 100% ,默认为 0.1 ,即 10%

    四、本地测试

    启动项目,所有功能都跑一遍,然后访问 zipkin 服务器地址,显示如下:

    更多相关内容
  • Spring Boot默认使用LogBack日志系统,并且已经引入了相关的jar包,所以我们无需任何配置便可以使用LogBack打印日志。这篇文章主要介绍了SpringBoot+Logback实现一个简单的链路追踪功能,需要的朋友可以参考下
  • 主要介绍了spring cloud 分布式链路追踪的方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 一份springcloud链路追踪的demo源码,包括了在不使用rabbitmq的情况下得到链路追踪demo和使用了rabbitmq的情况下的链路追踪demo,其中app1,app2使用了rabbitmq的demo,app3,app4未未使用rabbitmq的demo,
  • 2-3、使用探针技术实现无侵入式的监控和链路追踪-韩天峰@学而思
  • 主要介绍了SpringCloud链路追踪组件Sleuth配置方法解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • zipkin为分布式链路调用监控系统,聚合各业务系统调用延迟数据,达到链路调用监控跟踪。 zipkin主要涉及四个组件 collector storage search web UI 1.Collector接收各service传输的数据 2.Cassandra作为Storage的一...
  • 服务链路追踪

    2021-02-22 14:37:54
    服务链路追踪 为什么需要服务追踪 在微服务架构下,由于进行了服务拆分,一次请求往往需要涉及多个服务, 每个服务可能是由不同的团队开发,使用了不同的编程语言,还有可能部署在不同的机器上,分布在不同的数据...

    服务链路追踪

    为什么需要服务追踪

    在微服务架构下,由于进行了服务拆分,一次请求往往需要涉及多个服务,
    每个服务可能是由不同的团队开发,使用了不同的编程语言,还有可能部署在不同的机器上,分布在不同的数据中心。
    服务跟踪系统

    • 可以跟踪记录一次用户请求都发起了哪些调用,

    • 经过哪些服务处理,并且记录每一次调用所涉及的服务的详细信息

    • 通过查看完整的调用链路,形成拓补图可以更加直观的了解业务,

    • 也可以针对当前的系统进行分析,是否需要扩容、优化接口、失败缓解

    通过日志快速定位是调用失败的环节。

    Sleuth概述

    简介

    • Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案
    • 并且兼容支持了 zipkin,你只需要在pom文件中引入相应的依赖即可

    服务追踪说明

    • 微服务架构是通过业务来划分服务的 使用 REST 调用。

    • 对外暴露的一个接口,可能需要很多个服务协同才能完成这个接口功能
      如果链路上任何一个服务出现问题或者网络超时 都会形成导致接口调用失败。

    • 随着业务的不断扩张,服务之间互相调用会越来越复杂。

    在这里插入图片描述

    随着服务的越来越多,对调用链的分析会越来越复杂。它们之间的调用关系也许如下:

    在这里插入图片描述
    好壮观的 :冠状病毒呀!!

    Sleuth链路追踪入门

    虽然,理论比较难弄, 但代码实现到不是很困难!

    • 链路追踪, 主要是因为:
      微服务架构,不同模块完成不同的事情…
      一个功能由多个模块构成… 模块之间相互依赖… 而为了更方便的浏览业务. 以及防止 因某个模块出错:快速的定位错误 排错 完善…
      出现的技术!
    • 所以一般来说:每个模块都要进行 链路追踪配置!

    依赖:

    因为,每个模块都要进行 链路追踪! 就直接定义在父工程模块下了!

    pom.xml

    <!-- 引入Sleuth依赖 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>
    

    .yml 配置文件

    每个模块都要哦~
    application.yml添加日志级别为了能够在 控制台中看到每次调用的情况! 方便实时进行分析

    .yml

    #yml 配置不在任何属性节点下!
    logging:
      level:
        root: INFO              
        org.springframework.web.servlet.DispatcherServlet: DEBUG		# DispatcherServlet 日志级别! 
        org.springframework.cloud.sleuth: DEBUG     					# sleuth 日志级别
    

    启动微服务,调用之后,我们可以在控制台观察到sleuth的日志输出。

    网关:
    在这里插入图片描述
    调用者:
    在这里插入图片描述

    提供者:
    在这里插入图片描述

    • 其中 9bd993c22c807eda是TraceId,后面的是 Span
      仔细分析每个微服务的日志,不难看出请求的具体过程。
    • 查看日志文件并不是一个很好的方法 可以使用Zipkin 进行可视化的查看服务之间的 链路请求!
      当微服务越来越多日志文件也会越来越多,通过Zipkin可以将日志聚合,并进行可视化展示和全文检索。

    Zipkin的概述

    Zipkin 是 Twitter 的一个开源项目

    • 基于 Google Dapper 论文实现,
      它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
    • 我们可以使用它来收集各个服务器上请求链路的跟踪数据:
      并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序
      从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。
      除了面向开发的 API 接口之外,它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细
    • Zipkin 提供了可插拔数据存储方式:In-Memory、MySql、Cassandra 以及 Elasticsearch。

    Zipkin 的基础架构,它主要由 4 个核心组件构成:

    在这里插入图片描述

    • Collector:收集器组件
      它主要用于处理从外部系统发送过来的跟踪信息,
      将这些信息转换为 Zipkin内部处理的 Span 格式,以支持后续的存储、分析、展示等功能

    • Storage: 存储组件
      它主要对处理收集器接收到的跟踪信息,
      默认会将这些信息存储在内存中,
      我们也可以修改此存储策略,通过使用其他存储组件 将跟踪信息存储到数据库中。

    • RESTful API: API 组件
      它主要用来提供外部访问接口。
      比如给客户端展示跟踪信息,或是外接系统访问以实现监控等。

    • Web UI
      基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地 查询 和 分析跟踪信息。

    Zipkin Server的部署和配置

    Zipkin Server下载

    从spring boot 2.0开始,官方就不再支持使用自建Zipkin Server的方式进行服务链路追踪
    *而是直接提供了编译好的 jar 包来给我们使用。可以从官方网站下载先下载Zipkin的web UI *

    我们这里下载的是 zipkin-server-2.12.9-exec.jar

    启动

    windows 控制台:java -jar zipkin-server-2.12.9-exec.jar 启动 Zipkin Server
    在这里插入图片描述

    默认Zipkin Server的请求端口为 9411

    在这里插入图片描述

    客户端Zipkin + Sleuth整合

    通过查看日志分析微服务的调用链路并不是一个很直观的方案

    结合zipkin可以很直观地显示微服务之间的调用关系。

    因为Sleuth是在所以模块下进行链路追踪的, 所以模块下都要进行配置哦!*

    客户端添加依赖

    同样父工程下添加:pom.xml

    <!-- 客户端Zipkin+Sleuth整合  -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>
    

    客户端配置文件

    Spring 属性节点下配置!
    yml.xml

    spring:
      application:
        name: order-provider
      zipkin:
        base-url:  http://127.0.0.1:9411/ 	#zipkin server的请求地址
        sender:
          type: web 						#请求方式,默认以http的方式向zk server发送追踪数据
      sleuth:
        sampler:
          probability: 1.0 					#采样的百分比,所有的监控记录...
    
    • 指定了zipkin server的地址
    • 下面制定需采样的百分比,默认为0.1,即10%,这里配置1,是记录全部的sleuth信息

    测试:

    启动Zipkin Service。通过浏览器发送一次微服务请求。 我们可以根据条件追踪每次请求调用过程
    在这里插入图片描述

    链路追踪Sleuth-Zipkin与Mysql数据的持久化:

    上面说了:
    在这里插入图片描述
    存在内存中: Zipkin服务关闭,监控的数据就丢失了!

    Zipkin持久化数据库! Mysql

    在这里插入图片描述
    mysql 脚本:

    `information_schema`/*
    SQLyog Ultimate v11.33 (64 bit)
    MySQL - 5.5.58 : Database - zipkin
    ********************************************************************* 
    */`zipkin_dependencies`
    
    
    /*!40101 SET NAMES utf8 */;
    
    /*!40101 SET SQL_MODE=''*/;
    
    /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
    /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
    /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
    /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
    CREATE DATABASE /*!32312 IF NOT EXISTS*/`zipkin` /*!40100 DEFAULT CHARACTER SET utf8 */;
    
    USE `zipkin`;
    
    /*Table structure for table `zipkin_annotations` */
    
    DROP TABLE IF EXISTS `zipkin_annotations`;
    
    CREATE TABLE `zipkin_annotations` (
      `trace_id_high` bigint(20) NOT NULL DEFAULT '0' COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit',
      `trace_id` bigint(20) NOT NULL COMMENT 'coincides with zipkin_spans.trace_id',
      `span_id` bigint(20) NOT NULL COMMENT 'coincides with zipkin_spans.id',
      `a_key` varchar(255) NOT NULL COMMENT 'BinaryAnnotation.key or Annotation.value if type == -1',
      `a_value` blob COMMENT 'BinaryAnnotation.value(), which must be smaller than 64KB',
      `a_type` int(11) NOT NULL COMMENT 'BinaryAnnotation.type() or -1 if Annotation',
      `a_timestamp` bigint(20) DEFAULT NULL COMMENT 'Used to implement TTL; Annotation.timestamp or zipkin_spans.timestamp',
      `endpoint_ipv4` int(11) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
      `endpoint_ipv6` binary(16) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null, or no IPv6 address',
      `endpoint_port` smallint(6) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
      `endpoint_service_name` varchar(255) DEFAULT NULL COMMENT 'Null when Binary/Annotation.endpoint is null',
      UNIQUE KEY `trace_id_high` (`trace_id_high`,`trace_id`,`span_id`,`a_key`,`a_timestamp`) COMMENT 'Ignore insert on duplicate',
      KEY `trace_id_high_2` (`trace_id_high`,`trace_id`,`span_id`) COMMENT 'for joining with zipkin_spans',
      KEY `trace_id_high_3` (`trace_id_high`,`trace_id`) COMMENT 'for getTraces/ByIds',
      KEY `endpoint_service_name` (`endpoint_service_name`) COMMENT 'for getTraces and getServiceNames',
      KEY `a_type` (`a_type`) COMMENT 'for getTraces',
      KEY `a_key` (`a_key`) COMMENT 'for getTraces',
      KEY `trace_id` (`trace_id`,`span_id`,`a_key`) COMMENT 'for dependencies job'
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
    
    /*Data for the table `zipkin_annotations` */
    
    /*Table structure for table `zipkin_dependencies` */
    
    DROP TABLE IF EXISTS `zipkin_dependencies`;
    
    CREATE TABLE `zipkin_dependencies` (
      `day` date NOT NULL,
      `parent` varchar(255) NOT NULL,
      `child` varchar(255) NOT NULL,
      `call_count` bigint(20) DEFAULT NULL,
      UNIQUE KEY `day` (`day`,`parent`,`child`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
    
    /*Data for the table `zipkin_dependencies` */
    
    /*Table structure for table `zipkin_spans` */
    
    DROP TABLE IF EXISTS `zipkin_spans`;
    
    CREATE TABLE `zipkin_spans` (
      `trace_id_high` bigint(20) NOT NULL DEFAULT '0' COMMENT 'If non zero, this means the trace uses 128 bit traceIds instead of 64 bit',
      `trace_id` bigint(20) NOT NULL,
      `id` bigint(20) NOT NULL,
      `name` varchar(255) NOT NULL,
      `parent_id` bigint(20) DEFAULT NULL,
      `debug` bit(1) DEFAULT NULL,
      `start_ts` bigint(20) DEFAULT NULL COMMENT 'Span.timestamp(): epoch micros used for endTs query and to implement TTL',
      `duration` bigint(20) DEFAULT NULL COMMENT 'Span.duration(): micros used for minDuration and maxDuration query',
      UNIQUE KEY `trace_id_high` (`trace_id_high`,`trace_id`,`id`) COMMENT 'ignore insert on duplicate',
      KEY `trace_id_high_2` (`trace_id_high`,`trace_id`,`id`) COMMENT 'for joining with zipkin_annotations',
      KEY `trace_id_high_3` (`trace_id_high`,`trace_id`) COMMENT 'for getTracesByIds',
      KEY `name` (`name`) COMMENT 'for getTraces and getSpanNames',
      KEY `start_ts` (`start_ts`) COMMENT 'for getTraces ordering and range'
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
    
    /*Data for the table `zipkin_spans` */
    
    /*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
    /*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
    /*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
    /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
    

    启动Zipkin Server (附带数据库)

    如果,以及启动了上面的,要记得关闭哦!

    Windows 启动命令:

    java -jar zipkin-server-2.12.9-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_DB=zipkin --MYSQL_USER=root --MYSQL_PASS=ok
    
    • STORAGE_TYPE : 存储类型
    • MYSQL_HOST: mysql主机地址
    • MYSQL_TCP_PORT:mysql端口
    • MYSQL_DB: mysql数据库名称
    • MYSQL_USER:mysql用户名
    • MYSQL_PASS :mysql密码

    在这里插入图片描述
    配置好服务端之后,可以在浏览器请求几次。回到数据库查看会发现数据已经持久化到mysql中

    下次重启,依然可以看到 历史的链路追踪:
    在这里插入图片描述

    术语解释

    Span

    Span:基本工作单元 (相当于一次完整的请求!一次请求对应一个 Span )

    Trace

    一系列 Spans 组成的一个树状结构,
    例如,如果你正在运行一个分布式大数据工程,你可能需要创建一个 Trace。


    Span 通过一个 64 位 ID 唯一标识, Trace 以另一个 64 位 ID 表示。 可以在控制台中查看!


    Annotation

    用来即使记录一个事件的存在,一些核心 Annotations 用来定义一个请求的开始和结束:

    在这里插入图片描述
    在Zipkin Ul页面上, 可以之间对某个服务进行查看: 调用方/提供方 响应请求时间…

    • CS
      客户端发起一个请求,这个 Annotation 描述了这个 Span 请求 的开始
    • SS
      服务端获得请求并准备开始处理它,如果将其 ss 减去 cs 时间戳便可得到网络延迟
    • SF
      表明请求处理的完成(当请求返回客户端),如果 sf 减去 ss 时间戳便可得到服务端需要的处理请求时间
    • CF
      表明 Span 的结束,客户端成功接收到服务端的回复,
      如果 cf 减去 cs 时间戳便可得到客户端从服务端获取回复的所有所需时间
    展开全文
  • jaeger-1.32.0-linux-amd64.tar链路追踪二进制安装包
  • 提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。 具体请参考 funtl.com SkyWalking 服务端配置 1、基于 Docker 安装 ElasticSearch Docker及Docker-Compose安装 Centos7(Ubuntu18.04)安装...
  • Skywalking全链路追踪使用说明

    千次阅读 2022-04-27 17:51:22
    因此面对复杂的调用链路,我们需要一款具体如下功能全链路追踪工具,提高我们对业务的掌控度: ①请求链路追踪,快速定位故障;②可视化链路各阶段的耗时,进行性能分析;③ 梳理服务依赖关系;④ 系统指标监控,...

    1、背景与需求:

            随着业务规模的不断增大,系统的复杂度也越来越高,我们的软件架构也进入了分布式的阶段,服务按照不同的维度进行拆分,那么一次请求可能横跨多个服务模块、项目,依赖的中间件也越来越多,其中任何一个节点出现异常,都可能导致业务出现波动或者异常。而传统的日志监控等方式无法很好满足调用链路跟踪,排查问题等需求,这就导致定位/诊断服务异常变得异常复杂。

            因此面对复杂的调用链路,我们需要一款全链路追踪工具,帮助我们实现如下功能,提高我们对业务的掌控度:

    (1)功能性需求:

    • ① 请求链路追踪,快速定位故障,缩短故障的排除时间 以及 判断故障影响范围
    • ② 可视化链路各阶段的耗时,进行性能分析,排除业务瓶颈
    • ③ 梳理服务依赖关系以及优化依赖的合理性
    • ④ 系统指标监控,吞吐量(TPS)、响应时间及错误记录等。

    (2)非功能性需求:

    • 探针的性能消耗:服务调用埋点本身会带来性能损耗,这就需要组件对业务系统的性能影响小
    • 代码的侵入性:对业务系统尽可能少入侵或者无入侵其他,对于使用方透明,减少开发人员的负担。

    2、Skywalking 简介:

            skywalking 是一个优秀的国产开源APM组件,是一个对 Java 分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。2015年由个人吴晟开源 , 2017年加入Apache孵化器。短短两年就被Apache收入麾下,实力可见一斑。

            skywalking 支持 SpringBoot、SpringCloud、dubbo 集成,代码无侵入,通信方式采用 GRPC,性能较好,实现方式是 Java 探针,支持告警,支持JVM监控,支持全局调用统计等等,功能较完善。

    3、Skywalking 使用说明:

    3.1、仪表盘:

            仪表盘是Skywalking的首页,它提供多个指示板来可视化指标,例如:服务(APM)、数据库(Database)等等。

    3.1.1、APM(服务):

            APM面板总体分为四个维度:Global(全局)、Service(服务)、Instance(实例)、Endpoint(API),提供筛选功能,每块都包含一些指标。

    (1)Global(全局)指标:

    • Services Load:服务每分钟请求数
    • Slow Services:慢响应服务,按响应时间排序topN,单位ms
    • Un-Health Services (Apdex):Apdex性能指标,即服务的不健康值,1为满分,Apdex是根据设定的阈值和响应时间综合考虑的衡量标准,是满意响应时间和不满意响应时间相对于总响应时间的比率,衡量的是用户对服务的满意程度,因为传统的指标(如平均响应时间)可能很快就会容易形成偏差。
    • Slow Endpoints:慢接口平均响应耗时排序,单位ms
    • Global Response Latency:响应时间百分比,不同百分比的延时时间,单位ms。percentile 标签含义,例如 p99 为 3500ms,意味着 99% 的请求应该比 3500ms 更快
    • Global Heatmap:服务响应时间热力分布图,根据时间段内不同响应时间的数量显示颜色深度, 颜色越深,请求越多。

    (2)Service(服务)维度:

    • Service Apdex 数字:Apdex性能指标
    • Service Apdex 折线图:一段时间的Apdex分数
    • Service Avg Response Time:服务平均响应时间
    • Service Response Time Percentile:百分比响应延时
    • Successful Rate(%)数字:请求成功率
    • Successful Rate(%)折线图:一段时间的请求成功率
    • Service Load(CPM - calls per minute):每分钟调用数
    • Service Load(CPM - calls per minute):一段时间的每分钟调用数
    • Service Instances Load(CPM - calls per minute):每个实例每分钟请求数
    • Slow Service Instance:每个服务实例平均延时topN
    • Service Instance Successful Rate:服务实例的请求成功率 topN

     (3)Instance(实例)维度:

    • Service Instance Load:实例每分钟调用数
    • Service Instance Successful Rate:实例调用成功比率
    • Service Instance Latency:实例响应延时
    • JVM CPU(Java Service):JVM 占用 CPU 百分比
    • JVM Memory (Java Service):JVM内存占用大小,包含四个指标 instance_jvm_memory_heap(堆内存使用)、instance_jvm_memory_heap_max(最大堆内存)、instance_jvm_memory_noheap(直接内存当前使用)、instance_jvm_memory_noheap_max(最大直接内存)
    • JVM GC Time:JVM垃圾回收时间,包含 young gc 和 old gc
    • JVM GC Count:JVM垃圾回收次数,包含 young gc count 和 old gc count

    (4)Endpoint(API)维度:

    • Endpoint Load in Current Service:每个API每分钟请求数
    • Slow Endpoints in Current Service:平均响应时间的最慢的topN个API
    • Successful Rate in Current Service:每个API的请求成功率
    • Endpoint Load:当前API每个时间段的请求数据
    • Endpoint Avg Response Time:当前API每个时间段的平均响应时间
    • Endpoint Response Time Percentile:当前API每个时间段的响应时间占
    • Endpoint Successful Rate:当前API每个时间段的请求成功率

    3.1.2、Database(数据库):

    • Database Avg Response Time:当前数据库平均响应时间
    • Database Access Successful Rate:当前数据库访问成功率
    • Database Traffic:当前数据库每分钟请求数
    • Database Access Latency Percentile:数据库不同响应时间占比
    • Slow Statements:当前数据库慢查询TopN
    • All Database Loads:所有数据库中请求量排序
    • Un-Health Databases:所有数据库不健康排名,请求成功率排名,失败最多的请求在最上。

    3.2、拓扑图:

            拓扑图可以很直观地展示服务与服务之间的依赖关系,这对于我们进行服务梳理是非常有帮助的,并且支持自定义分组,如下图所示,就将 ai-search、social-search、social-scan 三个服务自定义一个分组,并通过拓扑图很直观地展示出三者间的依赖关系:

            除此之外,拓扑图还能查看服务运行信息进行度量,包括开发框架类型、服务平均响应时间、吞吐量、百分比响应、Apdex分值、SLA值等

    3.3、链路追踪:

            链路追踪可以查看每个接口的调用链,每个链路耗时、状态,如果为失败,还会展示错误信息,如果是数据库也会展示查询语句,如果是Redis还会展示操作指令,另外可以根据追踪id(trace id)进行筛选查询:

    查看数据库操作详情:

    查看Redis缓存操作详情:

    3.4、性能剖析:

            Skywalking 在性能剖析方面非常强大,提供到基于堆栈的分析结果,能够让开发人员一看看出调用过程中各个步骤所消耗的时间,以便进行有针对性的进行优化。

            性能剖析通过新建任务,对不同端点进行采样,提供更详细的报告,比如比链路追踪多了线程栈的信息、慢方法提示等等内容。接下来我们就介绍下怎么进行性能剖析:

    (1)新建任务:

    在 性能剖析模块 -> 新建任务 -> 选择服务、填写端点、监控时间,操作如下图:

    备注:每个服务,相同时间只能添加一个任务,且添加的任务不能更改也不能删除,只能等待过期后自动删除

    (2)执行请求:

    多次访问 "/api/searchByWholeOcr" 接口,然后选择这个任务将会出现监控到的数据,如下图:

    备注:需要连续执行多次请求,因为存在采用设置。如果执行次数少,可能不会出现采样数据,也就无法进行分析了

    (3)性能剖析:

            上图可以看出,”/api/searchByWholeOcr“ 接口耗费了681ms,通过分析详细堆栈信息,我们可以看到耗时最多的操作就是SearchServiceImpl 类的 executeSearchRequest()方法,耗费了563ms,主要是调用 ES 做了全文搜索,如下图所示:

    展开全文
  • 以上虽然主要以SkyWalking为例来介绍链路追踪系统,但是并不是说其他链路追踪系统一点不适用。具体选择什么样的,大家可按实际场景灵活选择。 作者:猿话 来源:https://www.toutiao.com/i6884571378981274123/ ...
    此文转载自:https://my.oschina.net/u/4196605/blog/4721563

    公众号关注 “ 杰哥的IT之旅 ”,

    选择“ 星标 ”, 重磅干货,第一 时间送达!

    在分布式系统,尤其是微服务系统中,一次外部请求往往需要内部多个模块,多个中间件,多台机器的相互调用才能完成。在这一系列的调用中,可能有些是串行的,而有些是并行的。在这种情况下,我们如何才能确定这整个请求调用了哪些应用?哪些模块?哪些节点?以及它们的先后顺序和各部分的性能如何呢?

    这就是涉及到链路追踪。

    什么是链路追踪?

    链路追踪是分布式系统下的一个概念,它的目的就是要解决上面所提出的问题,也就是将一次分布式请求还原成调用链路,将一次分布式请求的调用情况集中展示,比如,各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

    链路追踪的原理

    衡量一个接口,我们一般会看三个指标:

    1、接口的 RT(Route-Target)你怎么知道?
    2、接口是否有异常响应?
    3、接口请求慢在哪里?

    1、单体架构时代

    在创业初期,我们的系统一般是单体架构,如下:

    对于单体架构,我们可以使用 AOP(切面编程)来统计这三个指标,如下:

    使用 AOP(切面编程),对原本的逻辑代码侵入更少,我们只需要在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间。另外,使用 AOP(切面编程)来捕获异常也可知道是哪里的调用导致的异常。

    2、微服务架构

    随着业务的快速发展,单体架构越来越不能满足需要,我们的系统慢慢会朝微服务架构发展,如下:

    在微服务架构下,当有用户反馈某个页面很慢时,虽然我们知道这个请求可能的调用链是 A -----> C -----> B -----> D,但服务这么多,而且每个服务都有好几台机器,怎么知道问题具体出在哪个服务?哪台机器呢?

    这也是微服务这种架构下的几个痛点:

    1、排查问题难度大,周期长
    2、特定场景难复现
    3、系统性能瓶颈分析较难

    分布式调用链就是为了解决以上几个问题而生,它主要的作用如下:

    1、自动采取数据
    2、分析数据,产生完整调用链:有了请求的完整调用链,问题有很大概率可复现
    3、数据可视化:每个组件的性能可视化,能帮助我们很好地定位系统的瓶颈,及时找出问题所在

    通过分布式追踪系统,我们能很好地定位请求的每条具体请求链路,从而轻易地实现请求链路追踪,进而定位和分析每个模块的性能瓶颈。

    3、分布式调用链标准(OpenTracing)

    OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。它的出现是为了解决不同的分布式追踪系统 API 不兼容的问题。

    OpenTracing 通过提供与平台和厂商无关的 API,使得开发人员能够方便地添加追踪系统,就像单体架构下的AOP(切面编程)一样。

    说到这里,大家是否想过 Java 中类似的实现?还记得 JDBC 吧?JDBC 就是通过提供一套标准的接口让各个厂商去实现,程序员即可面对接口编程,不用关心具体的实现。这里的接口其实就是标准。所以,制定一套标准非常重要,可以实现组件的可插拔。

    OpenTracing 的数据模型,主要有以下三个:

    • Trace:一个完整请求链路

    • Span:一次调用过程(需要有开始时间和结束时间)

    • SpanContext:Trace 的全局上下文信息,如里面有traceId

    为了让大家更好地理解这三个概念,我特意画了一张图:

    如图所示,一次下单的完整请求就是一个 Trace。TraceId是这个请求的全局标识。内部的每一次调用就称为一个 Span,每个 Span 都要带上全局的 TraceId,这样才可把全局 TraceId 与每个调用关联起来。这个 TraceId 是通过 SpanContext 传输的,既然要传输,显然都要遵循协议来调用。如图所示,如果我们把传输协议比作车,把 SpanContext 比作货,把 Span 比作路应该会更好理解一些。

    理解了这三个概念,接下来我们就看看分布式追踪系统是如何采集图中的微服务调用链。

    我们可以看到底层有一个 Collector 一直在默默无闻地收集数据,那么每一次调用 Collector 会收集哪些信息呢。

    1、全局 trace_id:这是显然的,这样才能把每一个子调用与最初的请求关联起来
    2、span_id: 图中的 0,1,1.1,2,这样就能标识是哪一个调用
    3、parent_span_id:比如 b 调用 d 的 span_id 是 1.1,那么它的 parent_span_id 即为 a 调用 b 的 span_id 即 1,这样才能把两个紧邻的调用关联起来。

    有了这些信息,Collector 收集的每次调用的信息如下:

    根据这些图表信息显然可以据此来画出调用链的可视化视图如下:

    于是一个完整的分布式追踪系统就实现了。

    以上实现看起来确实简单,但有以下几个问题需要我们仔细思考一下:

    1、怎么自动采集 span 数据:自动采集,对业务代码无侵入
    2、如何跨进程传递 context
    3、traceId 如何保证全局唯一
    4、请求量这么多采集会不会影响性能

    接下来,我们来看看链路追踪系统 SkyWalking 是如何解决以上四个问题的。

    链路追踪系统SkyWalking的原理

    1、怎么自动采集 span 数据

    SkyWalking 采用了插件化 + javaagent 的形式来实现了 span 数据的自动采集,这样可以做到对代码的无侵入性。插件化意味着可插拔,扩展性好。如下图所示:

    2、如何跨进程传递 context

    我们知道数据一般分为 header 和 body,就像 http 有 header 和 body,RocketMQ 也有 MessageHeader,Message Body。body 一般放着业务数据,所以不宜在 body 中传递 context,应该在 header 中传递 context,如图所示:

    dubbo 中的 attachment 就相当于 header,所以我们把 context 放在 attachment 中,这样就解决了 context 的传递问题。

    3、traceId 如何保证全局唯一

    要保证全局唯一 ,我们可以采用分布式或者本地生成的 ID。使用分布式的话,需要有一个发号器,每次请求都要先请求一下发号器,会有一次网络调用的开销。所以 SkyWalking 最终采用了本地生成 ID 的方式,它采用了大名鼎鼎的 snowflow 算法,性能很高。

    不过 snowflake 算法有一个众所周知的问题:时间回拨,这个问题可能会导致生成的 id 重复。那么 SkyWalking 是如何解决时间回拨问题的呢。

    每生成一个 id,都会记录一下生成 id 的时间(lastTimestamp),如果发现当前时间比上一次生成 id 的时间(lastTimestamp)还小,那说明发生了时间回拨,此时会生成一个随机数来作为 traceId。这里可能就有同学要较真了,可能会觉得生成的这个随机数也会和已生成的全局 id 重复,是否再加一层校验会好点。

    这里要说一下系统设计上的方案取舍问题了,首先如果针对产生的这个随机数作唯一性校验无疑会多一层调用,会有一定的性能损耗,但其实时间回拨发生的概率很小(发生之后由于机器时间紊乱,业务会受到很大影响,所以机器时间的调整必然要慎之又慎),再加上生成的随机数重合的概率也很小,综合考虑这里确实没有必要再加一层全局唯一性校验。对于技术方案的选型,一定要避免过度设计,过犹不及。

    4、请求量这么多,全部采集会不会影响性能?

    如果对每个请求调用都采集,那毫无疑问数据量会非常大,但反过来想一下,是否真的有必要对每个请求都采集呢?其实没有必要,我们可以设置采样频率,只采样部分数据,SkyWalking 默认设置了 3 秒采样 3 次,其余请求不采样,如图所示:

    这样的采样频率其实足够我们分析组件的性能了,按 3 秒采样 3 次,这样的频率来采样数据会有啥问题呢。理想情况下,每个服务调用都在同一个时间点,这样的话每次都在同一时间点采样确实没问题。如下图所示:

    但在生产上,每次服务调用基本不可能都在同一时间点调用,因为期间有网络调用延时等,实际调用情况很可能是下图这样:

    这样的话就会导致某些调用在服务 A 上被采样了,在服务 B,C 上不被采样,也就没法分析调用链的性能。

    那么 SkyWalking 是如何解决的呢?

    它是这样解决的:如果上游有携带 Context 过来(说明上游采样了),则下游将强制采集数据,这样可以保证链路完整。

    SkyWalking 的基础架构

    SkyWalking 的基础如下架构,可以说几乎所有的的分布式调用都是由以下几个组件组成的。

    首先当然是节点数据的定时采样,采样后将数据定时上报,将其存储到 ES, MySQL 等持久化层,有了数据自然而然可根据数据做可视化分析。

    SkyWalking 的性能如何

    如下是官方的测评数据:

    图中蓝色代表未使用 SkyWalking 的表现,橙色代表使用了 SkyWalking 的表现,以上是在 TPS 为 5000 的情况下测出的数据,可以看出,不论是 CPU,内存,还是响应时间,使用 SkyWalking 带来的性能损耗几乎可以忽略不计。

    接下来我们再来看 SkyWalking 与另一款业界比较知名的分布式追踪工具 Zipkin、Pinpoint 的对比(在采样率为 1 秒 1 个,线程数 500,请求总数为 5000 的情况下做的对比)。

    可以看到在关键的响应时间上, Zipkin(117ms),PinPoint(201ms)远逊于 SkyWalking(22ms)!从性能损耗这个指标上看,SkyWalking 完胜!

    再看下另一个指标:对代码的侵入性如何。

    ZipKin 是需要在应用程序中埋点的,对代码的侵入强,而 SkyWalking 采用 javaagent + 插件化这种修改字节码的方式可以做到对代码无任何侵入。除了性能和对代码的侵入性上 SkyWaking 表现不错外,它还有以下优势几个优势:

    • 对多语言的支持,组件丰富:目前其支持 Java、 .Net Core、PHP、NodeJS、Golang、LUA 语言,组件上也支持dubbo, mysql 等常见组件,大部分能满足我们的需求。

    • 扩展性:对于不满足的插件,我们按照 SkyWalking 的规则手动写一个即可,新实现的插件对代码无入侵。

    以上虽然主要以SkyWalking为例来介绍链路追踪系统,但是并不是说其他链路追踪系统一点不适用。具体选择什么样的,大家可按实际场景灵活选择。

    作者:猿话 

    来源:https://www.toutiao.com/i6884571378981274123/


    如果您觉得这篇文章对您有点用的话,麻烦您为本文来个四连:转发分享、点赞、点在看、留言,因为这将是我写作与分享更多优质文章的最强动力!


    本公众号全部博文已整理成一个目录,请在公众号后台回复「 m」获取!

     

    推荐阅读:

    1、 成为架构师,必须掌握 10 种常见的架构模式!
    2、 程序员必知的 7 种软件架构模式
    3、 一文读懂「分布式架构」
    4、 Linux 经典的几款收包引擎
    5、 最全 VxLAN 知识详解
    6、 什么是堡垒机?为什么需要堡垒机?

    关注微信公众号「 杰哥的IT之旅」,后台回复「 1024」查看更多内容,回复「 加群备注:地区-职业方向-昵称 即可加入读者交流群。

    点个[在看],是对杰哥最大的支持!

    本文分享自微信公众号 - 杰哥的IT之旅(Jake_Internet)。
    如有侵权,请联系 support@oschina.cn 删除。
    本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

    展开全文
  • 一、为什么要用链路追踪? 1.1 因:拆分服务单元 微服务架构其实是一个分布式的架构,按照业务划分成了多个服务单元。 由于服务单元的数量是很多的,有可能几千个,而且业务也会更复杂,如果出现了错误和异常,很难...
  • 微服务链路追踪

    2022-01-06 15:47:58
    Sleuth概述2.1 相关概念2.2 链路追踪Sleuth入门3. Zipkin的概述3.1 Zipkin Server的部署和配置3.2 客户端Zipkin+Sleuth整合3.3 zipkin 数据持久化3.4 基于消息中间件收集数据3.5 客户端配置 1. 微服务架构下的问题 ...
  • 分布式链路追踪

    千次阅读 2022-04-04 10:37:55
    为了提高系统的可见性观察,分布式链路追踪被提了出来,并迅速发展。 背景 分布式体系的构建是以“拆”为核心,其目标是职责分明、高度自治。不同的模块甚至会由不同的团队负责,用不同的语言编写。当我们想要组合...
  • 轻量级分布式链路追踪系统设计与实现,杨鑫,赵天忠,随着互联网技术的高速发展,以往单应用的服务架构已经很难处理如井喷式增长的信息数据,随着云计算技术的大规模应用,以微服务、
  • 阿里云第一届云原生编程挑战赛(分布式统计和过滤的链路追踪) 排名:116/4404 参照赛题方给的Demo思路做的一个extend版本,在正式赛的时候排名50左右,但在最终赛由于换了一组数据并且没有给出运行日志,没有找到错误...
  • 阿里云链路追踪服务全面支持SkyWalking.pdf 个人收集电子书,仅用学习使用,不可用于商业用途,如有版权问题,请联系删除!
  • 微服务-链路追踪

    2021-02-01 17:12:22
    文章目录微服务-链路追踪Sleuth+Zipkin1.打印日志2.聚合日志Zipkin3.持久化数据4.化数据采集RabbitMQSkywalking 微服务-链路追踪 通过链路追踪,可以记录请求在整个调用链路的日志信息、对应用性能进行监控、显示...
  • 服务链路追踪:Spring Cloud Sleuth 我们知道,微服务之间通过网络进行通信,但在我们提供服务的同时,不能保证网络一定是畅通的。相反地,网络是很脆弱的,网络资源也有限,因此我们有必要追踪每个网络请求,了解它们...
  • ▲点击上方“分布式实验室”关注公众号回复“1”抽取纸质技术书—1—为什么需要链路追踪在学习分布式链路追踪之前,我们需要先理解这项技术产生的背景,以及它能够帮我们解决哪些棘手问题。提到...
  • 全网最全的Skywalking链路追踪

    千次阅读 2022-03-11 17:16:36
    写在前面:笔者发现目前关于Skywalking的内容很是零散,没有成型的内容,笔者在项目中使用到...请求链路追踪 服务监控只要能满足这三个要素,基本就能实现我们想要的监控效果,我们来看看为什么服务监控需要满足这
  • 本文以 Dapper 论文为切入点,延伸到其相关的论文内容,结合历史时间线发展的线索,给读者展示出软件从业者对链路追踪技术的探索和实践。 带着疑问看历史 提起链路追踪,大部分人都会想起 Zipkin、Jaeger、...
  • 调用链路变得复杂,一条调用链路变多条,且每一条链路都可能发生延迟或错误,这种场景下,一旦出现问题,排查起来将会是一个噩梦。为了解决这个问题,分布式系统调用跟踪应运而生。 目前业界分布式服务跟踪的理论...
  • 为了解决这个问题,基础架构智能运维团队自研链路追踪系统,将海量 Metrics/Trace/Log 数据进行整合与统一,并在此基础上实现了新一代的一站式全链路观测诊断平台,帮助业务解决监控排障、链路梳理、性能分析等问题...
  • 链路追踪详讲

    2021-07-30 22:21:44
    什么是链路追踪 分布式链路追踪(Distributed Tracing),也叫 分布式链路跟踪,分布式跟踪,分布式追踪 等等。 本文使用分布式Trace来简称分布式链路追踪。 trace就犹如一张大的json表,同一层级的数据代表同一层级...
  • Skywalking 链路追踪

    千次阅读 2021-01-20 14:03:44
    Skywalking 链路追踪 Skywalking 根据官方的解释,Skywalking是一个可观测性平台(Observability Analysis Platform简称 OAP)和应用性能管理系统(Application Performance Management 简称 APM)。提供分布式链路...
  • 异构系统链路追踪——滴滴 trace 实践.pdf
  • 链路追踪是微服务中排查的利器,用一个 TraceId 就可以串起整个调用链路的所有环节,对排查一些生产问题帮助很大。但是目前公司自研的链路追踪系统因为资源限制,数据处理延迟很严重。本篇文章分享实习期间对链路...
  • 一、先抛两个常见的问题 微服务调用链路出现了问题怎么快速排查? 微服务调用链路耗时长怎么定位是哪个服务? 二、链路追踪系统是做什么的 ...注意:AlibabaCloud全家桶还没对应的链路追踪系统,我们使用S

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,390
精华内容 12,156
关键字:

链路追踪