主动的应用程序监视

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Alexandre Polozoff (polozoff@us.ibm.com), Software Services for WebSphere, IBM Software Group

2003 年 6 月 01 日

通过监视应用程序，在终端用户意识到存在问题之前检测出问题并对问题做出反映，是一个普遍的系统需求，对盈利性生产环境来说更是如此。大多数管理员都理解这种对应用程序进行监视的需要。

© Copyright International Business Machines Corporation 2003. All rights reserved.

引言

通过监视应用程序，在终端用户意识到存在问题之前检测出问题并对问题做出反映，是一个普遍的系统需求，对盈利性生产环境来说更是如此。大多数管理员都理解这种对应用程序进行监视的需要。实际上，各基层小组一般通过关注 CPU 利用率、吞吐量、内存使用等等来监视应用程序服务器的基本状况。然而，一个应用程序服务器环境有许多部分，知道需要监视每个部分的哪些计量值（metric）就能够区分能够有效预见生产问题的环境和有可能被这些问题击垮的环境。

当应用程序监视应用于适当的环境时，它就不仅仅是那些表示应用程序执行情况的技术数据。页面点击量、点击频率以及相关的统计数字等这些相互对照的信息也能够表明哪些应用程序或其哪些部分一贯性能良好（或不良）。根据搜集到的原始数据生成的管理报告能够清楚显示使用过应用程序的用户量。例如，一个在线商店能够根据实际的页面点击数比较某个时段的成交额，知道哪些页面的成交额较高，哪些较低。

回页首

调整主动的应用程序监视

基本上有两种方法来解决生产环境中的问题：

1. 一种是使用应用程序监视工具（它们通常是提供最新的性能、性能状况以及状态信息）持续搜集数据。
2. 另一种是通过试用和将错误理论化，这通常与从脚本文件和随机日志解析中能够获得哪些数据有关。

没什么好奇怪地，后面一种方法不怎么有效，但是了解它的其它缺点还是比较重要的。引入几种级别的日志记录以提供各种类型的信息一直是一种流行的内部应用程序监视方法，同时也是有充分理由的。日志记录是客户机-服务器时代的一种非常可信的方法，用来捕获远程工作站正在发生的事件以帮助确定应用程序问题。如今，随着浏览器主宰了瘦客户机领域，几乎没有在终端用户的工作站上收集数据的需要。因此，现在是在集中的服务器位置上收集用户数据。然而，我们一般是假定所有可能的日志记录点都可被预见并且被适当编码的，这时在服务器上收集数据就也有问题了。我们更经常的做法是在应用程序中断断续续地应用日志记录，通常仅在遇到问题和需要更多信息时才会使用日志记录功能。

相反，应用程序监视工具提供不改变应用程序代码，向早已收集到的信息中快速添加新数据的能力，因为随着分析的进行对不同数据的需要会发生改变。

虽然日志记录在单用户环境中能顺利进行，但在企业应用程序服务器环境中日志记录会带来一些内在的问题：

• 群集环境无益于集中的日志。对于具有多个服务器并且一个应用程序有多个实例的大环境来说，这是一个系统问题。一个人到底如何管理多个日志，关键在于他在多个应用程序服务器上查找不使用 HTTP SESSION 对象的应用程序的能力。对于同时涉及到多个日志的用户来说，协调和巩固事件是极其困难与费时的。
• 应用程序的多实例及其写到同一套日志的线程强加了一个重罚给应用程序（本来就要在特定的日志记录框架中花时间同步）。海量网站是一种为减少任何潜在的瓶颈而必须避免任何一种同步的环境，这些瓶颈可能会导致响应时间过长，从而使终端用户感到不满意。
• 不同级别的日志记录还需要注意：当一个问题出现时，必须打开下一级别的日志记录。这就意味着从问题一出现有价值的数据就丢失了。由于问题不会再生，很难预知日志记录什么时候应当打开，什么时候应当关闭。
• 不同机器上的日志的时间戳记会有很大差别，使得多个日志间的数据几乎不可能有相关性。
• 除了将代码行实际添加到应用程序以实现监视功能所产生的影响外，其他开发影响还包括：
  • 代码维护：那些明白引入的代码变化将产生的影响的开发者希望功能、逻辑位置和收集到的数据能够得到保持。
  • 不一致的日志记录：不同开发者对收集什么数据和什么时候收集数据可能有完全不同的解释。这些不一致不容易得到纠正。
  • 开发者介入：由于开发者通常能把数据解释得最好，所以在基于日志的方法中就需要开发者介入来确定问题。
