云应用大部分都是首先在私有云环境里面部署的，然后随着需求的增长，公共云实例才临时被服务所征用。由于资源一部分是内部的、一部分又是外部供应商的，还有那些根据需要纳进来的，资源的混合使用监控云应用性能的挑战随之产生。本文对云应用性能管理作了十项分析，这些分析能够说明相关挑战及解决方案。

　　1.资源性能监控Vs.应用性能监控：云应用性能经常会被拿来跟资源监控，如CPU、磁盘、内存利用情况的监控混为一谈。应用性能仅处理用户不同时间以及也许是不同地方所看到的端到端时延和性能。对最终用户的体验的监控及管理需要成为云应用性能管理的关注点。在使用应用时，用户所看到的端到端响应时间是多少？

　　2.私有实例Vs.公共实例：计算资源可源自处于组织控制范围内的私有云实例，不过一旦需求超出供应能力，公共云实例就可以加入服务当中来。资源监控会被分解，原因是尽管你了解哪些私有资源在用，但对于所使用的公有云提供商的那些特定的物理计算资源则是一无所知。公共实例所使用的物理资源会由公共云提供商动态地进行重新安排。

　　3.拓扑发现：云实例的拓扑发现，以及在发生变化时跟踪它们可能是CAPM所需要的，尤其是在用到私有云时。既然云的一部分是处在组织的控制之下的，你可以在必要的时候采取更广泛的纠正动作，至少对私有云可以如此。

　　4.第一代CAPM工具及问题：第一代CAPM工具跟编程语言和特定公司的Web服务器软件捆绑在一起。在精确跟踪在云设施运行的应用的性能时，这会产生若干问题。预测在公共云实例中使用的资源有问题。监控代理跟应用相互独立。

　　5.第二代CAPM工具及优势：第二代CAPM工具实现了在将额外的云实例（公有或私有）加入到服务里面时，将代理的拷贝跟应用一并发送的概念。这解决了第一代CAPM工具所经历的监控问题。现在你可以一致地对公有云和私有云实例了进行监控了。

　　6.云应用性能组件：云应用性能从典型用户看到的端到端响应时间和时延开始。这一点可以通过世界各地的虚拟用户来模拟真正的云应用性能测定。在云实例的这个层面上，你需要将性能组件分解为网络、用户界面、应用及数据库响应时间，以便对性能改进的根本原因进行深入分析。

　　7.代理和应用：一旦监控代理跟应用一并部署到实例中，无论其是公有或者是私有的实例都无所谓了，它们一样都能利用的云应用性能各种组件，如用户界面、数据库、应用响应时间等进行测量和报告。现在，你可以以一种一致、可靠的方式进行性能比较，因为私有和公共实例都有了相同代理的拷贝了。

　　8.互联网作为设施的一部分：云计算把公共互联网作为通信机制的一部分，此举也给总体的性能测定引入了不可知、不可预测的性能特征。唯有通过对大量实例进行性能测定并取其均值方能获得可靠的性能指标。这是因为在你基础设施中使用公共互联网时，你的网络路径可能会动态地发生改变，这是不可预测的，对于分析来说也是不可再现的。

　　9.托管SaaS CAPM的优势：跟别的托管服务已有，托管CPAM也具备相同的优势；无需额外的软硬件成本，容易伸缩，有新应用时可快速扩充，不需要时可快速缩减，只为使用到的服务付费。许多第二代CAPM工具都是托管的，符合这一模式。

　　10.根源分析的挑战：应用性能监控目的在于根源分析和问题处理，无论是用户界面、网络、数据库获应用代码均性能监控如此。CAPM的根源分析会更加棘手，因为其所使用的基础设施的动态天性。这正是将监控软件的拷贝跟应用一起发送到不同的实例上去的策略派上用场的原因。你仍然可以将性能瓶颈与各个云实例进行隔离，并通过它们深挖探究到根本原因。你可以修正私有云实例，因为它们属于组织内部的，但是公有云则会产生问题。你也许知道公有实例性能问题的根源，但是却无法对此修正。

　　结论

　　云应用性能管理（CAPM）处理的是最终用户体验问题。由于所使用的基础设施的动态性，监控和分析云应用性能是复杂的，相对而言，公有云实例的监控和分析又比私有云的要复杂。CAPM工具，尤其是将监控代理连同应用一并部署到每一个私有云及公有云实例的第二代工具，解决了其中的若干挑战。理解CAPM所有的关键概念可让你判断正确，恰当地运用这些工具可以改进云应用的性能。