链接:https://www.zhihu.com/question/27994350/answer/118821214
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
通过跟踪请求的处理过程,来对应用系统在前后端处理、服务端调用的性能消耗进行跟踪,关于Dapper的介绍可以看这个链接:
Dapper,大规模分布式系统的跟踪系统 by bigbully
我所知道相对有名的APM系统主要有以下几个:
1、Pinpoint
github地址: GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.
对java领域的性能分析有兴趣的朋友都应该看看这个开源项目,这个是一个韩国团队开源出来的,通过JavaAgent的机制来做字节码代码植入,实现加入traceid和抓取性能数据的目的。
NewRelic、Oneapm之类的工具在java平台上的性能分析也是类似的机制。
2、SkyWalking
github地址: wu-sheng/sky-walking
这是国内一位叫吴晟的兄弟开源的,也是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统,在github上也有400多颗星了。
功能相对pinpoint还是稍弱一些,插件还没那么丰富,不过也很难得了。
3、Zipkin
官网: OpenZipkin · A distributed tracing system
github地址: GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system
这个是twitter开源出来的,也是参考Dapper的体系来做的。
Zipkin的java应用端是通过一个叫Brave的组件来实现对应用内部的性能分析数据采集。
Brave的github地址: https://github.com/openzipkin/brave
这个组件通过实现一系列的java拦截器,来做到对http/servlet请求、数据库访问的调用过程跟踪。
然后通过在spring之类的配置文件里加入这些拦截器,完成对java应用的性能数据采集。
4、CAT
github地址: GitHub - dianping/cat: Central Application Tracking
这个是大众点评开源出来的,实现的功能也还是蛮丰富的,国内也有一些公司在用了。
不过他实现跟踪的手段,是要在代码里硬编码写一些“埋点”,也就是侵入式的。
这样做有利有弊,好处是可以在自己需要的地方加埋点,比较有针对性;坏处是必须改动现有系统,很多开发团队不愿意。
5、Xhprof/Xhgui
这两个工具的组合,是针对PHP应用提供APM能力的工具,也是非侵入式的。
Xhprof github地址: GitHub - preinheimer/xhprof: XHGUI is a GUI for the XHProf PHP extension, using a database backend, and pretty graphs to make it easy to use and interpret.
Xhgui github地址: GitHub - perftools/xhgui: A graphical interface for XHProf data built on MongoDB
我对PHP不熟,不过网上介绍这两个工具的资料还是蛮多的。
前面三个工具里面,我推荐的顺序依次是Pinpoint—》Zipkin—》CAT。
原因很简单,就是这三个工具对于程序源代码和配置文件的侵入性,是依次递增的:
Pinpoint:基本不用修改源码和配置文件,只要在启动命令里指定javaagent参数即可,对于运维人员来讲最为方便;
Zipkin:需要对Spring、web.xml之类的配置文件做修改,相对麻烦一些;
CAT:因为需要修改源码设置埋点,因此基本不太可能由运维人员单独完成,而必须由开发人员的深度参与了,而很多开发人员是比较抗拒在代码中加入这些东西滴;
相对于传统的监控软件(Zabbix之流)的区别,APM跟关注在对于系统内部执行、系统间调用的性能瓶颈分析,这样更有利于定位到问题的具体原因,而不仅仅像传统监控软件一样只提供一些零散的监控点和指标,就算告警了也不知道问题是出在哪里。
第二个问题,则复杂一些
监控系统更多属于运维领域,当然,它会有一些性能管理的概念,但总体上来说,属于监控线上服务的一组技术和手段。我想对于监控系统的定义不会有什么疑问。 而对于APM,则需要理清一些概念问题。
在信息技术和系统管理等领域,应用性能管理(APM),是软件应用程序性能和可用性的监控和管理。 APM致力于检测和诊断应用性能问题,从而能提供预期的服务水平。
应用程序性能指标
有两组性能指标,第一组定义了应用程序终端用户的性能体验,一个很好的例子是在高峰时刻的平均响应时间。请注意这里有两个组成部分,负载和响应时间。负载是应用程序处理的业务量,如每秒事务数、每秒请求数、每秒PV。响应时间是指在给定的负载下,应用程序响应用户操作的时间。如果没有一定负载,绝大部分应用程序都足够快,这就是为什么程序员不太可能在开发过程中捕捉到性能问题。
第二组性能指标衡量了在一定负载下应用程序使用的计算资源,是否有足够的容量来支持给定的负载,在哪里可能有性能瓶颈。这些指标的测量为应用建立一个基于历史经验的性能基线。然后基线可以用来检测性能的变化。性能的变化可与外部事件相关联,并用于预测应用程序性能的未来变化。
使用APM最常见的领域是WEB应用。除了测量用户的响应时间,应用程序的组件的响应时间也可以被监控,以协助我们查明延迟的具体原因。
当前难点
APM已经演变成跨越许多不同的计算平台上的管理应用程序性能的一个概念。它的实现有两个挑战:
(1)很难通过仪表化应用程序来监视应用程序性能,尤其是应用程序的内部组件。
(2)应用程序可以被虚拟化,这增加了测量的变化性。分布式,虚拟和基于云的应用程序给应用性能监控带来一个独特的挑战,因为大部分关键的系统组件都不再位于同一台主机上。每个功能现在可能被设计成运行于多个虚拟系统上的一个因特网服务,应用程序本身也很可能会从一个系统迁移到另一个系统,以满足服务水平目标或者应对临时停电。
应用性能管理关注点应用程序本身正变得越来越难以管理,因为他们走向高度分散,多层次,多元素的构造,在很多情况下依赖于应用程序开发框架,如.NET或Java。
对于WEB性能管理,我们重点要关注的是
终端用户体验监控 - (主动和被动) 、用户自定义事务处理剖析、应用程序组件监控、报告和应用数据分析
终端用户体验监控 - (主动和被动)
测量用户请求数据然后返回响应给用户是捕获最终用户体验的一部分。这种测量的结果被称为实时应用监控(又名自上而下的监控),其中有两个组成部分,被动和主动。
被动监控通常是无代理的,比如使用网络端口镜像实现监控。在这个解决方案需要考虑的一个关键功能是支持多协议的分析(如XML,SQL,PHP),因为大多数企业已经不仅仅只支持基于Web的应用程序。
主动监控,包含预定义的人工探针和网络机器人,用以报告系统可用性和业务交易。主动监控是被动监控的一个很好的补充。两种手段配合,可以提供可视化的应用健康状况。
用户自定义事务处理剖析
专注于用户定义的事务或对于商业团体具有某种意义的URL页面定义。例如,对于一个给定应用程序,如果有200~300个唯一页面,可以把它们分组为8~12个更高层次的类别。这样可以实现有意义的服务等级协议(SLA)报告,从业务的角度提供应用性能的趋势信息:先从大类开始,逐渐完善它。
报告和应用数据分析
对于所有应用程序,提供一套共同的指标来收集和报告信息很重要,然后就可以对呈现应用程序的性能数据的视图标准化。来自其他工具集收集的原始数据可提高报告的灵活性。这样就可以回答各种各样的性能问题,尽管每个应用程序可能运行在不同的平台。
注意过多的信息是难以查看的,这就是为什么报告保持简单很重要,否则它将不被使用。
原文地址:知乎https://www.zhihu.com/question/27994350