sleuth+zipkin链路监控原理分析和配置使用

2020-05-31 868 0

介绍

微服务架构中,服务之间的调用关系非常复杂,一个服务可能组合调用不同的微服务,调用过程中可能因为某个网络延迟高、出现异常错误等导致请求失败,为了方便快速排错和监控,需要一套服务追踪来进行管理。Spring Cloud Sleuth 提供了分布式服务链路监控的解决方案,我最近搭建此方案对项目进行了实践,带着对链路监控数据流及采集上报性能有担忧风风险,对框架深入进行了研究

基本说明

术语

详细参考:https://zipkin.io/pages/instrumenting.html

详细参考:https://github.com/openzipkin/zipkin-api/blob/master/thrift/zipkinCore.thrift

  1. Span 基本工作单元,例如,在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC,span通过一个64位ID唯一标识,trace以另一个64位ID表示,span还有其他数据信息,比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
  2. Trace 一系列spans组成的一个树状结构,例如,如果你正在跑一个分布式大数据工程,你可能需要创建一个trace
  3. Annotation 用来及时记录一个事件的存在,一些核心annotations用来定义一个请求的开始和结束
    • cs - Client Sent -客户端发起一个请求,这个annotion描述了这个span的开始
    • sr - Server Received -服务端获得请求并准备开始处理它,如果将其sr减去cs时间戳便可得到网络延迟
    • ss - Server Sent -注解表明请求处理的完成(当请求返回客户端),如果ss减去sr时间戳便可得到服务端需要的处理请求时间
    • cr - Client Received -表明span的结束,客户端成功接收到服务端的回复,如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

网络时间计算

  • sr-cs:网络延迟
  • ss-sr:逻辑处理时间
  • cr-cs:整个流程时间

zipkin-ui Annotations说明

  • Client Start 对应 Client Sent
  • Server Start 对应 Server Received
  • Client Finish 对应 Client Received
  • Server Finish 对应 Server Finish

    span下所有annotation的Relative Time为相对整个trance的开始时间,所以可以用这个相对时间来计算每个事件的间隔耗时

日志采样

合理配置采样规则能减少系统开销,同时在开发人员跟踪时调试可以增加强制采样header参数:X-B3-Flags设置为1 或 X-B3-Sampled设置为1

原理说明

花了一整天时间深入研究源码后,画了以下两个图记录下原理,觉得这个方案值得学习,对于以后工作中处理程序异步线程间队列缓冲数据交换时可以借鉴

  • 采集上报原理简析
    file

  • 数据采集时序图
    file

配置使用

  • 监控采集端pom依赖
<!--服务链路监控 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
  • 监控采集端参数配置

    spring:
    zipkin:
    #采集开关,线上请暂时关闭(请提入git配置文件中)
    enabled: true
    #日志中心地址(请提入git配置文件中)
    base-url: http://service-zipkin
    sleuth:
    sampler:
      #设置抽样采集为100%,默认为0.1,即10% 
      percentage: 1.0
  • 链路监控查询
    file

相关文章

轻量级微服务监控方案:Spring Boot Admin+Cloud+Nacos
SpringBoot插件化技术方案选型
PF4J ExtensionPoint核心原理与实战示例
DeepSeek 本地部署的尝试之旅
当Actuator失效时:Tomcat线程池监控的全面解决方案
版本号命名规范,为软件开发注入秩序

发布评论