应用性能管理(APM)的五个步骤
目前对很多行业来说，IT技术正在支持着关键的业务应用，如制造业的ERP 系统、电信BOSS系统、银行的核心业务系统、卡业务系统以及基于电子商务的业务等。关键业务应用对性能有较高要求，性能下降往往对业务造成巨大损失。面对这些问题，需要有一系列工具和方法，能够对IT系统的性能进行监控和管理，并对可能出现的性能问题进行及时、准确的分析和处理。从而改善服务品质，减少操作失败和灾难发生的风险，减少维护运营的整体成本，提高系统的可用性、缩短响应时间，提高最终客户的满意度。
应用系统性能管理范围涉及到企业级应用和终端应用的各个方面，例如打印设备，存储设备，数据库，应用服务器，网络，Web服务器，操作系统，用户应用软件等。应用系统性能管理的尺度可概括为用户的请求是否被快速处理，系统的资源是否得到合理的利用，以及系统是否能够连续不间断地运行等三个方面。具体实施可分为下面五个步骤：
1. “见微知著” ，主动及早发现问题：
建立问题报警机制。在系统运行中，从网络，操作系统，数据库，应用服务器，Web服务器等环节上会产生大量的信息，这些信息的组合可能预示着某种潜在的性能问题，需要可灵活定制报警的机制，并且可以通过多种报警方式（电子邮件，手机短信等方式）通知管理员。
在应用系统投入运行的前期，应尽量多地发现应用系统的潜在性能问题。虽然系统在早期一般负载不大，但是通过使用监控工具，可以明显发现系统资源的细微变化。大部分问题是能够在系统运行的早期发现的。
大多数问题是可以从基本的操作系统，网络的层面中反映出来的，例如内存过度消耗，CPU的高使用率，进程的频繁启动或数量过多等；所以常见的监控对象通常是：CPU、磁盘I/O、网络、文件系统，进程，用户，MIBII，系统日志，Web服务器等。为了发现与特定应用系统有关的问题，需要有针对性地建立规则，对于SAP,PeopleSoft,Oralce,WebLogic等软件系统，应建立特定的报警规则。
2. “按图索骥” 诊断问题：
快速找出性能瓶颈，依赖更精确的监控信息。不管问题发生在操作系统，存储，数据库、应用软件，应用服务器还是WebServer 等；我们需要借助软件工具来收集有用的系统信息，提供丰富的实时的视图和报表，直接在每个被监控的系统中搜集端到端的准确信息。在这些信息基础上，进行实时和历史分析。
快速明确供应商责任是有利于快速解决问题。现在的应用系统越来越复杂，涉及到提供主机，存储设备，操作系统，数据库，应用服务器，应用软件，及其之间的大量接口的供应商，出现问题后，手工方式很难快速找到问题的根源，并且对于一些问题难以找到足够的数据以明确供应商的责任。
3. 专家性建议：
提供系统性的专家性建议，为快速解决问题提供依据和可能的方案；深入地分析问题：挖掘问题，向专家咨询，从性能管理工具中查找建议，或访问内部知识库可获得问题解决的建议及手段。
一个好的知识库，不只记录了相关问题的技术信息，同时也记录了应该找谁，在哪可以获得帮助。知识库是一个不断积累的过程，现在一些厂商也开始提供不断更新的诊断知识库。
4. 解决问题：
根据专家建议和方案，进行优化试验，测试，验证和评估等工作，在现有方案中确定最优的解决方案并进行实施。
5. 日常维护：
保证系统正常运行，关注系统运营状况，调整报警规则，关注新问题的发生，从而不断提升服务管理水平。
通过性能管理, 可以快速理解整个应用系统在运行中资源分配情况和运行机制。
应该采用服务等级管理(SLA)，建立起IT技术实现到IT技术服务管理的桥梁，使得能够从管理的层次对应用系统的维护进行评估。在SLA上前摄性地进行管理和报告，通过初始化SLA定义，可以提供实时和历史数据，并能够预见到未来的对SLA的违背，并基于这一数据对SLA进行调整。
“应用性能问题好比是在一个黑暗的房间里，你知道这个黑屋里有些问题，但是你不知道屋子里有什么，也不知道问题在哪儿。这时，应用性能管理软件就好比是一盏明亮的灯，有了这些软件工具以后，整个黑屋明亮了起来，你能非常准确地、容易地确定问题之所在，找出问题的原因，并立刻修复它。”
这里以一种优秀的性能管理工具美国Quest 公司的Foglight 来说明是怎样帮助管理J2EE应用。
随着J2EE的企业级应用越来越广泛，在实际中面临着很大风险，系统中的很多性能问题源于此。这是由于：
J2EE 应用服务器体现了“黑箱”思想，用户或开发人员对实现的细节并不清楚；
开发人员只开发业务逻辑代码，由已经标准化的资源来处理数据库连接，消息等，并不熟悉这些标准化的资源的实现过程；目前J2EE发展很快, 在很多项目建设中, 技术人员普遍对J2EE缺乏经验，专家非常缺乏；
JAVA本身难于调试，特别是获得运行中的信息更为困难。J2EE包含了很多组件，（包括客户端软件，Web 服务器，应用服务器，数据库服务器，等等），排查问题尤为艰难。
在Foglight中，监控管理信息的来源主要是：资源的使用，包括各种应用池和缓存；J2EE应用服务器通过JMX提供的信息；应用服务器/操作系统等的错误日志。
1. 发现问题：
通过Foglight 定义发现问题的恰当规则是应用性能管理的关键一步，在实际中，可从三个方面考虑：
a) 在可用性方面：
当集群中有20%服务器宕机时，发出警告；
当集群中有80%服务器宕机时，发出危急警报；
当集群中有100%服务器宕机，或一个非集群服务器宕机时，发出致命错误；
b) 在服务性能方面，需要根据应用的设计和负载定义规则：
JDBC Pools，大多数应用是以数据库为中心的，调整JDBC Pools的数量对应用的性能甚至正确性有显著影响。根据应用的设计和负载，确定JDBC Pools阈值，系统在达到阈值时将报警。
Execution Queues，根据应用实际情况，确定线程的阈值。
JMS Servers，根据应用的设计和负载，确定字节/消息的阈值，系统在达到阈值时将报警。
Message Driven Bean 和 Stateless Session Bean pools，如果Beans不可用，则请求必须等待直到获得。根据应用的设计和负载，确定Message Driven Bean 和 Stateless Session Bean pools阈值，系统在达到阈值时将报警。
Entity Bean 和 Stateful Session Bean caches，当Beans过渡地钝化或激活(passivated, activated)时，大量的磁盘I/O会显著降低性能，系统可产生报警。
回滚（Rollbacks），系统错误，资源不足，超时异常等产生的事务回滚可严重影响业务处理的成功完成。
日志文件（Log Files），根据WebLogic日志的消息的严重程度，确定不同的报警方式(Warning,Critical,Fatal)。
c) 在应用性能方面：
反应时间（Response Times），反应时间：确定相关类或方法的响应时间的报警阈值，这些值可通过这些类或方法的响应时间的历史纪录确定。报警级别可根据与历史纪录的差距确定。
回滚（Rollbacks），报警的严重程度与应用回滚数量与全部事务数量的比例相关。应用事务的回滚可能是正常的（例如校验数据），但是当应用回滚的比例很大时，将意味着错误。
2. 诊断问题：
Foglight根据预先定义的规则对应用系统进行监控并发出警报。Foglight 针对监控的对象类型，提供了丰富的关联性图表以显示类或方法的响应时间，JDBC Pool，JMS，Entity Bean，Stateful Session Bean，Message Driven Bean，Execution Queues等的使用情况。其中垃圾回收和HTTP会话是编写JAVA应用代码中常见的问题症状。
a) 垃圾回收（Garbage Collection）：
Foglight 提供图表显示垃圾回收的次数和每次回收的内存数量，可以判断应用使用内存的效率。如果每次回收大量内存的次数很多，意味着应用没有正确使用内存资源；如果每次回收较少内存的次数很多，意味着应用在使用内存方面是健康的。
b) HTTP会话：
Foglight 可以显示应用服务器上每个应用的HTTP会话的数量。可以分析HTTP会话的超时配置是否合适，同时可以计算会话对内存的消耗。如果会话数量很多，就需要注意每个会话使用的内存数量。
3. 专家性建议：
根据经验可以从三个方面获得专家性建议：
1)Foglight 和Spotlight（Quest公司的诊断产品）的联机帮助，提供了大量的实用建议。
2)系统维护团队的工作日志或知识库系统。
3)J2EE应用服务器的供应商和应用系统开发商的技术咨询队伍。
4. 解决问题：
在专家性建议的基础上，需要一支经验丰富的技术队伍来完成，技术队伍不但需要对系统和对JAVA开发有丰富的经验，而且应具有正确的解决问题的规范和方法。
5. 日常维护：
根据软件版本的变化，新功能的开发，问题的解决，需要对一些预警规则进行调整，并继续持续观察。
Foglight 提供对SLA的实时统计监控功能，自动进行统计并生成规范的管理报告。
目前国内用户对应用性能管理的认识还处于引导性阶段。很多用户还不了解对于绝大多数问题已经有工具化、程序化的解决方法。习惯在出现问题后，采用现有的简单分析工具，完全依赖开发商的经验进行分析和会诊。这种非程序化方法导致解决问题时间的不可控。使用应用性能管理产品和服务，可以帮助用户监控，分析和解决问题，从而提高整体管理水平。
（北京铸锐数码科技有限公司 www.InnovateDigital.com）