SkyWalking
本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。采用java探针，字节码增强的基本原理
Zipkin
twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。可进行多种存储方式进行支持，并且可进行扩展开发，制定对应监控的服务链路以及采样率。采用拦截请求，发送（HTTP，mq）数据至zipkin服务。
Pinpoint
韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。采用ava探针，字节码增强的基本原理
接入方式：
类别 Zipkin Pinpoint SkyWalking
接入方式 基于linkerd或者sleuth方式，引入配置即可 javaagent字节码 javaagent字节码
agent到collector的协议 http,MQ thrift gRPC
OpenTracing √ × √
使用情况分析：
类别 Zipkin Pinpoint SkyWalking
颗粒度 接口级 方法级 方法级
全局调用统计 × √ √
traceid查询 √ × √
报警 × √ √
JVM监控 × × √
应用展示友好度分析：
类别 Zipkin Pinpoint SkyWalking
友好与详细程度
功能简单，但是清晰，
可完成基本链路监视功能
功能丰富，应用清晰
链路监控能力丰富
功能比较丰富，应用清晰
完整的链路监控能力
存储支持：
Zipkin：ES，mysql,Cassandra,内存
Pinpoint：Hbase
SkyWalking：ES，H2
PinPoint和skyWalking支持的插件对比
类别 Pinpoint SkyWalking
web容器 Tomcat6/7/8,Resin,Jetty,JBoss,Websphere Tomcat7/8/9,Resin,Jetty
JDBC Oracle,mysql Oracle,mysql,Sharding-JDBC
消息中间件 ActiveMQ, RabbitMQ RocketMQ 4.x,Kafka
日志 log4j, Logback log4j,log4j2, Logback
HTTP库 Apache HTTP Client, GoogleHttpClient, OkHttpClient Apache HTTP Client, OkHttpClient,Feign
Spring体系 spring,springboot spring,springboot,eureka,hystrix
RPC框架 Dubbo,Thrift Dubbo,Motan,gRPC,ServiceComb
NOSQL Memcached, Redis, CASSANDRA Memcached, Redis
性能分析：
摘自：https://juejin.im/post/5a7a9e0af265da4e914b46f1
以上三种全链路监控方案需要对比的项提炼出来：
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明，容易开关
添加新功能而无需修改代码，容易启用或者禁用。
完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构
比较关注探针的性能，毕竟APM定位还是工具，如果启用了链路监控组建后，直接导致吞吐量降低过半，那也是不能接受的。对skywalking、zipkin、pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。
选用了一个常见的基于Spring的应用程序，他包含Spring Boot, Spring MVC，redis客户端，mysql。 监控这个应用程序，每个trace，探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边基本和 skywalkingtest 的测试应用差不多。
模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：
从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。