• 通过编码实现的应用程序监视很少重用。当然框架本身是可以重用的，但那些被插入用来捕获特定数据的代码行可能无法重用。
• 将日志记录到文件时，对服务器的文件 I/O 子系统的影响是很大的。极少有别的事情会比写入文件对企业应用程序速度的负面影响更大。尽管可以配置服务器高速缓存和其它机制来尽量减弱这种负面影响，但这依然是个严重的、不可避免的瓶颈，在应用程序一直不断地向日志发送数据的高流量情况下更是如此。
• 虽然面向方面的编程（Aspect-Oriented Programming）被证明是颇有价值的日志记录技术，但至今仍只是在技术社区内被使用。

没什么好奇怪地，设法通过利用日志框架、捕获 Servlet 响应时间或某些有问题方法的定时等方式来收集基本性能数据以便更好地了解应用程序的执行情况对于开发团队来说也很常见。但因为任何可疑的问题点都会被正确识别并被改正，所以这种行为也因为上面提到的缺点而没被推行。如果识别到新数据点，就必须修改应用程序使其能容纳其他的数据集合，重新测试该应用程序，然后将其部署到生产环境。自然，在应用程序的生命周期内，我们也需要持续维护这些代码。

回页首

主动的应用程序监视工具

主动的、基于工具的应用程序监视方法的好处有很多：

• 无需编码
  到目前为止，对于基于工具的方法来说，这是唯一的最有价值的好处。因为能够使用 classloader 监测和其他 Java 技术，无需写一行代码，应用程序监视工具就能够完成无缝的、不可见的数据收集。
• 开发者分心的事更少
  由于应用程序监视不再是焦点，开发者就可以将注意力集中在应用程序的逻辑上了。
• 不是特定于应用程序的
  应用程序监视工具不是为那些比 Java 语言和 WebSphere Application Server 环境更特定的东西而开发的。
• 重用能力
  编写应用程序监视工具是为了能通过它用一般的方式从任何应用程序捕获数据，因此这个工具本身就内建了大量的重用。无需做什么特别的工作，应用程序监视工具就可以为各种在线应用程序捕获数据。
• 可靠性
  虽然一些主要供应商提供的应用程序监视工具一般都经过了大量测试并且有适应海量环境的质量保证，但您仍要付出一定的努力来确保工具在您的环境中能正常发挥作用。
• 可理解的结果
  数据巩固是在某个中心控制台进行，并且结果很容易被系统管理员接受。只有当系统管理员想尽办法仍然解决不了问题时，才会需要开发者检查来自各子系统的数据来帮助发现和解决问题。
• 成本
  是的，获取这种工具起初是要有点花费的，但随着时间的推移，最终真的很有可能大大节约成本。

回页首

应用程序监视 101

基于 WebSphere Application Server 的应用程序最少有图 1 中指出的两个或两个以上的组件：

1. servlet 容器（servlet container）
2. EJB 容器（EJB container）
3. HTTP Session 对象
4. 连接一个或多个数据库的连接池（connection pool）
5. JVM 内存（JVM memory）

其中的每一个组件都有各种可被收集和监视的计量值。当监视一个应用程序时，先确定执行监视的具体组件（这取决于您想监视的内容），然后设置能够向可解决特定问题的团队成员提供警告的阈值。例如，如果连接池的 SQL 定时比平时慢了的话，就可以与后端数据库管理员和网络管理员联系，那样他们就可以找出发生这种情况的原因。

应用程序监视可以被分为以下几类：

