由上表，根据代码侵入/非侵入选择了两款优者进行实验，最终选择了非入侵：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%之内。

具体实现方式见下一篇