应用系统在测试或生产运行过程当中，可能常常遇到这样的场景：mysql
- “某服务挂了，报错信息看不出个因此然来，坐等大佬救场”
- “某个请求响应速度很慢，要查到是哪里卡壳了须要一层层往下查”
- “只懂得监控服务器的资源指标，遇到问题时依旧啥也不是”
- “系统老是时不时抽风下，还能再抢救一下吗？。。。”
特别是在当下流行的分布式服务系统中，若是出现性能问题，面对N台的硬件服务器和10N级的服务（容器），从何处下手自己就已是个难题了。web
那么，接下来给你们介绍分布式服务的APM监控工具，Pinpoint。redis
【适合读者】：开发、测试、运维等。sql
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服务器加上权限验证再进行转发等；
若是你们有其余不一样意见或见解，欢迎留言讨论。