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

Span 基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)

Trace 一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace

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

原理说明

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

采集上报原理简析
数据采集时序图

配置使用

监控采集端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