Zipkin分布式任务追踪

zipkin简介
Zipkin 是一款开源的分布式实时数据追踪系统,由基于 Google Dapper 的论文设计而来,由 Twitter 公司提供开源实现,主要功能是聚集来自各个异构系统的实时监控数据,和微服务架构下的接口直接的调用链路和系统延时问题。


Zipkin 提供了自己的UI,应用将自己的监控数据报告给zipkin,由Zipkin 汇集并提供关联图展示,Zipkin可以追踪请求调用链路。Zipkin 以 Trace 的结构表示一次请求的追踪,又把每个Trace拆分为若干个有依赖关系的 Span,在微服务架构中,一次用户的请求可能会被后台的若干个服务处理,这完整的一次用户请求可以一条调用链路Trace,每个调用处理请求的服务可以理解为一个Span(如API服务),这个服务也可能继续调用其他的服务,因此形成一个Span的树形结构,以体现服务间的调用关系。

Zipkin 的用户界面除了可以查看 Span 的依赖关系之外,还以瀑布图的形式显示了每个 Span 的耗时情况,可以一目了然的看到各个服务的性能状况。打开每个 Span,还有更详细的数据以键值对的形式呈现,而且这些数据可以在装备应用的时候自行添加。
spring Cloud Sleuth是对Zipkin的一个封装,对于Span、Trace等信息的生成、接入HTTP Request,以及向Zipkin Server发送采集信息等全部自动完成。
Spring Cloud Sleuth的简介
以下是Spring Cloud Sleuth的概念图

在Spring Cloud Sleuth的封装中,Zipkin分为两端,一个是Zipkin服务端,一个是Zipkin客户端,客户端也就是微服务的应用, 客户端会配置服务端的url地址,一旦发生服务间的调用的时候,会被配置在微服务里面的Sleuth的监听器监听,并生成相应的 Trace 和 Span 信息写进http报文头里面,并同时向Zipkin服务端上传这些信息,如图所示。

主要方式有两种,一种是消息总线的方式如RabbitMq发送,还有一种是http报文的方式发送,向 Zipkin 服务端发送gzip的数据包,服务端接收到gzip的数据包进行解析,根据每个调用链路汇总成调用链路的信息,这里注意,每个 Zipkin Client 里面如果设置了登录验证,并不会影响Zipkin Server的信息收集,因为 Client 端会自动上传gzip的数据包给 Server 端,而无需 Server 端去调用 Client 端的接口去统计信息,Client 端在生成 Trace 统计信息的同时,如果配置了 MDC 或者在 logback 日志中集成了日志收集工具 logstash,则可以在 Client 端的控制台读到这些 Trace 和 Span 的信息,对每个 Span 的信息都会有对应的 Annotation 进行声明。
Span 的 Annotation 信息
这些 Annotation 分为四种类型:
cs : Client Sent,这个标识着 Span的开始。
sr : Server Received,这个标识着服务端接收到客户端发送请求的信息。Sleuth还可以根据 cs 和 sr 的时间戳来计算服务调用的延时。
ss : Server Sent,这个标识表示服务端接收到客户端后要返回 response 信息。
cr : Client Received,这个标识表示客户端收到服务端返回的 response 信息。


这几个注解反应了一次完整的服务间调用的信息,这些注解结合 Span id 信息可以从不同的应用汇总成调用链路的 Trace 信息,也就是说一次 Trace 的信息如果经过了 A 应用、B 应用,那么 Sleuth 会从 A 应用汇总对B应用调用产生的注解信息 Client Sent 和 Client Received,再从 B 应用汇总对 A 应用调用产生的 Server Received 和 Server Sent,A 应用根据自己调用信息组装成 Span 和携带相应的 Annotation 以gzip包的方式通过http发送给 Zipkin Server,B 应用像 A 应用一样也会组装这些信息给 Zipkin Server,Zipkin Server会根据 A 应用和 B 应用的信息汇总成统计信息展示在 Zipkin UI上。
Span的生命周期
start:开始对Span命名和记录开始时间戳
close:结束时记录结束时间戳并检查属性 exportable 然后汇总给 Zipkin,然后移除出当前的线程。
continue:为 Span 新建实例并拷贝继续进行的 Span
detach:Span 没有 stop 或者 close,仅仅是移出当前的线程。
create with explicit parent:在另外的一个线程重新创建一个 Span 并且明确它的 parent。

Span 的存储方式
在 Zipkin Server里面有很多种存储方式,但是比较主流的有这两种:
放在内存中存储。
放在mysql中存储。 放在内存中的随着服务端的启动会出清空历史数据,如果想持久化保留这些数据,可以选择 mysql 的方式存储。 mysql配置方式参考:Stack Overflow 网友提供的参考方案 mysql 配置后有两个表,如图


更多 zipkin 学习资料:
Spring Cloud Sleuth 官方文档
Github 上的 Zipkin 参考样例

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,444评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,421评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,036评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,363评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,460评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,502评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,511评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,280评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,736评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,014评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,190评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,848评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,531评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,159评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,411评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,067评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,078评论 2 352

推荐阅读更多精彩内容