### SkyWalking 本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。采用java探针，字节码增强的基本原理 **优点**：功能比较全，UI比较好，性能损耗较少，主流中间件和数据库的监控基本都支持 **缺点**：es强在检索能力但存储能力偏弱 ### Zipkin twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。可进行多种存储方式进行支持，并且可进行扩展开发，制定对应监控的服务链路以及采样率。采用拦截请求，发送（HTTP，mq）数据至zipkin服务。 **优点**：与`spring-cloud`项目整合非常方便，而且支持以`spring-boot`的方式部署`zipkin-collector` **缺点**：功能比较少，而且有代码入侵(jar包和配置项) ### Pinpoint 韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。采用ava探针，字节码增强的基本原理 **优点**：功能比较全，UI比较好，而且调用链的跟踪粒度非常细，并且依靠HBase强大的存储能力适合日志量非常庞大的场景 **缺点**：由于采集信息太过详细所以对性能的损耗最大，并且HBase的维护代价有点大，需要有能力hold住一套HBase集群 ### 接入方式： |类别|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 ### 以上三种全链路监控方案需要对比的项提炼出来： 1、探针的性能 主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 2、collector的可扩展性 能够水平扩展以便支持大规模服务器集群。 3、全面的调用链路数据分析 提供代码级别的可见性以便轻松定位失败点和瓶颈。 4、对于开发透明，容易开关 添加新功能而无需修改代码，容易启用或者禁用。 5、完整的调用链应用拓扑 自动检测应用拓扑，帮助你搞清楚应用的架构 比较关注探针的性能，毕竟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%之内。