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

  1. “这个模块的响应速度很慢,但是不知道为什么这么慢,具体慢在哪里?”
  2. “运维只有监控服务器的资源指标,单从服务器资源看不出为什么慢”
  3. “系统总是时不时抽风下,还能再抢救一下吗?。。。”
  4. “服务出错了,需要翻看下系统日志文件”

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

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

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

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

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

今天我们只谈,Pinpoint能给我们带来什么?
首先上个总体图
APM监控之Pinpoint使用心得

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

接下来我们来具体查看某个请求
APM监控之Pinpoint使用心得
pinpoint的跟踪粒度是比较详细的,可以看到整个服务链路各节点上的详细耗时情况,可以很清楚地看到是哪个节点哪个方法消耗了最多的时间。

再来个图,大家从这个图可以看出这个系统当前的性能瓶颈在哪吗?
APM监控之Pinpoint使用心得

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

APM监控之Pinpoint使用心得

APM监控之Pinpoint使用心得
这里能直接看到数据库连接池的最大连接数和当前连接数,对于判断数据库连接池数够不够用,一眼就能把它揪出来。

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

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

总结一下,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服务器加上权限验证再进行转发等;

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