Zipkin简介

Zipkin是 Twitter 的一个 开源项目 ,它基于 Google Dapper实现。我们可以使用它来收集各个 服务器 上请求链路的跟踪数据,并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向 开发 的API接口之外,它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。

上图展示了Zipkin的基础架构,它主要有4个核心组件构成:

  • Collector:收集器组件,它主要用于处理从外部系统发送过来的跟踪信息,将这些信息转换为Zipkin内部处理的Span格式,以支持后续的存储、分析、展示等功能。
  • Storage:存储组件,它主要对处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,我们也可以修改此存储策略,通过使用其他存储组件将跟踪信息存储到 数据库 中。
  • RESTful API:API组件,它主要用来提供外部访问接口。比如给客户端展示跟踪信息,或是外接系统访问以实现监控等。
  • Web UI:UI组件,基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息。

HTTP收集

在 Spring Cloud Sleuth 中对Zipkin的整合进行了 自动化 配置 的封装,所以我们可以很轻松的引入和使用它,下面我们来详细介绍一下 Sleuth 与Zipkin的基础整合过程。主要分为两步:

第一步:搭建Zipkin Server

创建一个基础的 Spring Boot 应用,命名为 zipkin -server,并在 pom .xml中引入Zipkin Server的相关依赖,具体如下:

  1. <parent> 

  2.   <groupId>org.springframework.boot</groupId> 

  3.   <artifactId>spring-boot-starter-parent</artifactId> 

  4.   <version>1.5.10.RELEASE</version> 

  5.   <relativePath/> 

  6. </parent> 

  7. <dependencies> 

  8.   <dependency> 

  9.     <groupId>io.zipkin.java</groupId> 

  10.     <artifactId>zipkin-server</artifactId> 

  11.   </dependency> 

  12.   <dependency> 

  13.     <groupId>io.zipkin.java</groupId> 

  14.     <artifactId>zipkin-autoconfigure-ui</artifactId> 

  15.   </dependency> 

  16. </dependencies> 

  17. <dependencyManagement> 

  18.   <dependencies> 

  19.     <dependency> 

  20.         <groupId>org.springframework.cloud</groupId> 

  21.         <artifactId>spring-cloud-dependencies</artifactId> 

  22.         <version>Dalston.SR5</version> 

  23.         <type>pom</type> 

  24.         <scope>import</scope> 

  25.     </dependency> 

  26.   </dependencies> 

  27. </dependencyManagement> 

  • 创建应用主类Zipkin App li cat ion,使用@EnableZipkinServer注解来启动Zipkin Server,具体如下:
  1. @EnableZipkinServer 

  2. @SpringBootApplication 

  3. public class ZipkinApplication { 

  4.  

  5.   public static void main(String[] args) { 

  6.     SpringApplication.run(ZipkinApplication.class, args); 

  7.   } 

  8.  

  • 在application.properties中做一些简单配置,比如:设置 服务端 口号为9411(客户端整合时候,自动化配置会连接9411 端口 ,所以在服务端设置了端口为9411的话,客户端可以省去这个配置)。
  1. spring.application.name=zipkin-server 

  2. server.port=9411 

创建完上述工程之后,我们将其启动起来,并访问 http ://localhost:9411/,我们可以看到如下图所示的Zipkin管理页面:

第二步:为应用引入和配置Zipkin服务

在完成了Zipkin Server的搭建之后,我们还需要对应用做一些配置,以实现将跟踪信息输出到Zipkin Server。我们以之前实现的trace-1和trace-2为例,对它们做以下改造内容:

  • 在trace-1和trace-2的pom.xml中引入spring-cloud-sleuth-zipkin依赖,具体如下所示。
  1. <dependency> 

  2.   <groupId>org.springframework.cloud</groupId> 

  3.   <artifactId>spring-cloud-sleuth-zipkin</artifactId> 

  4. </dependency> 

  • 在trace-1和trace-2的application.properties中增加Zipkin Server的配置信息,具体如下所示(如果在zip-server应用中,我们将其端口设置为9411,并且均在本地 调试 的话,该 参数 也可以不配置,因为默认值就是http://localhost:9411)。
spring.zipkin.base-url=http://localhost:9411 

测试 与分析

到这里我们已经完成了接入Zipkin Server的所有基本工作,我们可以继续将eureka-server、trace-1和trace-2启动起来,然后我们做一些测试实验,以对它的运行机制有一些初步的理解。

我们先来向trace-1的接口发送几个请求:http://localhost:9101/trace-1,当我们在日志中出现跟踪信息的最后一个值为true的时候,说明该跟踪信息会输出给Zipkin Server,所以此时我们可以去Zipkin Server的管理页面中选择合适的查询条件后,点击Find Traces,就可以查询出刚才在日志中出现的跟踪信息了(也可以根据日志中的Trace ID,在页面的右上角输入框中来搜索),具体如下页面所示:

点击下方trace-1端点的跟踪信息,我们还可以得到Sleuth收集到的跟踪到详细信息,其中包括了我们关注的请求时间消耗等。

点击导航栏中的Dependencies菜单,我们还可以查看Zipkin Server根据跟踪信息分析生成的系统请求链路依赖关系图:

消息中间件收集

Spring Cloud Sleuth在整合Zipkin时,不仅实现了以HTTP的方式收集跟踪信息,还实现了通过消息中间件来对跟踪信息进行异步收集的封装。通过结合Spring Cloud Stream,我们可以非常轻松的让应用客户端将跟踪信息输出到消息中间件上,同时Zipkin服务端从消息中间件上异步地消费这些跟踪信息。

接下来,我们基于之前实现的trace-1和trace-2应用以及zipkin-server服务端做一些改造,以实现通过消息中间件来收集跟踪信息。改造的内容非常简单,只需要我们做项目依赖和配置文件做一些调整就能马上实现,下面我们分别对客户端和服务端的改造内容做详细说明:

第一步:修改客户端trace-1和trace-2

  • 为了让trace-1和trace-2在产生跟踪信息之后,能够将抽样记录输出到消息中间件中,我们除了需要之前引入的spring-cloud-starter-sleuth依赖之外,还需要引入zipkin对Spring Cloud Stream的扩展依赖spring-cloud-sleuth-stream以及基于Spring Cloud Stream实现的消息中间件绑定器依赖,以使用Rabbit MQ 为例,我们可以加入如下依赖:
  1. <dependency> 

  2.     <groupId>org.springframework.cloud</groupId> 

  3.     <artifactId>spring-cloud-sleuth-stream</artifactId> 

  4. </dependency> 

  5.  

  6. <dependency> 

  7.     <groupId>org.springframework.cloud</groupId> 

  8.     <artifactId>spring-cloud-starter-stream-rabbit</artifactId> 

  9. </dependency> 

  • 在application.properties配置中去掉HTTP方式实现时使用的spring.zipkin.base-url参数,并根据实际部署情况,增加消息中间件的相关配置,比如下面这些关于RabbitMQ的配置信息:
  1. spring.rabbitmq.host=localhost 

  2. spring.rabbitmq.port=5672 

  3. spring.rabbitmq.username=springcloud 

  4. spring.rabbitmq.password=123456 

第二步:修改zipkin-server服务端

为了让zipkin-server服务端能够从消息中间件中获取跟踪信息,我们只需要在pom.xml中引入针对消息中间件收集封装的服务端依赖spring-cloud-sleuth-zipkin-stream,同时为了支持具体使用的消息中间件,我们还需要引入针对消息中间件的绑定器实现,比如以使用RabbitMQ为例,我们可以在依赖中增加如下内容:

  1. <dependency> 

  2.     <groupId>org.springframework.cloud</groupId> 

  3.     <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId> 

  4. </dependency> 

  5.  

  6. <dependency> 

  7.     <groupId>org.springframework.cloud</groupId> 

  8.     <artifactId>spring-cloud-starter-stream-rabbit</artifactId> 

  9. </dependency> 

  10.  

  11. <dependency> 

  12.     <groupId>io.zipkin.java</groupId> 

  13.     <artifactId>zipkin-autoconfigure-ui</artifactId> 

  14. </dependency> 

其中,spring-cloud-sleuth-zipkin-stream依赖是实现从消息中间件收集跟踪信息的核心封装,其中包含了用于整合消息中间件的核心依赖、zipkin服务端的核心依赖、以及一些其他通常会被使用的依赖(比如:用于扩展数据存储的依赖、用于支持测试的依赖等)。但是,需要注意的是这个包里并没有引入zipkin的前端依赖zipkin-autoconfigure-ui,为了方便使用,我们在这里也引用了它。

测试与分析

在完成了上述改造内容之后,我们继续将eureka-server、trace-1和trace-2、zipkin-server都启动起来,同时确保RabbitMQ也处于运行状态。此时,我们可以在RabbitMQ的控制页面中看到一个名为sleuth的交换器,它就是zipkin的消息中间件收集器实现使用的默认主题。

最后,我们使用之前的验证方法,通过向trace-1的接口发送几个请求:http://localhost:9101/trace-1,当有被抽样收集的跟踪信息时(调试时我们可以设置AlwaysSampler抽样机制来让每个跟踪信息都被收集),我们可以在RabbitMQ的控制页面中发现有消息被发送到了sleuth交换器中,同时我们再到zipkin服务端的Web页面中也能够搜索到相应的跟踪信息,那么我们使用消息中间件来收集跟踪信息的任务到这里就完成了。

springcloud+zipkin实现链路监控搭建zipkin-server(五)相关推荐

  1. 实现一个全链路监控平台很难吗?Pinpoint、skywalking、zipkin,哪个实现比较好?...

    点击上方蓝色"方志朋",选择"设为星标"回复"666"获取独家整理的学习资料! 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往 ...

  2. 实现全链路监控平台很难吗?Pinpoint、SkyWalking、Zipkin 选型对比

    随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现.有可能布在了 ...

  3. 微服务项目中引入全链路监控平台:Pinpoint、SkyWalking、Zipkin怎么选?

    来源:www.jianshu.com/p/92a12de11f18 0 问题背景 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上, ...

  4. 牛逼哄哄的全链路监控系统!搭建起来也没有想象中的那么难啊...

    点击关注公众号,回复"1024"获取2TB学习资源! 问题背景 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上 ...

  5. 一文搞懂全链路监控:方案概述与比较 | 干货

    原文标题为<全链路监控(一):方案概述与比较>,作者陶邦仁,链接:https://www.jianshu.com/p/92a12de11f18 0 - 问题背景 随着微服务架构的流行,服务 ...

  6. 全链路监控细节和难点剖析!

    点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料!原文 | https://www.jianshu.com/p ...

  7. 主流微服务全链路监控系统之战

    点击上方蓝色"方志朋",选择"设为星标"回复"666"获取独家整理的学习资料!问题背景随着微服务架构的流行,服务按照不同的维度进行拆分,一次 ...

  8. 实现一个全链路监控平台很难吗?一点都不难。。。

    0 问题背景 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现 ...

  9. 一文搞懂全链路监控:方案概述与比较!

    作者:陶邦仁 https://www.jianshu.com/p/92a12de11f18 0 - 问题背景 随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务.互联网应 ...

最新文章

  1. 统计学习方法笔记 -- 概论
  2. web前端之JavaScript
  3. egret 开发总结
  4. 计算机网络基础期中测试题,计算机网络基础期末考试试题
  5. git安装与配置_git 安装及基本配置
  6. 关于async和await的探讨
  7. spring支持的事务管理
  8. Python str 函数 - Python零基础入门教程
  9. 晒2012年度十大杰出IT博客 奖品
  10. Metal Framework基础使用教程
  11. C++ 不能重载的运算符
  12. Linux Framebuffer驱动剖析之中的一个—软件需求
  13. Android源码模块编译
  14. zabbix agent报错 :cannot connect to [[127.0.0.1]:10051]: [111] Connection refused
  15. redis 实战面试
  16. 程序员一般可以从什么平台接私活?
  17. [BFS]愿天下有情人都是失散多年的兄妹
  18. 数据结构课程设计项目2:校园导游咨询-预习报告
  19. android 监控行为,一种针对Android系统App行为的监控方法
  20. 关于create-react-app搭建react环境并修改端口号

热门文章

  1. qq游戏大厅2015官方下载正式版 v3.6 免费版​
  2. 浏览器的 5 种 Observer,你用过几种?
  3. Android最新版本号与API级别对应关系
  4. sp3 win xp 符号表_windows xp sp3下载|windows xp下载「xp系统」-太平洋下载中心
  5. Arrays类常见方法
  6. IP地址,netmask 子网掩码、gateway 默认网关,dns-nameserve域名服务器总结
  7. ECUG 演讲分享 | 刘奇:Chaos Engineering at PingCAP
  8. 一直在构建版本_升级成2.0版本的自己,生活会有什么不一样
  9. https证书沒有生效,vpn访问证书生效
  10. 面向对象之继承-5种JavaScript继承的方法