pinpoint mysql_APM监控之Pinpoint使用心得

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

“这个模块的响应速度很慢，但是不知道为什么这么慢，具体慢在哪里？”

“运维只有监控服务器的资源指标，单从服务器资源看不出为什么慢”

“系统总是时不时抽风下，还能再抢救一下吗？。。。”

“服务出错了，需要翻看下系统日志文件”

特别是分布式服务系统中，如果出现性能问题，面对N台的硬件服务器和10N级的服务(容器)，从何处下手就已经是个让人头疼的问题了。

接下来给大家介绍一款分布式服务监控工具，Pinpoint。

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

Pinpoint是一款APM工具，APM全称Application Performance Management，应用性能监控，顾名思义，跟性能有关！

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

今天我们只谈，Pinpoint能给我们带来什么？

首先上个总体图

从这个图我们可以得到这些信息：

1.系统的总体架构组成部分，比如图中可以看到应用服务与mysql、redis、第三方服务之间的请求统计情况；

2.系统和各节点的响应速度情况，以及成功失败的请求次数等；

接下来我们来具体查看某个请求

pinpoint的跟踪粒度是比较详细的，可以看到整个服务链路各节点上的详细耗时情况，可以很清楚地看到是哪个节点哪个方法消耗了最多的时间。

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

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

这里能直接看到数据库连接池的最大连接数和当前连接数，对于判断数据库连接池数够不够用，一眼就能把它揪出来。

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

另外，因为Pinpoint详细记录了请求的链路信息，把请求过程中具体的SQL语句都展示出来了，所以也可以用来帮助排查问题，或者监控SQL语句的执行速度，很惊喜有没有！

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

掌握系统的整体响应速度情况，对系统运行情况心里有底；

掌握各节点的响应速度情况，比如第三方服务接口，redis，mysql等；

单次请求的具体服务链路耗时情况，定位性能瓶颈；

单次请求的具体服务链路请求信息，对于排查问题能提供帮助；

监控各服务的JVM、线程池、数据库连接池使用情况，想象一下，如果分布式服务系统中有几十甚至几百个服务节点，要如何来监控每个节点的JVM呢？

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

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

APM监控一定不可以影响业务系统的运行成败，换句话说就是即使APM监控挂了，业务系统也应该能够照常运行着。不要因为引入APM监控，而给整套系统引入了一颗不定时炸弹，这样就得不偿失了。在这一点上，pinpoint应该是OK的，我测试过pinpoint服务端即使挂了，业务系统照样能跑得好好的；

APM监控是会消耗服务器的资源的，监控粒度越细，消耗越多。在其他文章里人做了各种APM监控工具的性能损耗对比，pinpoint相对是损耗较多的，因为它的监控粒度算是比较细的。我也做过测试，开启pinpoint监控后，性能确实会有8%左右的损耗。但是换个角度来说，目前各种系统的线上环境，CPU等各类资源，经常都是在30%使用率以下运行的，这种情况下，即使再多个损耗10%也是在能接受范围内的；

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

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