【IT168 评论】近日New Relic在纽交所上市了。New Relic成立于2008年，总部位于旧金山,提供应用性能管理解决方案。New Relic在华尔街的起步表现可以说非常强劲，这也为之后准备IPO的初创公司作出了良好的示范。在股票价格方面，New Relic设定的初始发行价为每股23美元，本周五在纽交所上市的开盘价上涨了31%，为每股30美元，这个股价超出了其IPO申请时提交的价格范围。
当谈到应用程序性能时，国外硅谷的AppDynamics、New Relic和国内的听云是知名度较高的3家。AppDynamics和New Relic衍生自同一家公司——Wily Technology，这是一家专门研发性能监控的企业并于2006年被CA收购——但却又各自发展成为足以独当一面的技术方案。New Relic由原Wily Technology CEO Lew Cirne创立。AppDynamics则由Wily Technology公司担任首席软件架构师JyotiBansal所缔造。听云，是北京基调网络股份有限公司推出的下一代应用性能管理平台。
New Relic的上市证明了全球软件开发商急需线上应用性能解决方案公司为他们提供服务，借此之际，本文的主要目的是帮助大家了解这三套APM技术解决方案之间的相近之处与差异所在，从而帮助大家根据自己的实际需求选择更为合适的产品。
一、APM是什么?
我可以向大家保证，这是本篇文章当中惟一一个专业术语。……好吧，也许DevOps也算一个，但就这么多了。总而言之，APM的意思是应用程序性能管理，这一概念已经存在了一段时间，但不少开发人员似乎仍不习惯将其引入自己的工作流程。APM能够帮助我们就应用程序性能作出分析——从核心角度讲，也就是计量其在执行不同区域代码以及完成事务过程中所消耗的具体时长——此类工具可以通过代码检测、监控记录或者参考网络/硬件指标等获取到这一信息。
在这一基础概念之上，还存在着众多特性各异的实施方式——但有一点基本状况是不会改变的：一套现代解决方案应该对生产环境加以监控，这就意味着其运行资源成本(包括CPU与数据吞吐量)非常重要。此外，此类方案还应该显示出Server/移动终端用户的真实使用体验。
曾经被认为是奢侈之举的处理方式如今早已进入寻常百姓家：在生产环境中进行快速部署意味着较高提升系统架构中出现错误的可能性，进而导致系统运作速度变慢甚至引发崩溃。面对这种情况，我们看看这三家解决方案提供商各自拿出了怎样的应对策略。
二、受支持环境
New Relic:Java、Scala、.NET、PHP、Node.js、Ruby以及Python。感兴趣的朋友可以点击此处(http://newrelic.com/platform)查看其所支持的数据库、云平台以及其它插件。而在用户监控方面，iOS、Android以及JavaScript都受到这两款解决方案的支持。
AppDynamics:Java、Scala、.NET、PHP、Node.js、iOS以及Android; 其中也包括大家最熟悉也最喜爱的各类数据库及云平台。
听云：听云Server目前支持包括Java, PHP, .NET在内的国内主流的三大开发平台，听云App目前支持iOS和Android两大移动开发平台。
结论:以上几家之间除了对Ruby、Python等开发语言的支持能力有所区别之外，值得一提的是听云主动式的APM产品：听云Network。听云Network在竞品性能分析、第三方服务选型和第三方服务水平监控上提供了采用被动式监测的其他两个产品所无法提供的功能。
三、具体功能
根据应用性能监控的基本发展趋势， New Relic、AppDynamics、听云和都能够被拆分成六款指向性不同的产品维度，但它们都向同一套主仪表板界面进行报告。下面让我们从后端、移动与前端角度分别对这些主要功能组件进行概述。
1、后端监控
性能管理的主要实现手段包括报告状态、图形以及关于深层应用程序性能表现的分析结论。在这方面他们各自提供一种解决方案：应用程序性能管理——高级指标，深入至代码层级获取数据，从而衡量应用程序的实际性能表现。其中必须具备的量度指标包括事务响应时间、错误率、每分钟请求数量(听云Server、New Relic上的数据吞量)以及每分钟调用数量(AppDynamics的负载功能)。
▲左图为AppDynamics仪表板，中图则为New Relic仪表板，右图为听云Server仪表板
从上图大家可能已经发现了，New Relic和听云Server的主屏幕直接显示一幅响应时间图，通过一个图表更加一目了然地展示应用性能中Web前端、应用代码、数据库、非关系型数据以及后端服务的各项性能数。相比之下，AppDynamics的主屏幕当中包含一幅服务示意图，意在显示应用程序的调用载入与性能健康指标。
这种设计方案上的差别直接反映出NewRelic与AppDynamics、听云Server在关注重点上的不同，AppDynamics相对更倾向于服务大型企业用户。
在这方面，最棘手的一大难题在于报警与报告：由于其中包含大量指标与移动部件，我们很难断言其中哪些作用最大、最值得密切关注。应该将主要精力放在低错误率身上吗?还是响应性?抑或是数据吞吐能力?New Relic、听云Server采用的是同一种评分指数，AppDynamics则选择了自己的一种方式来将以上指标纳入到性能指示体系当中。
Apdex是New Relic和听云Server采用的评分指数，这一机制利用由用户定义的响应时间阈值T来代表终端用户满意度。简单来讲，需要以手动方式设定这一阈值。下面举例说明应用程序性能得分的计算方式：
▲计算Apdex得分，只要将给定时间段内所有请求的分项得分汇总起来，就能得到全局性能分数。
而在另一方面，AppDynamics则认为Apdex结果根本就靠不住(曾发表过一篇题为〈Apdex存在致命缺陷〉的文章以解释其观点)。面对这种情况，AppDynamics想出了一套解决方案，即为随着时间推移而不断变化的应用程序性能提供一套自动化动态基准创建机制。举例来说，事务执行速度过慢的定义可能随着系统负载的升高与降低而发生变化。
总结：我们认为AppDynamics将关注优先级放在了端到端堆栈的可视化呈现方面，而New Relic和听云Server则专注于汇总性的响应时间水平。基于应用响应时间和Apdex的实时性能监控和警报机制，专注与整体应用的总体响应水平并可对重点的业务过程进行监控和报警。对响应性能特别差的访问，提供详细的追踪数据帮助用户迅速定位性能瓶颈。此外，我们还发现Apdex与动态基准机制在警报处理方面也有所不同。
服务器监控是这三款工具都提供的另一项功能，旨在检测服务器运行所在的硬件基础，其中包括：硬件规格、CPU利用率、内存利用率、磁盘I/O以及网络IO等等。
▲左图为AppDynamics，中图为New Relic，右图为听云Sys，其中分别列出了一部分样本数据。
在这一类别当中，AppDynamics所提供的备选功能要比New Relic更多一些，且主要以内存为考量重点：堆大小与利用率，每轮垃圾回收状态以及内存泄漏检测等。听云Sys功能介乎于两者之间，目前听云Server只提供了对JVM的内存、垃圾回收、线程、会话等等各个方面的详细监控数据的各项指标。
▲AppDynamics服务器监控——内存类相关功能
总结: AppDynamics能够提供更为深入的垃圾回收与内存泄漏检测机制，而非仅仅停留在标准指标层面。
(1)数据库监控
审视堆栈当中的其它组件，大家首先想到的肯定就是数据库。三家解决方案在这方面同样存在着巨大差异。其中AppDynamics拥有一套元素更加丰富的仪表板，其中包含资源消耗、等待状态、用户会话以及特定查询调用等信息。而在New Relic和听云，不同之处在于数据库仪表板实际上属于基础APM产品当中的一部分。New Relic和AppDynamics都能够通过插件来获取特定数据库监控指标，从而允许大家通过外部服务实现数据查看。听云Server非插件的方式，直接通过探针对数据库进行分析，提供了对各类常见数据库的性能分析，包括Oracle, MySQL, SQL Server, PostgreSQL和DB 2等等。无论采用哪种方式，本地与外部功能集都会根据大家所使用数据库类型的不同而有所区别。
▲左图为关注Oracle DB的AppDynamics，右图则为配备了MySQL插件的New Relic。
总结: 三套解决方案都提供针对特定数据库提供多种值得尝试的功能。从数据库层面的图表，用户可以了解应用中对那些数据库表的哪些SQL操作响应最慢、查询最频繁、耗时最多。相比较而言，而对于非常慢的SQL查询，听云Server还会保留完整的慢查询追踪记录，帮助用户了解哪些SQL语句查询慢，是哪段应用代码执行了这个查询语句，以及该SQL语句的执行计划等等，迅速帮助用户定位并调优SQL语句性能问题。同时，除了对关系型数据库的支持，听云Server还支持常用的NoSQL服务的性能监测，包括Memcached, MongoDB, Redis等等。AppDynamics也拥有更具深度的共享式数据库指标。
在数据库监测方面，AppDynamics与听云Server不相伯仲，New Relic稍差一些。
(2)观察与分析
目前听云还只是专注与APM方面的功能的提供，还未提供任何业务层面的商务数据分析。而New Relic与AppDynamics都已经能够访问到应用程序当中的各类消息，因此二者也构建了一套额外的可选数据库、帮助大家保存应用运行状态并在需要时加以查询。
▲左图为AppDynamics，右图为New Relic，右图为听云App，前二者各自列出部分样本数据。
总结: 国外的AppDynamics和New Relic要明显优于听云，二者超越传统APM后在商务智能指标方面的实际表现。
2、前端与移动监控
聊过了后端的话题，我们再来看看三套解决方案在真实用户监控方面各自拥有怎样的表现。三家产品各自拥有自己针对浏览器的产品与面向iOS及Android移动平台的方案。在移动方面，其旗舰功能包括审查速度低下及崩溃状况，并通过地理区划、设备、操作系统以及运营商网络等条件对其加以过滤：
▲左图为AppDynamics，中图为New Relic，右图为听云App——移动真实用户监控功能
在对终端用户浏览器进行分析时，整个过程类似于通过Chrome开发者工具查看浏览器的实际载入时间——只不过这一次观察对象换成了应用程序的实际用户，听云App在应用网络性能方面提供了包括主机、HTTP请求、地理位置、运营商和接入方式等多个维度的性能分析。在应用代码的性能方面提供了交互性能、设备、操作系统、崩溃等多维度的数据分析。在功能上，听云App注重于帮助国内App开发者解决他们的痛点，在满足国内开发者需求上，增加了关键元素监控，黑白名单，劫持监控，CDN监控，第三方API服务监控、行业指标等多项特色的功能模块：
▲左图为AppDynamics，中图为New Relic，右图为听云App——浏览器真实用户监控
总结: 根据我们的感受，New Relic听云App和听云App和的关注重点在于响应时间汇总，而AppDynamics则倾向于强调全局状态——与之前得出的结论完全一致。除此之外，听云Network还可以提供浏览器用户体验监控之外，还可以提供事务流、流媒体、私有协议、压力测试、CDN质量、竞品对标的多种形式的性能监控和评估，并且在发现性能问题时可以提供最详尽的网络链路诊断报告来帮助定位网络故障。针对本土的特点最大限度降低了性能问题的定位。
四、如何解决我们找出的错误
除了AppDynamics与New Relic自身所提供的错误报告与警报机制之外，很多用户还选择了自主将Takipi纳入自己的工具箱。这能帮助他们在利用New Relic或者AppDynamics对服务器速度低下以及错误状况进行监控之外，同时利用Takipi对相关状况加以解决。每当系统发现异常状况或者日志中出现错误信息时，Takipi就会捕捉状况出现时的各类与方法及设备相关的状态变量并将结果呈现给大家。
Takipi会将上述信息与错误出现时正在执行的代码进行叠加——这样大家就能准确地重现错误发生时的背景条件并分析异常情况的出现原因。Takipi的仪表板会将所有错误连接至对应的记录实例——该实例中包含问题出现时的所有相关代码，同时也会捕捉引发问题的全部变量值：
Takipi能够与AppDynamics实现理想的协作效果，同时也提供一套New Relic插件、用于在仪表板中显示异常情况与日志错误：
▲面向New Relic的Takipi插件
由于国内环境，以及严格控制APM工具对服务器的影响，在这方面听云并没有集成插件的内容。听云更多的是给用户提供预警服务，听云平台目前支持基于邮件和短信的警报，可以在应用出现性能和错误异常时，记录详细的代码级性能追踪和错误追踪数据，迅速帮助用户定位性能瓶颈和异常故障点。听云追踪功能包括听云App的错误追踪、崩溃追踪、慢交互追踪，和听云Server的Web过程追踪、慢查询追踪、异常追踪等等。如何解决还需要用户自己优化。
总结: 有一点需要强调：弄清楚是哪些因素导致服务故障是一回事，但将其彻底解决则是完全不同的另一回事。如果大家身为Java或者Scala开发人员，那么无论各位是否使用APM工具、Takipi都是不可错过的一大神兵利器。听云与AppDynamics和New Relic相比还要有差距。
五、仪表板与使用情况
要让大家更好地感受两款工具的实际用户体验以及解决问题的方式，我认为最理想的办法就是通过视频演示来说明。不过在此之前，需要强调的是AppDynamics使用的仪表板以Flash为基础……没错，就是Flash，看来这套搞得天怒人怨的方案还没彻底消失。虽然采用Flash看起来是种倒退，但AppDynamics本身可能算得上是我所见过的最出色的Flash应用程序(需翻墙)：
http://www.youtube.com/embed/doSM9lSD2so?rel=0
NewRelic方面在TypeSafe上发布了一段网络讲座视频，其中对New Relic方案的方方面面进行了说明(视频内容确实有点长，但如果大家确实打算部署自己的APM方案，那么其讲解效果还是非常出色的，需翻墙)：
http://www.youtube.com/embed/LJL7EAavb1Q?rel=0
听云的仪表盘：基于HTML 5的自定义仪表盘，用户可向仪表盘中添加任意一个在听云平台上看到的图表，并可自由拖拽图表的排列，非常适合运维NOC在大屏幕上展示重点关注的性能指标项。由于采用HTML 5的仪表盘，除了支持传统PC平台的访问，更可方便地在各移动平台设备上提供一致的访问体验。
总结: 三款工具都提供良好的使用体验，但在布局方面全世界的APM解决方案都显得有些杂乱。
六、 安装
1、SaaS/内部环境: AppDynamics和听云提供多种操作模式——包括SaaS、内部以及混合型机制，每一种都提供各自的安装指导说明。其中听云Network无需用户对生产环境做任何改动即可立即使用，只需要在听云Network平台上配置需要监测的应用的URL，几分钟后即可看到实时的性能数据。而New Relic则只支持SaaS这一种模式。
2、代理: 要对自己的应用程序进行监控，我们需要借助指向服务器的附加语言指定代理。举例来说，在Java方面我们有两种可能性选择利用代理将代码引入设备，即利用Java代理或者利用本地代理。New Relic与AppDynamics在收集报告所需的性能数据时，使用的都是Java代理。而为了获取低层级数据来指明错误位置并帮助解决问题，Takipi则会使用本地代理。
3、代码与配置变更: 在真实用户监控方案当中，如果大家需要向自己的Web或者移动应用程序中添加监控功能，那么项目与配置变更所包含的必要关联性就变得必不可少。其中包括向我们的网站添加JS代理或者向移动应用程序中添加本地移动代理等。
4、警报: AppDynamics自身会计算我们的响应时间阈值，而且可能需要花费一段时间来检查并识别当前系统。听云和New Relic则要求大家为其Apdex指数以自定义方式设置阈值。
总结：如果大家需要一套内部运行版本，那么最理想的方案明显应该是听云。如果没有此类要求，那么三者在安装流程方面都很简单——只是New Relic在警报设置层面要更复杂一些。
结论
AppDynamics、New Relic与听云可以说是目前市面上的应用最为广泛的APM工具，而且从传统角度上面向不同类型的开发人员——从全球到中国、从大型企业到初创公司。不过从三家方案中选择其一已经成为没有确切答案的问题，大家只需要明确一点——内部环境运行时不能选择New Relic，只能选择AppDynamics和听云!
本文中Appdynamics、New Relic、听云从受支持环境、具体功能、解决错误仪表板及使用、安装、价格这几项对比分析是否让你已经很清晰地了解到了如何选择适合你的应用性能解决方案了呢?笔者认为，不论使用哪款产品，作为开发者的你都是希望自己的产品能超越其他，在这竞争激烈的移动互联网时代脱引而出，不是吗?
