分布式链路追踪(Sleuth、Zipkin)

技术背景

在微服务架构中,随着业务发展,系统拆分导致系统调用链路愈发复杂,一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成,那么当整个请求出现问题时,我们很难得知到底是哪个服务出了问题导致的,这时就需要解决一个问题,如何快速定位服务故障点,于是,分布式系统调用链追踪技术就此诞生了。

ZipKin

Zipkin 是一个由Twitter公司提供并开放源代码分布式的跟踪系统,它可以帮助收集服务的时间数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。

每个服务向zipkin报告定时数据,zipkin会根据调用关系通过Zipkin UI生成依赖关系图,展示了多少跟踪请求经过了哪些服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如用户每次请求服务的处理时间等,可非常方便的监测系统中存在的瓶颈。

Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra以及Elasticsearch。我们可以跟根据需求选择不同的存储方式,生成环境一般都需要持久化。我们这里采用elasticsearch作为zipkin的数据存储器。

Spring Cloud Sleuth

一般而言,一个分布式服务追踪系统,主要有三部分组成:数据收集、数据存储和数据展示。

Spring Cloud Sleuth为服务之间的调用提供链路追踪,通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外,Sleuth还可以帮助我们:

耗时分析: 通过Sleuth可以很方便的了解到每个采样请求的耗时,从而分析出哪些服务调用比较耗时。

可视化错误: 对于程序未捕捉的异常,可以通过集成Zipkin服务界面上看到。

链路优化: 对于调用比较频繁的服务,可以针对这些服务实施一些优化措施。

spring cloud sleuth可以结合zipkin,将信息发送到zipkin,利用zipkin的存储来存储信息,利用zipkin ui来展示数据。

实现案例

在早前的Spring Cloud版本里是需要自建zipkin服务端的,但是从SpringCloud2.0 以后,官方已经不支持自建Server了,改成提供编译好的jar包供用户使用。 
因为我用的是2.0以后的版本,自建Servcer的方式请自行百度。这里我们是使用docker方式部署zipkin服务,并采用elasticsearch作为zipkin的数据存储器。

下载镜像

此前请先安装好docker环境,使用以下命令分别拉取zipkin和elasticsearch镜像。

docker pull openzipkin/zipkin
docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.0

通过 docker images 查看下载镜像。

编写启动文件

创建如下文件夹结构。

dockerfile
    |- elasticsearch
    |    |- data
    |- docker-compose.yml

docker-compose.yml

version: "3"
services:

  elasticsearch:
    image:  docker.elastic.co/elasticsearch/elasticsearch:6.3.0
    container_name: elasticsearch
    restart: always
    networks:
      - elk
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
       - ../elasticsearch/data:/usr/share/elasticsearch/data

  zipkin:
    image: openzipkin/zipkin:latest
    container_name: zipkin
    restart: always
    networks:
      - elk
    ports:
      - "9411:9411"
    environment:
      - STORAGE_TYPE=elasticsearch
      - ES_HOSTS=elasticsearch

networks:
    elk:

关于docker-compose.yml 文件格式及相关内容请自行百度了解。

启动服务

命令模式进入dockerfile目录,执行启动命令如下。

docker-compose up -d

执行过程如下图所示。

执行完成之后,通过 docker ps 命令查看,发现zipkin和elasticsearch确实启动起来了。

到这里,zipkin服务端就搭建起来了,访问 http://localhost:9411,效果如下,因为还没有客户端,所以还没有数据。

zipkin服务端已经搭建完成了,接下来我们来实现客户端。

添加依赖

修改 spring-cloud-consul-consumer 项目Maven配置,添加zipkin依赖。

pom.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

添加配置

修改配置文件,添加如下zipkin配置。

spring:
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1 #样本采集量,默认为0.1,为了测试这里修改为1,正式环境一般使用默认值。

application.yml

测试效果

先后启动注册中心、服务提供者、服务消费者。

反复访问几次 http://localhost:8521/ribbon/call,产生zipkin数据。

再次访问 http://localhost:9411, 发现出现了我们刚刚访问的服务,选择并点击追踪。

点击追踪之后,页面显示了相关的服务调用信息。

点击调用记录查看详情页面,可以看到每一个服务所耗费的时间和顺序。

原文地址:https://www.cnblogs.com/7788IT/p/10667173.html

时间: 2024-07-31 16:45:00

分布式链路追踪(Sleuth、Zipkin)的相关文章

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

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

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

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

基于zipkin分布式链路追踪系统预研第一篇

分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scribe(Facebook开源的日志传输通路)或

zipkin分布式链路追踪系统

基于zipkin分布式链路追踪系统预研第一篇 分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scr

个推基于 Zipkin 的分布式链路追踪实践

作者:个推应用平台基础架构高级研发工程师 阿飞 01业务背景 随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能. 单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户. 而在微服务架构中,一个请求往往需要多个模块共同协作处理,不同模块可能还依赖于不同的外部存储,各个模块的实现技术还不尽相同,

spring cloud 分布式链路跟踪(集成zipkin)

篇写了分布式链路追踪  spring cloud 分布式链路追踪 这样的链路追踪虽然可以解决问题 但日志太过于分散 如果微服务过多 就会变的相当复杂 zipkin就可以帮我们把链路调用的过程全部收集起来 它就像注册中心一样 分为客户端和服务端 想要使用 首先建一个模块 当作他的服务端 首先添加如下依赖 compile 'io.zipkin.java:zipkin-server' compile 'io.zipkin.java:zipkin-autoconfigure-ui' 在配置文件中配置它的

分布式链路追踪系统预研第二篇

本文为博主原创文章,未经博主允许不得转载. 在上篇随笔后,分布式链路在缓慢推进.一直没什么兴致写,zipkin使用elasticsearch作为数据完全是可行的.但是揉合这两者,就存在两种方案: 第一种,保持zipkin,替换掉存储.即保持zipkin架构,替换掉默认数据存储,改用elasticsearch作为存储.这完全是可行的,但是做出来的也仅仅是一个分布式链路追踪系统.zipkin官方有相应的多数据源的实现源码,有兴趣大家可以自行去git上看. 由于我们想要的不只是分布式链路追踪系统,我们

聊聊分布式链路追踪

原文链接:http://lidawn.github.io/2018/12/26/distribute-tracing/ 起因 最近一直在做分布式链路追踪的调研和实践,整理一下其中的知识点. 什么是链路追踪 分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务.分布式数据库.分布式缓存等,使得后台服务构成了一种复杂的分布式网络.在服务能力提升的同时,复杂的网络结构也使问题定位更加困难.在一个请求在经过诸多服务过程中,出现了某一个调用失败的情况,查询具体的异常由哪一个服务引起的就变得十分

Laravel + go-micro + grpc 实践基于 Zipkin 的分布式链路追踪系统 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

分布式调用链跟踪系统,属于监控系统的一类.系统架构逐步演进时,后期形态往往是一个平台由很多不同的服务.组件构成,用户请求过来后,可能会经过其中多个服务,如图 不过,出问题时往往很难排查,如整个请求变慢.偶尔报错.不可用等,我们很难得知具体是由哪一个或哪些服务引起的,通常开发同学都会互相甩锅,最后不得不花大量时间人肉 tracing 项目初期时,可以简单处理,通过生成唯一 request_id ,在各个方法记录日志,方便排查问题.中后期系统拆分为各个子服务时,要么继续推进原有的 request_i