三、具体功能

　　根据应用性能监控的基本发展趋势， 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质量、竞品对标的多种形式的性能监控和评估，并且在发现性能问题时可以提供最详尽的网络链路诊断报告来帮助定位网络故障。针对本土的特点最大限度降低了性能问题的定位。