0%

分布式监控系统zipkin介绍

zipkin是Twitter基于google的分布式监控系统Dapper(论文)的开发源实现,zipkin用于跟踪分布式服务之间的应用数据链路,分析处理延时,帮助我们改进系统的性能和定位故障。

zipkin架构

img

Instrumented client和Instrumented server是分布式系统中的服务,通过装备库采集跟踪信息,装备库再调用Transport,把跟踪信息发送给zipkin。

装备库

针对不同语言,不同RPC框架,有不同的装备库实现,目前已有实现列表见此,其中Brave是zipkin官方提供的Java的装备库。
一个装备库的实现需要考虑如下情况:

  • 实现语言,和需要装备的服务的语言一致
  • zipkin需要的核心数据结构信息记录,包括tracerid,spanid的生成,延迟时间的计算,事件记录,tag记录等
  • 服务之间跟踪信息的传递,称为植入,不同RPC接口植入的方式不一样,例如HTTP接口采用B3协议植入
    植入的信息包括:Trace Id、Span Id、Parent Id、Sampled、Flags
  • 采样,减少跟踪导致的系统负荷
  • 报告给zipkin,调用Transport将跟踪信息传给zipkin

Transport

Transport是zipkin对外提供的接口,目前有HTTP、Kafka、Scribe三种。

  • HTTP:采用json格式,接口定义见https://github.com/openzipkin/zipkin-api
  • Kafka:分布式发布订阅消息系统
  • Scribe:Facebook的日志收集系统https://github.com/facebook/scribe

核心数据结构

v2版本

  • traceId:64位或128位,全局唯一,
  • parentId:父spanid,64位,根span的parentId为空
  • id:spanid,64位,tranceId内唯一
  • name:方法名
  • serviceName:服务名
  • timestamp:自1970-1-1 00:00:00 UTC的微秒
  • duration:开始span到结束span的时间,单位微秒
  • annotations:记录事件,value有一些预定义的值,例如客户端发送(cs),客户端接收(cr),服务端接收(sr),服务端发送(ss)等
  • tags:记录附加数据

一个Span就是记录[remoteEndpoint.serviceName]服务的[Span.name]方法的执行过程,其中的annotation记录了中间的一些事件发生时间,通过这些时间可以得到[Span.name]方法的网络传输时间,服务端执行时间,客户端响应时间等信息,从而对其进行诊断优化。多个Span通过parentId构成一个树形结构,根Span的parentId为空,描述了一次trace(tranceId标识)中多个服务之间的调用过程。

示例说明

https://github.com/zhongpan/zipkin-ice

假设service1.fun1中调用service2.fun2和service3.fun3,service2.fun2中调用service4.fun4。本次跟踪各个服务中会创建如上的span1~span7,span1为根span。span2和span4为一次RPC的客户端和服务端行为,可以共享spanid,span4不用新生成spanid,span2和span4在zipkin中会合并为1个span,span3/span5以及span6/span7类似。最终,在zipkin界面展示的树形结构为:

-------------本文结束感谢您的阅读-------------