APM简介
APM全称Application Performance Management ,目前市面的系统基本都是参考Google的Dapper(大规模分布式系统的跟踪系统)来做的, 核心思想是在服务各节点彼此调用的时候,记录并传递一个应用级别的标记,这个标记可以用来关联各个服务节点之间的关系,最终形成一个分布式跟踪的服务调用链。
APM 要解决的问题
微服务架构下,服务按照不同的维度进行拆分,一次请求请求往往需要涉及到多个服务。尤其是大规模互联网应用,服务由不同的团队开发,用不同编程语言来实现、并部署在成千上万态几千台服务器上面。我们需要可以帮助我们理解系统行为和进行分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。
市面上的APM工具
Zipkin
由Twitter公司开源,开放源代码分布式的跟踪系统
Pinpoint
Pinpoint是一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪系统
Skywalking
国产的优秀APM组件,是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。
其他类似的组件还有美团点评的CAT,淘宝的鹰眼EgleEye。
APM链路监控组件的要求
探针的性能消耗
APM组件服务的影响对被监控的应用应该做到足够小。
代码的侵入性
监控工具对程序员来说最好是透明的, 有侵入性对程序员来说是非常不友好的,程序员需要额外理解监控组件,以及要放入的位置,如果忽略了就监控不到,而且可能还容易引起bug
可扩展性
能够支持的组件越多当然越好,或者能提供插件开发的API,对于一些没有北监控到的组件,应用开发者也可以自行扩展
数据的分析
数据的分析要快 ,分析的维度尽可能多,实时性要求很高,这样才能在生产环境下的异常状况做出快速反应,分析并解决问题
Zipkin 与Pinpoint
Zipkin
zipkin主要涉及几个组件:collector收集agent的数据,storage存储,web UI图形化界面,search查询Storage中存储的数据, 提供简单的JSON API获取数据。
Spring cloud 提供了 sleuth 方便集成到zipkin,在Spring cloud 的帮助下我们很快就可以搭建出zipkin的server 和client,
PinPonit
Pinpoint 主要由 3 个组件外加 Hbase 数据库构成,三个组件分别为:Agent、Collector 和 Web UI
PinPoint 与ZipKin比较
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明,容易开关
添加新功能而无需修改代码,容易启用或者禁用。
完整的调用链应用拓扑
自动检测应用拓扑,帮助你搞清楚应用的架构
探针的性能
网上有大神对skywalking、zipkin、pinpoint进行了压测,并与基线(未使用探针)的情况进行了对比。
大神模拟了三种并发用户:500,750,1000。使用jmeter测试,每个线程发送30个请求,设置思考时间为10ms,采样率为100%
在三种链路监控组件中,skywalking的探针对吞吐量的影响最小,zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显,在500并发用户时,测试服务的吞吐量从1385降低到774,影响很大。然后再看下CPU和memory的影响,大牛是在内部服务器进行的压测,对CPU和memory的影响都差不多在10%之内。
collector的可扩展性
zipkin
zipkin-agent与zipkin-Server通过http或者mq进行通信,通过基于mq异步方式通信,zipkin-Server通过订阅具体的topic进行消费。多个zipkin-Server实例进行异步消费mq中的监控信息。
PinPoint
pinpoint也是支持集群和单机部署,pinpoint agent通过thrift通信框架,发送链路信息到collector
全面的调用链路数据分析
zipkin
zipkin的链路监控粒度相对没有那么细,下图可以看到调用链中具体到接口级别,再进一步的调用信息不能看到
pinpoin
pinpoint数据分析相对完毕。提供代码级别的可见性以便轻松定位失败点和瓶颈,下图可以看到对于执行的sql语句,都进行了记录
对于开发透明,容易开关
Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能,但是它要求在需要时修改代码
pinpoint是基于字节码增强的方式,开发人员不需要修改代码,并且可以收集到更多精确的数据因为有字节码中的更多信息
完整的调用链应用拓扑
PinPoint的界面更加丰富,在这方面可以秒掉zipkin
其它方面
Pinpoint 是一个完整的性能监控解决方案:有从探针、收集器、存储到 Web 界面等全套体系;而 Zipkin 只侧重收集器和存储服务,虽然也有用户界面,但其功能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口,更强大的用户界面和系统集成能力,可以基于该接口二次开发实现。
Zipkin 官方提供有基于 Finagle 框架(Scala 语言)的接口,而其他框架的接口由社区贡献,目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架;但是 Pinpoint 目前只有官方提供的 Java Agent 探针。
Pinpoint 提供有 Java Agent 探针,通过字节码注入的方式实现调用拦截和数据收集,可以做到真正的代码无侵入,只需要在启动服务器的时候添加一些参数,就可以完成探针的部署;而 Zipkin 的 Java 接口实现 Brave,只提供了基本的操作 API,如果需要与框架或者项目集成的话,就需要手动添加配置文件或增加代码。
总结
对于我们来说Pinpoint 确实具有压倒性的优势;无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持;关于由于PinPoint采用的是字节码注入的方式导致接口开发困难度提高一个数量级,对于我们2B服务的互联网产品来说或许不是一个大问题,我们可以等一等,站在巨人的肩膀上,采取拿来主义的原则,而不是去自己实现一些接口,因为我们并不是走在互联网的前沿,所以很多问题走在前沿的开发人员会帮助我们解决,他们对于我们来说就是巨人。
Pinpoint实战演示效果
搭建一个java开源项目jforum,跑在tomcat下,使用jmeter进行压测,用户100个
服务器图(ServerMap)
通过可视化其组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关组件的详细信息,例如其当前状态和事务计数。
实时活动线程图(Realtime Active Thread Chart)
实时监视应用程序内的活动线程。
请求/响应散布图(Request/Response Scatter Chart)
可视化请求计数和响应模式,以确定潜在问题。可以通过在图表上拖动来选择事务以获取更多详细信息
调用栈信息(CallStack)
增强分布式环境中每个事务的代码级可见性,识别单个视图中的瓶颈和故障点。
检查器(Inspector)
查看应用程序的其他详细信息,如CPU使用率,内存/垃圾收集,TPS和JVM参数
Zipkin实战演示效果
调用栈信息(CallStack)
服务器图(ServerMap)
参考+引用+抄袭的文章
https://www.cnblogs.com/Bug-Hunter/p/8677435.html
http://www.herohuang.com/2017/03/01/apm-pinpoint/
https://sq.163yun.com/blog/article/168169689970475008
http://www.tangrui.net/2016/pinpoint-plugin-development.html
http://iamlile.github.io/2017/10/06/apm/
http://www.tangrui.net/2016/zipkin-vs-pinpoint.html
https://juejin.im/post/5a0579e6f265da4326524f0f
https://juejin.im/post/5a274614518825592c07f8b8