APM监控之Pinpoint使用心得

Posted 2020-12-21

应用系统在测试或生产运行过程中，可能经常遇到这样的场景：

1. “某服务挂了，报错信息看不出个所以然来，坐等大佬救场”
2. “某个请求响应速度很慢，要查到是哪里卡壳了需要一层层往下查”
3. “只懂得监控服务器的资源指标，遇到问题时依旧啥也不是”
4. “系统总是时不时抽风下，还能再抢救一下吗？。。。”

特别是在当下流行的分布式服务系统中，如果出现性能问题，面对N台的硬件服务器和10N级的服务（容器），从何处下手本身就已经是个难题了。

那么，接下来给大家介绍分布式服务的APM监控工具，Pinpoint。

【适合读者】：开发、测试、运维等。

APM, 全称Application Performance Management，划重点，与性能有关！

已经有很多文章专门对比了各种APM工具之间的优劣，比如还有当下流行的skywalking、zipkin等，这里我就不再赘述，想了解更多的自己百度。

继续我们的主题，看看Pinpoint能给我们带来什么？
首先上个总体图：

从这个图我们可以得到这些信息：
1.系统的总体架构组成部分，比如图中可以看到应用服务与mysql、redis、第三方服务之间的请求情况；
2.系统/节点的响应速度情况，以及成功失败的请求次数等；

pinpoint的默认跟踪粒度确实是比较详细的，可以看到单次请求在整个服务链路各节点上的详细耗时情况，比如在这里，可以很清楚地看到是哪个节点哪个方法消耗了最多的时间。

再来个图，大家从这个图可以看出这个系统当前的性能瓶颈在哪吗？

除了可以跟踪服务链路耗时情况，pinpoint还可以监控JVM、线程池、数据库连接池、句柄等等的使用情况，来几个高能大图。

这里能看到数据库连接池的最大连接数和当前连接数，对于判断数据库连接池数够不够用，能起到很好的参考作用，一目了然。

Pinpoint除了上述常规用法，还可以用于跟踪异常错误，比如上面第一张图，在请求异常失败的情况下，pinpoint会以红色标识，点开也就可以看到出现异常失败的节点和方法位置，以及具体的错误信息。

同样地，因为Pinpoint详细地记录了请求的链路信息，把请求过程中具体的SQL语句都展示出来了，这样对于排查问题，甚至监控SQL语句的执行速度，都可以起到很好的帮助作用，很惊喜有没有！

总结一下，pinpoint可以给我们带来以下好处:

1. 掌握系统的整体响应速度情况，对系统运行情况心里有底；
2. 掌握各节点的响应速度情况，比如第三方服务接口，redis，mysql等；
3. 单次请求的具体服务链路耗时情况，定位性能瓶颈；
4. 单次请求的具体服务链路请求信息，对于排查问题能提供帮助；
5. 监控各服务的JVM、线程池、数据库连接池使用情况，想象一下，如果分布式服务系统中有几十甚至几百个服务节点，要如何来监控每个节点的JVM呢？

总体来说，在pinpoint这类APM监控工具逐渐发展成熟的当下，引入这类工具，对我们日常的开发测试运维工作，是能起到不错的辅助作用的，尤其是在分布式服务系统中，如果没有这类工具，遇到问题时难免慌手慌脚无从下手。

关于是否要在生产环境上部署这类APM监控工具，这里说几点供参考：

1. APM监控一定不可以影响业务系统的运行成败，换句话说就是即使APM监控挂了，业务系统也应该能够照常运行着。不要因为引入APM监控，而给整套系统引入了一颗不定时炸弹，这样就得不偿失了。在一点上,pinpoint应该是OK的，我试过pinpoint服务端即使挂了，业务系统照样能跑得好好的；
2. APM监控是会消耗服务器的资源的，监控粒度越细，消耗越多。在其他文章里人做了各种APM监控工具的性能损耗对比，pinpoint相对是损耗较多的，因为它的监控粒度算是比较细的。我也做过测试，开启pinpoint监控后，性能确实会有8%左右的损耗。但是换个角度来说，目前各种系统的线上环境，CPU等各类资源，经常都是在30%使用率以下运行的，这种情况下，即使再多个损耗10%也是在能接受范围内的；

3. 开源APM监控工具还要考虑安全问题，像pinpoint、skywalking这类工具目前好像还没有访问权限之类的控制，要注意不要被乱灌数据，或者被有不良企图的用户访问到各种请求链路详细信息。当然，这类安全问题也是有解决方案的，比如可以在路由防火墙上指定有权限的ip，或者通过web服务器加上权限验证再进行转发等；

   如果大家有其他不同意见或看法，欢迎留言讨论。