Compuware的应用性能管理观

     通常，APM 解决方案会动态地为一些被观察到的测量指标构建基线；经过数天或数星期，这些基线趋于一个正常的定义。对于其它的测量指标，您很可能想要基于一段时间内的观察手动设定基线。将这些基线作为参考点，然后您就能够确定性能阈值；当测量违反了特定的行为准则时，警报就会产生。至少在最初的时候，这些阈值很可能以一个超出基线的比例被设定。例如，当页面性能从基线降低25% 的时候，就会引发一个警报。这些引发也很可能基于一个模板或一套规则被设定，能够包括更复杂的逻辑；再例如，当磁盘写队列在60秒内超出2至少5次的时候。

　　重要的、需要考虑的是哪些指标被监测，使用什么阈值；大多数的 APM 工具提供多种多样的测量选项，深入的显示出能够被分散甚至误导的水平值。缺省值或特定平台的模板可能通过APM解决方案厂商、软件/硬件厂商、系统集成商或用户社区获得。然而，无论是什么资源，确定这些阈值是否适用于您的特定环境都是非常必要的。尽管这一决定部分地能够在实施期间作出，但是大多数阈值的改进都是在运行期间实现的。

　　最后，我们应该关注最终由 EUE测量驱动的相关性能力。对于有效的相关性来说，最重要的是理解依赖性或交易在系统里经过的路径。它也建议要注意测量时间。当然，不是所有的指标都能够被连续评估，因此有些是在一段时间内进行取样。这是一种检测普遍性问题的有效方法。然而，间歇的问题本质上可能会是短暂的，以至于它们在取样期间被隐藏起来。尽管这些通常只会带来更小的业务影响（因为它们以更小的频率影响更少的用户），但是它们本质上更难解决。交易“跟随”（following）——通常通过贴标签——可能对特定的环境是合适的，然而，暂时缩短的取样间隔时间为解决间歇问题提供一种更通用的方法。

　　一个实现强大APM配置的明智方法是，在前生产测试实验室实施关键APM监测组件，这样您就能够观察到一系列系统负载上的正常行为，这对于设置基线是非常有用的。通常，您将会找到性能的瓶颈。知道哪些测量指标表明了该瓶颈的根源和它发生的阈值，这是一个理解依赖性并积极配置生产监测阈值的理想办法，而且其带来的影响也很小。

　　三、APM 运行——持续的服务改进

　　成功的运行需要在稳定性和持续的服务改进（CSI）之间保持平衡。对许多企业来说，仅仅只有在故障发生并严重威胁到业务的时候，CSI才会成为一个项目。一旦该问题得到解决，这一概念又会立即被抛到脑后，直到下一个重大故障发生的时候才会被再次记起。一个更周全的CSI方法将在事件和问题管理方面带来明显的改善，帮助IT机构更好地解决和预防问题的发生。

　　正如之前提及的，APM成功的关键——既确保业务一致性，又能解决问题——在于相关性。一个强大的CSI流程强调去改进被监测到的并找到更合适的阈值。

　　考虑一个APM 的实施，终端用户体验和基础架构指标要能被监测。当事件发生的时候——无论这个事件是由EUE警报引起的，还是因为一个实际的终端用户——IT人员都要将这一事件和它的根源关联起来。确认并修正敏感性或瓶颈——至少暂时要做到这点。如果瓶颈指标数据没有被监测到，那么，无论如何也要开始对 APM进行明显改进来监测它。如果瓶颈指标数据被监测到了，那也要着手改进去调整警报阈值，因此下一次警报能够在用户抱怨之前就识别到问题。警报可能是被动的——超过某一阈值的用户正在经历性能问题——也可能是主动的——超出阈值给出了一个尽早的警告：如果用户继续这么做的话，他将会出现性能问题。

　　最终，持续的服务改进应该不止是通过改善APM解决方案的质量来改进业务服务的水平。它可能意味着，通过拨出额外的资源或者对资源的使用给予优先考虑来控制资源，以致瓶颈将不再发生。分配符合业务策略的网络质量，增加一个SAN，或卸载一个专门服务器上的流程，这些都是例子。

　　四、作为流程的APM

　　与事件和问题管理类似，APM本身能够被作为一种流程来考虑，因此也适合持续改进。在六西格玛DMAIC（定义、测量、分析、改进和控制）模式下，既可考虑用于实施APM解决方案，又能够考虑作为一种解决问题的一致方法。

　　定义（Define）：首先而且最重要的是，您必须界定问题。对于 APM 解决方案的设计来说，这一定义始于业务需求，而且是经常能够被扩展。然而，对于响应问题来说，这一步则反其道而行之，将问题的定义严格限定于它最简单的核心因素。

　　测量（Measure）：这一步专注于收集相关的诊断信息，忽略不相关的或分散的数据。与EUE测量的相关性，对于实现确定的故障域隔离和最终根源分析的主要目标来说至关重要。可重现的问题允许更好的相关性。

　　分析（Analyze）：该流程的核心步骤包括解释数据。通常，APM 解决问题流程的目标是对一个问题进行“选疗”（triage）——识别故障域并对该结论提供支持性证据。这一步实现了持续的服务改进；相关的故障能够被用于改进阈值设置，并作为修正系统设计的输入数据。

　　改进（Improve）：领域专家——与更大的团队合作——确定改进选项来解决事件或问题。这一流程应该分开。当然，主要的业务目标是解决问题以重新恢复服务，但是从持续服务改进的角度来看，改进 APM 解决方案也很重要。APM 工程师应该评估正确的指标是不是正在被监测到，这些指标是不是相关、能够提供正确的故障域信息。

　　控制（Control）：最后一步是最容易被忽视掉的；可是没有它，您将会发现，有时候对于同一个问题，您一直在重复着前面的4个步骤。从业务角度来说，这是系统结构发生变化的地方——增加资源或对项目逻辑作出改变以避免对限制的敏感，这些限制导致了问题的产生——应该被考虑到。从 APM 的角度来说，考虑调整警报阈值和规则，从而提供一个对将来问题的提前警报，这样就能在业务受到影响之前采取相应的行动。

　　五、总结

　　随着当今的业务应用日益变得分布和独立，Gartner 已经为APM确定了4个“维度”。我们已经在不同程度上讨论了这些维度，在此总结如下：

　　·体验（experience）：捕捉应用或服务的终端用户体验

　　·依赖性（dependency）：发现并模式化应用的拓扑结果

　　·深潜（deep dive）：捕捉与依赖的组件相关的丰富统计数据

　　·剖析（profiling）：跟踪整个基础架构内的交易流

　　成功的APM解决方案将在应用环境中能够有效地解决这些维度的问题。在随后的最佳实施文章中，我们将探讨什么办法能够确保您交付的应用服务可被有效管理。每个主题——数据中心、网络、J2EE 和.NET——将作为一个单独的方法、综合的APM解决方案的一部分被一一谈及，并专注于特别的终端用户体验。