概述

zipkin为分布式链路调用监控系统，聚合各业务系统调用延迟数据，达到链路调用监控跟踪。

在复杂的调用链路中假设存在一条调用链路响应缓慢，如何定位其中延迟高的服务呢？

日志：通过分析调用链路上的每个服务日志得到结果
zipkin：使用zipkin的web UI可以一眼看出延迟高的服务

zipkin

zipkin主要涉及四个组件 collector storage search web UI

Collector接收各service传输的数据
Cassandra作为Storage的一种，也可以是mysql等，默认存储在内存中，配置cassandra可以参考这里
Query负责查询Storage中存储的数据,提供简单的JSON API获取数据，主要提供给web UI使用
Web 提供简单的web界面

使用zipkin涉及几个概念

1. Span:基本工作单元，一次链路调用(可以是RPC，DB等没有特定的限制)创建一个span，通过一个64位ID标识它，
span通过还有其他的数据，例如描述信息，时间戳，key-value对的(Annotation)tag信息，parent-id等,其中parent-id
可以表示span调用链路来源，通俗的理解span就是一次请求信息

2. Trace:类似于树结构的Span集合，表示一条调用链路，存在唯一标识

3. Annotation: 注解,用来记录请求特定事件相关信息(例如时间)，通常包含四个注解信息

cs - Client Start,表示客户端发起请求
sr - Server Receive,表示服务端收到请求
ss - Server Send,表示服务端完成处理，并将结果发送给客户端
cr - Client Received,表示客户端获取到服务端返回信息

4. BinaryAnnotation:提供一些额外信息，一般已key-value对出现

完整的调用链路

上图表示一请求链路，一条链路通过Trace Id唯一标识，Span标识发起的请求信息，各span通过parent id 关联起来，如图

整个链路的依赖关系如下:

完成链路调用的记录后，如何来计算调用的延迟呢，这就需要利用Annotation信息

sr-cs 得到请求发出延迟ss-sr 得到服务端处理延迟cr-cs 得到真个链路完成延迟

Span细节图

注意，上图并没有显示Span的所有细节（比如name和binaryAnnotation等），但这并不影响我们分析问题。

上图的①和⑥是一次完整的RPC调用，它发生在服务器0和服务器1之间，显而易见的是，用于描述该RPC调用的Span的spanId是1000，所以，这是同一个Span的，只是它的数据来源于两台不同的服务器（应用）：服务器0和服务器1。

往低层说，该Span由两条跟踪日志表示，一条在服务器0上被采集，另一条在服务器1上被采集，他们的Span的traceId、spanId和parentSpanId都是一样的！而且该Span将成为跟踪树中的顶节点，因为他们的parentSpanId为null。

对于步骤①来说，服务器1上的sr减去服务器0上的cs的时间就是约等于网络耗时（这里忽略不同服务器时钟的差异），同理，对于其他步骤，sr-cs和cr-ss得到的都是网络耗时。

我们接着看请求步骤②和④，从跟踪树的层次来说他们属于①下的子调用，所以它们的parentSpanId就是①的1000。步骤②和④都会分别产生一个spanId（上面的1001和1002），所以如上图，看似一次简单的RPC过程，其实共产生了6条Span日志，它们将在Zipkin服务端组装成3个Span。

google dapper论文中文: https://blog.csdn.net/yangzishiw/article/details/79402084

(4条消息) zipkin

概述

相关推荐