Spring Cloud Sleuth + zipkin 实现服务追踪

服务追踪

Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案,通过使用Sleuth可以让我们快速定位某个服务的问题。

官方文档地址如下:

http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.0.1.RELEASE/single/spring-cloud-sleuth.html

一些概念:

  1. Span,Span是基本的工作单元。Span包括一个64位的唯一ID,一个64位trace码,描述信息,时间戳事件,key-value 注解(tags),span处理者的ID(通常为IP)。
    最开始的初始Span称为根span,此span中span id和 trace id值相同。
  2. Trance,包含一系列的span,它们组成了一个树型结构
  3. Annotation,用于及时记录存在的事件。常用的Annotation如下:
    • cs - Client Sent:客户端发送一个请求,表示span的开始
    • sr - Server Received:服务端接收请求并开始处理它。(sr-cs)等于网络的延迟
    • ss - Server Sent:服务端处理请求完成,开始返回结束给服务端。(sr-ss)表示服务端处理请求的时间
    • cr - Client Received:客户端完成接受返回结果,此时span结束。(cr-cs)表示客户端接收服务端数据的时间

如果一个服务的调用关系如下:

那么此时将Span和Trace在一个系统中使用Zipkin注解的过程图形化如下:

每个颜色的表明一个span(总计7个spans,从A到G),每个span有类似的信息

Trace Id = X
Span Id = D
Client Sent

此span表示span的Trance Id是X,Span Id是D,同时它发送一个Client Sent事件

spans 的parent/child关系图形化如下:



了解完基本的一些概念后,我们来在订单服务和商品服务中,集成spring cloud sleuth以及zipkin。在两个服务的pom.xml文件中,增加如下依赖:

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

为了更详细的查看服务通信时的日志信息,我们将openfeign的日志级别设置为debug。在两个项目的配置文件中,加入如下内容即可:

logging:
  level:
    org.springframework.cloud.openfeign: debug

启动订单、商品服务项目,然后访问创建订单的接口,订单服务的控制台会输出一段这样的信息:

[order,6c8ecdeefb0fc723,cc4109a6e8e56d1c,false]

商品服务的控制台也会输出类似的信息,如下:

[product,6c8ecdeefb0fc723,40cdc34e745d59e7,false]

说明:

  • product: 看也知道是服务名称
  • 6c8ecdeefb0fc723: 是TranceId,一条链路中,只有一个TranceId
  • 40cdc34e745d59e7:则是spanId,链路中的基本工作单元id
  • false:表示是否将数据输出到其他服务,true则会把信息输出到其他可视化的服务上观察

通过这些信息,我们可以得知服务的链路,但是控制台始终是不太方便查看。所以我们需要一个图形化的工具,这时候就轮到zipkin出场了。

zipkin官网地址如下:

https://zipkin.io/

zipkin结构图:

我们需要搭建zipkin服务器,我这里拿了一台线上的服务做实验,使用docker安装的zipkin,安装过程如下:

[[email protected] ~]# docker run -d -p 9411:9411 openzipkin/zipkin
Unable to find image ‘openzipkin/zipkin:latest‘ locally
latest: Pulling from openzipkin/zipkin
ff3a5c916c92: Pull complete
a8906544047d: Pull complete
590b87a38029: Pull complete
5a45314016bd: Pull complete
747e7e2c6558: Pull complete
d010e5d815f5: Pull complete
Digest: sha256:e130f6191ce6763f59250c44ca9a265ff9eca4c4b9a22c240403a8103123227e
Status: Downloaded newer image for openzipkin/zipkin:latest
e1fd796bc74175543ffce538b44cffcb013e75008acbc4248b4ec373a49df97f
[[email protected] ~]#

安装好后,使用浏览器访问9411端口,主页面如下所示:

然后在订单服务中将之前的sleuth依赖替换成如下依赖:

<!-- 这个依赖包含了sleuth和zipkin -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

在配置文件中,增加zipkin相关的配置项。如下:

spring:
  ...
  zipkin:
    base-url: http://xxx.xx.xxx.xx:9411/  # zipkin服务器的地址
    sender:
      type: web  # 设置使用http的方式传输数据
  sleuth:
    sampler:
      probability: 1  # 设置抽样采集为100%,默认为0.1,即10%      

配置好后重启项目,并访问创建订单接口。下单成功后,到zipkin页面上就可以查看到order服务的链路信息了:

会有红色的信息表示有错误,点击上图中的红色信息后,可以进入到服务链路的查看页面,在这里可以看到整条服务链路,并且可以看到每一个服务调用的耗时,也可以看到是哪一步调用发生了错误:

点击每一行信息都可以查看其详情信息,例如我点击耗时46.236ms的那行信息,其详细信息如下:

原文地址:http://blog.51cto.com/zero01/2173394

时间: 2024-09-30 21:57:46

Spring Cloud Sleuth + zipkin 实现服务追踪的相关文章

【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

全链路spring cloud sleuth+zipkin

http://blog.csdn.net/qq_15138455/article/details/72956232 版权声明:@入江之鲸 一.About ZipKin please google 二. Demo Scene 三. Result Display 四.Prepare 1.soft version kafka:2.10-0.10.2.0zokeeper:3.4.10elasticsearch:5.2.2jdk:1.8spring boot:1.5.3.RELEASEsprign clo

springcloud --- spring cloud sleuth和zipkin日志管理(spring boot 2.18)

前言 在spring cloud分布式架构中,系统被拆分成了许多个服务单元,业务复杂性提高.如果出现了异常情况,很难定位到错误位置,所以需要实现分布式链路追踪,跟进一个请求有哪些服务参与,参与的顺序如何,从而去明确一个问题. spring cloud sleuth 通常来说,一个分布式服务跟踪系统主要由三部分:数据收集.数据存储和数据展示. 对于大规模的分布式系统来说,数据存储可分为实时数据和全量数据两部分.实时数据用来排查故障,全量数据用于系统优化:数据展示涉及数据挖掘和分析. 名词解释 服务

浅尝Spring Cloud Sleuth

Spring Cloud Sleuth提供了分布式追踪(distributed tracing)的一个解决方案.其基本思路是在服务调用的请求和响应中加入ID,标明上下游请求的关系.利用这些信息,可以方便地分析服务调用链路和服务间的依赖关系. Only Sleuth 在Spring Tool Suite的文件菜单中,点击新建Spring Starter Project. 在请求处理方法内加上一行日志代码. import org.slf4j.Logger; import org.slf4j.Logg

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们

业余草 SpringCloud教程 | 第九篇: 服务链路追踪(Spring Cloud Sleuth)(Finchley版本)

这篇文章主要讲述服务追踪组件zipkin,Spring Cloud Sleuth集成了zipkin组件. 一.简介 Add sleuth to the classpath of a Spring Boot application (see below for Maven and Gradle examples), and you will see the correlation data being collected in logs, as long as you are logging re

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

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

Distributed traceability with Spring Cloud: Sleuth and Zipkin

I. Sleuth 0. Concept Trace A set of spans that form a call tree structure, forms the trace of the request. Span It is the basic unit of work, for example a call to a service. They are identified with a span ID and a trace ID to which span is owned. T