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研发成本较高

 

 

效果图

 

 

 

 

 

 

 

为什么选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. 不足之处在于开发人员需按照标准来进行埋点

 

效果图

 

 

 

性能分析

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

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

具体实现方式见下一篇