APM-全链路追踪工具选型(基于java/php)

  pinpoint zipkin cat Skywalking Jaeger
OpenTracing兼容 不支持 支持 不支持 支持 支持
客户端支持语言 java/php Java/c#/go Java Java/.NET/NodeJs/php Java/c#/go/php/node
存储 Hbase es/mysql/cassandra/内存 mysql/hdfs ES,H2,mysql,TIDB,sharding sphere ES,kafka,Cassandra,内存
传输协议支持 thrift/tcp/udp http,MQ http udp/http udp/http
ui丰富程度
实现方式-代码侵入性 字节码注入,无代码侵入 拦截请求,代码侵入 拦截请求,代码侵入 字节码植入,无代码侵入 拦截请求,代码侵入
扩展性
trace查询 支持 不支持 不支持 支持 支持
告警支持 支持 不支持 支持 支持 不支持
jvm监控 支持 不支持 不支持 支持 不支持
性能损失
优点 1. 开发人员不需要修改代码 2. 可以收集到更多精确的数据因为有字节码中的更多信息 3.UI丰富,支持多种插件 1.轻量级,与springcloud sleuth很好的兼容 2.易于部署 功能完善 完全无侵入,界面完善,支持应用拓扑图及单个调用链查询。 功能比较完善(zipkin + pinpoint) 1.原生支持opentrcing,为CNCF认可的项目,前景很好 2.采样策略多样,可以控制服务器压力 3.存储维护成本低,易于扩展
缺点 1. 字节码增强技术让应用容易造成风险,增加bug发生的可能性 2. 需要更高能力的开发人员,可以立即识别需要跟踪的类库代码并决定跟踪点 3. 状态采集无策略可调,对应用资源的消耗比较大。 4.扩展编译耗时,并且php-agent端运行于容器内时无法进行域名解析及穿透容器(总体来说是针对php还不算太完善) 5.存储需引入hbase,不易于维护 1.需要埋点 1.对代码侵入性很大,集成成本较高 1.Bug较多 2.依赖较多 1.需要埋点
文档 完善 完善 杂而乱 完善 完善
开发者 naver twitter 大众点评 华为 Uber

 

由上表,根据代码侵入/非侵入选择了两款优者进行实验,最终选择了非入侵:pinpoint和入侵:jaeger

为什么选择pinpoint

对于非代码侵入的两款pinpoint/Skywalker根据上表可以看到后者bug比较多,依赖比较多;违背我们的快速上手,稳定运行的标准,遂选择pinpoint

组件

  • agent 客户端,php需要编译pinpoint扩展

  • collet 采集agent的状态信息

  • Hbase 存储数据

  • UI 读取数据,在页面进行展示

 

痛点

  • 扩展编译过程较慢,需在国外服务器内完成

  • 底层存储需要用Hbase,需要引入一个全新生态,维护成本较高

  • 采集策略无法按需调整,UI界面展示迟缓

  • 对应用的性能有影响(具体表现在吞吐下降较多),官方介绍仅有3%的影响

  • php-agent相关文档较少,且在容器中实现尚有问题待解决

 

优点

  • 无需开发人员介入完成

 

隐患

  • 由于使用的字节码植入的方式进行数据采集,可能会增加业务中Bug出现

  • 扩展性较低,如若需要采集定制性的数据,需要开发熟悉pinpoint这套字节植入逻辑

使用推荐指数(5分为满)

pinpoint的推荐分数为3分

  1. 针对php的相关功能及文档不完善

  2. Hadoop没有较好的容器实现方式,维护成本较高

  3. pinpoint目前仅支持java/php对于语言的扩展性不强,不支持opentrcing研发成本较高

 

 

效果图

APM-全链路追踪工具选型(基于java/php)_第1张图片

 

 

 

 

 

 

APM-全链路追踪工具选型(基于java/php)_第2张图片

APM-全链路追踪工具选型(基于java/php)_第3张图片

 

为什么选Jaeger

其实较比几款需要进行代码侵入的链路追踪工具,显然具有争夺之力的为zipkin和jaeger;但这两款功能基本相仿(存储/协议等),但随着当下jaeger的地位逐步提升被大众越来越多的关注,所以我们也选择热门进行实验(当然,它还是具备优势的,比如它原生支持opentrcing/采集策略的多样性,更重要的是支持php)

组件

  • agent Agent是一个网络守护进程,监听通过UDP发送过来的Span,它会将其批量发送给collector。按照设计,Agent要被部署到所有主机上,作为基础设施。Agent将collector和客户端之间的路由与发现机制抽象了出来

  • collector Collector从Jaeger Agent接收Trace,并通过一个处理管道对其进行处理。目前的管道会校验Trace、建立索引、执行转换并最终进行存储。存储是一个可插入的组件,现在支持Cassandra和elasticsearch

  • queryQuery 服务会从存储中检索Trace并通过UI界面进行展现,该UI界面通过React技术实现,其页面UI如下图所示,展现了一条Trace的详细信息。

  • 存储 jaeger采集到的数据必须存储到某个存储引擎,目前支持Cassandra和elasticsearch

 

痛点

  • 需要研发配合进行代码植入完成数据采集

  • 依赖requestid字段,同时依赖日志收集系统(同样要收集requestid字段)

  • 需要研发人员了解这方面的工作,且需持续跟踪

 

优点

  • 存储可采用ES,与日志收集系统共用一套,便于维护;目前es未能支持7.x,但已提pr正在增加其功能

  • 社区活跃,对标opentrcaing文档较丰富

 

隐患

  • 如在新功能添加时未进行埋点则无法采集状态数据,意味着需要开发人员需紧密跟踪

 

使用推荐指数(5分为满)

jaeger推荐分数为4.5分

  1. 维护成本低

  2. 趋于大众化的工具,基于统一接口展开工作,扩展性复用性强

  3. 不足之处在于开发人员需按照标准来进行埋点

 

效果图

 

 

APM-全链路追踪工具选型(基于java/php)_第4张图片

 

APM-全链路追踪工具选型(基于java/php)_第5张图片

性能分析

模拟了三种并发用户:500,750,1000。使用jmeter测试,每个线程发送30个请求,设置思考时间为10ms。使用的采样率为1,即100%,这边与生产可能有差别。pinpoint默认的采样率为20,即50%,通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来,一共有12种。下面看下汇总表:该部分内容摘于https://www.jianshu.com/p/0fbbf99a236e

APM-全链路追踪工具选型(基于java/php)_第6张图片

从上表可以看出,在三种链路监控组件中,skywalking的探针对吞吐量的影响最小,zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显,在500并发用户时,测试服务的吞吐量从1385降低到774,影响很大。然后再看下CPU和memory的影响,在内部服务器进行的压测,对CPU和memory的影响都差不多在10%之内。

具体实现方式见下一篇

你可能感兴趣的:(微服务,全链路追踪,APM)