标签：链路   table   功能   全面   jvm监控   request   EAP   肩膀   进一步   

随着pinpoint版本的迭代更新，这图上的结论有些已经过时了，比如pinpoint方面：
1.协议，最新2.1.0版本也是默认使用gRPC的；
2.TraceId查询，最新2.1.0版本也是支持的；
3.发布包，最新2.1.0版本同样也是采用jar包部署的；

所以，没有什么是一层不变的，唯一不变的应该是我们的学习热情和决心。

接着说我们今天具体要对比的内容：

1. UI比较

对于我这种有点颜控的人来说，pinpoint的UI看上去更加的美观、友好、方便，pinpoint确实胜skywalking好几分，来两张图，各位看官自己比较。

skywalking的这个仪表盘貌似还有个问题，我如何查看过去某段时间内性能的表现情况呢？只能看当前时间段的吗？

2.跟踪粒度

看完了外观，我们再来对比下它们各自的内功，毕竟这类工具是要干活的，光当花瓶没有用，关键时候得派的上用场才行。

同样，我们先上两张图，来看看pinpoint和skywalking的跟踪粒度如何。

可以看出pinpoint可以监控到每个链路过程的耗时情况，包括SQL执行耗时、第三方服务响应耗时等，甚至连SQL的变量参数都跟踪出来了。

而skywalking只监控到了接口耗时，并没有监控更多一点的链路耗时信息，有群友告知说skywalking能监控到方法级，但是需要侵入代码，在每个要跟踪的方法上面加注解，所以我直接放弃了，因为这样的代价实在太大了点。而且即使监控到方法级，也只能知道哪个方法慢了，方法下面可能还有数据库调用、第三方方法调用等，还是没法定位出真正的问题。所以skywalking这款APM监控工具，个人理解，更多地是用来监控接口响应耗时并提出告警，至于具体的性能问题嘛，只能通过其他手段再进一步定位了。

所以，在监控粒度上面，skywalking差pinpoint不是一点半点，这是差了好几个量级啊。

3. JVM监控

接下来我们再来对比下这类APM工具的另外一个非常好用的功能，监控JVM。

这边就简单罗列下它们都能监控到那些JVM指标：

从上面对比结果来看，pinpoint在JVM监控方面要更强大得多，比如对Thread、Open File Descriptor、Data Source的支持，尤其是Data Source，实在是太方便了，数据库连接池的使用情况一目了然。

而skywaling的唯一得分点，是支持GC指标的查看。

4. 性能损耗

既然pinpoint跟踪粒度比skywalking详细了好几个量级，那么对应地，它的性能损耗是否要大得多呢？翻看有些网友（比如下面参考链接）的测试结果，pinpoint的性能损耗可以达到50%左右，这也太恐怖了，但是根据官方宣传，它的性能损耗是在3%以内的，那么到底谁是靠谱的呢？

本人主要是从事性能压测工作的，平时都是开着APM在做压测的，并没有感觉会有很大的性能损耗，总体损耗应该在8%以内，并且性能测试结果指标还都蛮OK的，所以，对于性能损耗这块，我对pinpoint还是挺有信心的。贴个官方性能损耗说明

5. 总结

今天，我主要从UI、跟踪粒度、JVM监控这三个方面对pinpoint和skywalking做了个人使用体验上的对比，从对比结果来看，pinpoint无论在操作简便性还是性能问题定位上，还是要优胜于skywalking的。毕竟作为一款APM工具，能够更好更快更全面地发现性能问题，才是它们最大的价值所在。

也可能是我对skywalking了解的还太肤浅，还没发现skywalking真正的强大和美好。各位如果持有不同看法和意见的，欢迎留言探讨。

参考链接：https://www.jianshu.com/p/626cae6c0522

我也来对比下pinpoint和skyWalking

标签：链路   table   功能   全面   jvm监控   request   EAP   肩膀   进一步   

原文地址：https://blog.51cto.com/14437683/2552347