多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
[TOC] ### 背景说明 ***** 前段时间对当前微服务中较流行的两款开源分布式tracing系统:Zipkin和Jaeger分别进行了调研。 **Zipkin**([github](https://github.com/openzipkin/zipkin),[homepage](https://zipkin.io/)),是一款由[java](http://www.codercto.com/category/java.html)开发的分布式追踪系统。在微服务架构下,它用于帮助收集排查潜在问题的时序数据,同时管理数据收集和数据查询。 **Jaeger**([github](https://github.com/jaegertracing/jaeger),[homepage](https://jaegertracing.io/)),则是受Dapper和OpenZipkin启发,由Uber使用golang开发的分布式跟踪系统。由于我们项目的技术栈为golang,所以重点调研了Jaeger并在此列出。 ` ` ### OpenTracing ***** 一句话总结,[OpenTracing](http://opentracing.io/)是一套标准,它通过提供平台无关、厂商无关的API,使得开发人员能够方便的添加(或更换)追踪系统的实现(我们在测试使用中是基本上通过两行代码的更改就可以在Zipkin和Jaeger之间切换)。 当Zipkin和Jaeger,都是支持OpenTracing标准的。 ### Jaeger介绍 ***** Jaeger的完整的概览设计。从中我们会发现Jaeger有5个模块元素,如下所列出,接下来我们来分别解释这五个模块的作用: ``` 1.Jaeger-client 2.Agent 3.Collector 4.Data Store 5.UI ``` ### Jaeger 服务 ##### Agent(客户端代理) ***** jaeger的agent,是一个监听在 UDP 端口上接收 span 数据的网络守护进程。 如同大多数分布式系统都拥有一个Agent一样,Jaeger的Agent有以下几类特点: agent收集并汇聚这些span信息到collector; agent的被设计成一个基础组件,旨在**作为基础架构组件部署到所有**[**宿主机**](https://cloud.tencent.com/product/cdh?from=10680); agent将client library 和 collector 解耦,为 client library 屏蔽了路由和发现 collector 的细节; ##### Collector(数据收集处理) collector,顾名思义,从agent收集traces信息,并通过处理管道处理他们,再写入后端存储(backends)。  当前的collector工作主要是管理trace,建立索引,执行相关转换,并最终存储它们。 Collector中运行着sampling逻辑,根据我们设定的sampling方式对数据进行收集和处理。 ##### Data Store(数据存储) jaeger的data store是组件的方式。  当前可以支持 Cassandra和ElasticSearch(当然也支持纯内存方式,但是不适用于生产环境). ##### Query & UI(数据查询与前端界面展示) Query查询是一种从存储中检索trace,并提供UI以显示它们的服务。上图中就展示了一次Trace的数据流向,作为一次系统作用的数据传播/执行图,即可以在Jaeger UI上展示出来。 #### 部署Jaeger服务 ##### docker 方式 ``` docker run -d -e \ COLLECTOR_ZIPKIN_HTTP_PORT=9411 \ -p 5775:5775/udp \ -p 6831:6831/udp \ -p 6832:6832/udp \ -p 5778:5778 \ -p 16686:16686 \ -p 14268:14268 \ -p 9411:9411 \ jaegertracing/all-in-one:latest ```  一旦启动成功后,就可以去http://localhost:16686看到Jaeger UI了,如下所示: ![UTOOLS1586400317129.png](https://user-gold-cdn.xitu.io/2020/4/9/1715cd3cef5f62ea?w=1636&h=937&f=png&s=84578) 注:在All in one模式下,Data Store使用的是内存,因此若重启dockre容器后就看不到之前的数据了。所以,该模式仅可用于前期demo或者验证,不可在生产环境中这样部署。 ##### 独立部署 当然我们更推荐的方式是独立部署,独立部署也可以分为docker镜像方式和binary 方式,官网有详细的[docker镜像方式启动命令介绍](https://www.jaegertracing.io/docs/deployment/) 关于**binary**方式部署,可以参看github上的[Jaeger的二进制包](https://github.com/jaegertracing/jaeger/releases)。地址提供了mac、linux和windows的三大操作系统的binary包。以linux为例,解压后我们可以发现有以下几个bin包,分别清晰地对应了我们之前说的几个模块: ``` drwxrwxr-x 3 2000 2000 4.0K May 28 23:29 jaeger-ui-build -rwxrwxr-x 1 2000 2000 27M May 28 23:29 jaeger-standalone -rwxrwxr-x 1 2000 2000 22M May 28 23:29 jaeger-query -rwxrwxr-x 1 2000 2000 25M May 28 23:29 jaeger-collector -rwxrwxr-x 1 2000 2000 16M May 28 23:29 jaeger-agent ``` 注:Jaeger同时也提供可Kubernetes and OpenShift的模板。可参考github地址有详细介绍 ##### 端口说明 通过上述All in one启动方式,我们直接发现了Jaeger启动时占据了很多端口,当然,并不是所有的端口都是必需的,这儿简单列出这些端口的说明如下: ``` 端口 协议 所属模块 功能 5775 UDP agent 通过兼容性Thrift协议,接收Zipkin thrift类型数据 6831 UDP agent 通过兼容性Thrift协议,接收Jaeger thrift类型数据 6832 UDP agent 通过二进制Thrift协议,接收Jaeger thrift类型数据 5778 HTTP agent 配置控制服务接口 16686 HTTP query 客户端前端界面展示端口 14268 HTTP collector 接收客户端Zipkin thrift类型数据 14267 HTTP collector 接收客户端Jaeger thrift类型数据 9411 HTTP collector Zipkin兼容endpoint ```