1. 故障
   这类监视主要是检测与一个或多个组件相关的主要错误。故障可以包括网络连接失败、数据库服务器掉线或者应用程序出现了 Java 内存溢出等错误。因为故障会对用户体验产生负面影响，所以在应用程序生命周期中检测故障是一件很重要的事。
2. 性能
   性能监视特别需要检测低于用户期望的应用程序性能，比如退化的 Servlet、数据库或其他后端资源响应时间。应用程序一般在用户负载上升时出现性能问题。由于性能问题像“故障”事件一样会对用户体验产生负面影响，所以在应用程序生命周期中检测性能问题也是一件重要的事情。
3. 配置
   配置监视是一项安全措施，用来确保影响应用程序和后端资源的配置变量处于一些预先确定的配置设置状态。不正确的配置，如最大 JVM 堆大小设置得太小或者最大 DB2 堆大小设置得太小，会对应用程序性能产生负面影响。包含几台机器的大环境，或者手工执行管理的环境，都很有可能出现配置错误和配置不一致的情况。了解应用程序配置和资源配置对于保持稳定来说至关重要。
4. 安全性
   安全监视用于检测未经授权的系统用户的侵入企图。
5. 记帐
   一些安装会向应用程序拥有者收取维护费和管理费。这类监视可以估量使用量，这样，例如一些自负盈亏并且拥有一个中心 IT 部门的组织就可以根据使用量向客户适当地收取一些费用。

这五类中的每一类也可以集成到应用程序的每日或每周管理报告中。如果使用了多个应用程序监视工具，个别子系统就能以不同的文件格式提供或者导出收集的数据，然后这些文件可以被填入报告工具。一些更强大的应用程序监视工具不仅能监视各种单个的子系统，而且还能提供一些报告或绘图功能。

历史数据

应用程序监视的主要好处之一就是能够确定应用程序的历史趋势。应用程序都经历生成期，在这期间应用程序的每一种新版本可能都会比前面的版本提供更多的功能和／或修定。主动的应用程序监视提供了一种衡量方法，衡量应用程序的改变是否影响性能，更重要的是衡量怎样影响性能。如果对前一种版本的修订使得响应速度更慢，那就必须问一下所提供的修订有没有被彻底实现。同样，如果新的功能部件证明比旧的慢得多，那就要让开发小组把注意力集中到理解这些差别上了。

当新的应用程序版本可用时，就可以根据一些预先定义的性能测试定义一个基线，然后重新执行性能测试来获得历史数据。必须在应用程序的某个点上及时执行这个基线，一旦达到了性能目标，就可以用新的基线取代这个基线。接着把这个基线作为一个可测的量，根据它直接测量应用程序的变化。性能统计数字也可以帮助澄清有关应用程序执行情况（正在执行时或者已经执行过）的误解，帮助弥补不基于事实的主观上的观察。如果不收集性能数据，主观上的观察经常会导致对应用程序性能做出错误的结论。

回页首

计量值

下文定义了适用于典型 WebSphere Application Server 环境的一套计量值。按照极端编程的风格，收集那些您感到对您的应用程序有用的空白最小计量值和阈值，收集时选择那些能够为确定问题提供必要帮助的数据点。从访问后端系统和 servlet/JSP 响应定时的方法开始。准备好在环境发展和规模扩大时改变这套收集的计量值或阈值。

请记住：可用的计量值集合依赖于您的基础结构。一些诸如网络转换器、路由器之类的组件已经内置了 SNMP 功能，以便在发生故障时发送陷阱警示（trap）。其他后端资源可由 Tivoli_Distributed Monitor 工具方便地监视。可以通过诸如 Wily 的 Introscope 之类的工具来监视应用程序和 JVM 环境，该工具能够向 Tivoli 控制台发出 SNMP 陷阱警示。每一种环境中工具的混合与搭配都会有所不同，这种搭配建立在技术需求和业务需求的基础之上。在一种环境中有效的工具在其他环境中可能会不怎么有效。

故障监视

不出所料，应用程序环境中的一个最全面的计量值集合是用来进行故障监视的计量值集合。这些计量值不但要检测与应用程序相关的故障，还要检测那些与运行应用程序的物理服务器相关的、与被访问的后端资源相关的以及与网络连接组件（转换器、路由器等等）相关的故障。故障分组中描述的许多计量值都与其他类别的阈值计量值有关联。

请注意：一些工具只在必须监视的日志文件中提供错误消息。

• DB2：监视 db2diag.log
• CTG：监视 CICSCLI.LOG
• SNA：监视 sna.err
• 应用程序日志文件是每个应用程序都有的。如果环境是群集环境的话，那就必须监视来自每一个应用程序的日志文件。

性能监视

性能监视分组中的计量值专门用于检测与应用程序相关的任何资源退化行为。

特定于应用程序的计量值会涉及到许多复杂页面请求（Complex Page Request），被用来通过专门的函数确定应用程序的性能。一些函数的阈值可能比另外一些函数的低。收集计量值的频率取决于工具和要收集的计量值。例如，servlet 平均响应时间和 CPU 利用率之类的计量值应该至少每分钟或每两分钟收集一次，而复杂页面请求则可以每 10 到 20 分钟收集一次。

配置监视

各种可存在于 WebSphere Application Server 配置中的后端资源并非微不足道。除了这些配置之外，还有各种特定于应用程序的配置。但生产环境中很少发生配置变化，这使它们成了以较低频率进行定期监视的理想候选者。

如果要用 XMLConfig 工具对配置进行抓屏的话必须要预先计划好。XMLConfig 是一个性能密集型应用程序，在 WebSphere Application Server 大环境中更是这样。因此，建议在流量比较小或维护窗口时安排 XMLConfig 的导出。

安全监视

安全监视要能够检测非法侵入和拒绝服务攻击。由于每个网络组件（例如，防火墙、路由器、第三方认证软件等等）都有自己的安全协议和检测功能，所以安全监视会很复杂。关于安全性这个主题，有许多优秀的权威参考资料可以为您提供具体的详细信息，如设置适当的监视点。由于这类监视自身的特性，您会想要有个可以保证安全的第三方来审查您的安装以确保您的监视点被设置得完全可以进行全面的威胁检测。

记帐监视

在有必要根据使用量向应用程序拥有者收取费用的环境中，大多数用于记帐的数据可从 Web 服务器访问日志中获取（WebSphere Site Analyzer 的功能）。不通过 Web 服务器进行通信的 Java 胖客户机上的应用程序可能需要提供额外的日志记录功能以便捕获使用量数据。大量、海量安装可以使用数据挖掘技术，但这同样要求能在最短的时间内存储大量的数据。

回页首

结束语

在生产环境中监视各种应用程序计量值可以帮助您从当前和历史的角度了解应用程序服务器环境内组件的状态。当更多的后端资源和应用程序被添加进来与原来的混合在一起时，您只需要指示应用程序监视工具去收集附加的计量值。即便不能帮助您完全避免这些问题，有了明智的计划和正确的数据集，主动监视也可以帮助您快速纠正会产生负面影响的应用程序性能。

因为根据收集到的原始数据可以很容易看出各种量的统计数字与（比如）总收入的相互关系，所以解释业务上下文内的原始数据就可以帮助管理人员了解应用程序的执行状况。了解一个站点的盈利状况可为应用程序将来的改动指明方向。

或许，应用程序会不可避免地出现些错误。但至少主动监视使您能够在问题发生时就检测问题，并且在这些问题还没有引起任何人注意之前就把它们解决掉。如果问题仍将发生的话，您最好在客户之前查明这些问题。

关于作者

		Alexandre Polozoff是一名 Software Services for WebSphere 顾问，从事海量、大规模安装的性能实践与技术的开发。他的专长包括第三方工具评估以及执行事后分析的最佳实践。Alexandre 还一直致力于开放技术标准，如 SNMP、TMN 和 CMIP。您可以通过 polozoff@us.ibm.com与他联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首