在大规模 WebSphere Application Server 环境中把 Introscope 用于网络管理

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

级别： 初级

Alexandre Polozoff (polozoff@us.ibm.com), IBM Software Group，Software Services for WebSphere, 芝加哥，伊利诺斯州

2003 年 4 月 01 日

由于您有时无法把 SNMP 功能添加到现有的 Web 应用程序中，那么您如何把网络监视功能添加到生产环境而不限制应用程序或中断最终用户的体验呢？本文讨论了在大规模环境中使用 Wily Technology 的 Introscope 使之成为可能的方法。

©2002 International Business Machines Corporation. All rights reserved.

介绍

在我的上一篇文章 Event Handler and SNMP Trap Notifications 中，我讲述了如何把简单网络管理协议（Simple Network Management Protocol，SNMP）功能添加到运行于 WebSphere Application Server 平台的 Web 应用程序。那一篇文章是从应用程序开发的角度来讨论的。然而，您有时无法把 SNMP 功能添加到 现有的应用程序中，因为许多现有的站点运行的 Web 应用程序并没有把网络管理功能作为应用程序设计的一部分。

首先开发 Web 应用程序，然后交给测试小组以验证其功能，最后进行部署。部署由网络基础结构小组来管理，虽然该小组独立于开发和测试，但它负责运行 Web 应用程序并确保站点是可用的且达到预先确定的服务质量级别。您常常会遇到这样的 Web 应用程序，它们没有包括使网络基础结构小组能够监视应用程序在生产环境中的性能的功能。

幸运的是，IBM 和第三方供应商已开始从系统管理的角度来处理网络管理的问题，具体来说，把着眼点放在独立于 Web 应用程序及其内部设计的收集数据的能力上。通过集成现有的网络管理控制台（例如 Tivoli NetView 和 HP OpenView），悄悄地收集重要的统计数据的产品正在被开发。

特别令人感兴趣的是管理包括许多大型多处理器（20 个或更多个处理器）服务器的大规模生产环境的能力。大规模环境对于网络管理对其提出的需求特别敏感。应尽量减少由网络管理工具所带来的对 CPU 开销的需求和增加的网络流量的影响以避免干扰生产环境和最终用户的体验。

在本文的第二部分（也是关于 SNMP 网络管理的），我将把重点放在 IBM 业务伙伴 Wily Technology 所开发的 Introscope。Introscope 是提供网络管理功能的工具，这些功能位于现有的生产环境之上而不限制 Web 应用程序的设计或开发过程。

回页首

生产环境和服务质量

生产环境中的硬件增加了很多功能和容量。在以前，多处理器服务器仅属于大型机的范畴。几十年后，多处理器服务器出现在中型机和 PC 环境中。不仅要解决硬件问题，而且要调整操作系统和开发工具箱以利用这些更大规模、有更多功能的机器。

“服务质量（Quality of Service，QoS）”成为生产环境的性能的衡量标准。IT 部门将努力为它的客户（通常是其它内部的部门）维护某一级别的 QoS，以确保全公司依赖技术的生产力在很可能较高的、一致的级别上。为跨国公司维护 QoS 级别常常更复杂甚至更重要，因为 任何时候的停机故障和当机时间都可能意味着某地某人无法完成他（她）的工作。

在 20 世纪 90 年代，生产环境开始经常性地包括 2、4 和 8x 处理器服务器。当时 Intel 的总裁 Gordon Moore 创立了“摩尔定律”：他预测微处理器中的晶体管的数量每过 18 个月就要翻一番。双倍的微处理器能力不仅加快了服务器的速度，也带来了把这些更快的处理器组装起来的更多硬件的改进，从而迅速扩大了生产环境的规模。在现在的 21 世纪，您常常可以看到利用 20 个、34 个甚至 64 个处理器的服务器。

更大服务器的规模提出了一些基本的限制。服务器常常在几个处理器和应用程序之间共享一个网络接口卡（Network Interface Card，NIC）。这就限制了通过 NIC 的数据量，即使是在吉位以太网线上也是如此。此外，多处理器服务器的硬件内部的网络总线限制了对 RAM 和其它 I/O 设备（例如硬盘）的访问。所有这些限制需被仔细地考虑以避免装入超过机器能力且降低性能的网络管理工具从而导致生产环境过载。

在图 1 中，有多个 Web 服务器被用作多个 WebSphere Application Server 的代理，而 WebSphere Application Server 与几个后端资源通信。在这个特定的基础结构中，后端资源是大型机加上 DB2 会话持久数据库，您也可以容易把它们换成 AS/400 或基于 UNIX 的服务器。

大规模环境中常见的问题包括：

• 硬件故障
• 断开的网络连接
• 网络阻塞
• Web 应用程序对堆大小的利用
• 由应用程序服务器完成的 JVM 垃圾收集
• Web 应用程序的内在瓶颈
• 不足的资源可用性（内存、磁盘、I/O 等）
• 很大的会话数据对象
• 应用程序错误
• 后端响应时间问题

出现在生产环境中的每个问题将影响 QoS 级别。有些问题（例如硬件故障）可被容易地诊断。其它问题（例如应用程序瓶颈或资源的过度利用）不太容易被发现或监视。这就增加了网络管理员的工作困难，特别是当问题的性质至关重要时，更是如此。

回页首

Introscope：组件

Introscope 是为现有的生产环境提供网络监视功能的工具。虽然笔者不想非常详细地描述 Introscope 产品，但是我们将简要地描述 Introscope 监视的工作原理，分析具体的性能监视问题，然后讨论 Introscope 在有大规模基础结构的 WebSphere 安装中的工作原理。

基本产品

Introscope 由几个组件构成。基本产品完成典型的应用程序和 OS 级别的性能监视。以下是一些被监视的组件：

• CPU 的利用

• servlet

• Enterprise JavaBeans（EJB）

• GC 堆

• 可扩展标记语言（Extensible Markup Language，XML）

• Java 命名与目录接口（Java Naming and Directory Interface，JNDI）

• 用户数据报协议（User Datagram Protocol，UDP）

• 线程

• 抛出的和捕获的异常

• 通用对象请求代理程序体系结构（Common Object Request Broker Architecture，CORBA）

• 正在运行的进程数量

• JavaServer Pages（JSP）

• Java 数据库连接（Java Database Connectivity，JDBC）

• 远程方法调用（Remote Method Invocation，RMI）

• Java 事务 API（Java Transaction API，JTA）

• Java 消息服务（Java Message Service，JMS）

• 文件系统

• 系统日志

• 网络套接字

Blame 技术

Introscope 的 Blame 功能部件可跟踪组件交互以分离造成性能问题的组件。例如，请考虑一个常见的示例：servlet 调用 EJB 而 EJB 调用 LDAP 服务器。Introscope 能够跟踪这些调用的路径并随着组件的执行而给出每个组件的相对响应时间。Blame 技术通过在同一张图中描绘各个组件来显式地指出罪魁祸首。（这适用于实时图和历史图。）反之，Blame 技术也能够找出与问题 无关的组件。

图 2 中的历史图是夜晚的运行结果，其中上半个屏幕显示的是 CPU 的利用，下半个屏幕显示的是垃圾收集活动。这些数据反映了强度测试的用户负载在晚上 11:30 从大变小。在这个 Blame 技术的示例中，您可以看到该图清楚地说明了在那一时刻垃圾收集周期的行为变化。

图 3 中的历史图印证了图 2 中的数据。在晚上 11:30，响应时间明显缩短，这时候垃圾收集周期似乎变长。

图 4 中的实时图显示了随着服务器上负载的增加而增加的 JDBC 调用。

图 5 是负载测试（与图 4 所反映的测试相同）期间 CPU 时间的实时图。

示例性的代码更改的影响

下图取自我们对应用程序代码更改所作的实际测试。为了使用套接字来从 Web 服务器获取数据，代码被添加到测试应用程序中。第一次施压时，应用程序没有使用套接字调用（图的左边），第二次施压时，使用了套接字调用（图的右边）。两次负载测试都是 400 个用户对一台应用程序服务器。早上 7:30 至早上 11:00 之间的长钉是为编译新 JSP 而触发的编译步骤。

图 6 显示了 servlet（绿色）和 JSP（粉红色）的响应时间。这里，值越低越好。通过两个响应时间的相加可算出总体响应时间。在左边，未用套接字的代码维持着 6.3 秒的 servlet 响应时间和 3.7 秒的 JSP 响应时间，总共是 10 秒。在右边，代码的套接字版本的 servlet 响应时间是 18.6 秒，JSP 响应时间是 8.8 秒，总共是 27.4 秒，或者说比代码的原来版本慢将近 3 倍。

图 7 显示了每秒的 SQL 查询数。这里，值越高越好。在左边，原来的代码在运行时达到每秒 123 个查询，添加了套接字代码的代码在运行时仅达到每秒 44 个查询。这意味着处理能力的明显下降。

图 8 显示了测试期间 CPU 的利用情况。右边显示的 CPU 的利用率比左边稍低一些。事实上，这似乎是向下的斜坡，这意味着机器的处理能力未被充分利用。

图 9 显示了垃圾收集周期。显然，Java 虚拟机（Java Virtual Machine，JVM）在左边受到较小的压力而在右边受到较大的压力。右边描绘的垃圾收集周期表示忙于垃圾收集方式的紧张的 JVM，这是不理想的模式。

WebSphere PowerPack 模块

Wily 还为它的基本产品提供被称为 PowerPack 模块的附件，PowerPack 模块为特定的应用程序提供全面的监视解决方案。WebSphere PowerPack 是为实际的生产 WebSphere Application Server 和 WebSphere 应用程序而设计的。它改进了 Introscope 的监视功能，它有一组预先配置的跟踪器、仪表板和警告以用于在 WebSphere 环境中监视以下性能指标：

检测 Java 应用程序

处于 Introscope 的核心的是检测和监视任何 Java 应用程序的能力。“检测”是把字节码插入类方法的过程。Introscope 基本产品提供监视所有 J2EE 组件的伪指令但可被配置成在方法级别上监视。由于 Introscope 可挂在 WebSphere Application Server 类装入器上，它能够在类被装入时根据所提供的伪指令来“检测”类。插入的字节码最终向收集和存储数据的 Introscope 企业管理器（Introscope Enterprise Manager）提供统计信息。

对于使用自己的类装入器的 Web 应用程序来说，可运行批处理进程来生成列出 Java 归档（Java Archive，JAR）或类文件中找到的所有的方法的属性文件。通过修改由批处理进程生成的属性文件可以实现对被监视的方法的选择。在缺省的情况下，所有的方法被改成注释。请在属性文件中取消对被监视的方法的注释并保存它，您也可以自己提供被监视的方法的列表。Introscope 的 ProbeBuilder 针对 JAR（或类）文件来运行并在字节码中插入 Introscope 的检测。把原来的应用程序换成检测的 JAR 文件后，Introscope 将开始收集有关方法的性能数据。

在最近的一个项目中我们利用这个功能的一个方法是检测 ctgclient.jar 文件，ctgclient.jar 是作为 CICS 事务网关（CICS Transaction Gateway，CTG）的连接性的一部分被安装的。CICS PowerPack 的 Introscope 版本包括监视重要事务的方法级别的伪指令。例如，一旦 ctgclient.jar 文件被检测后，我们就可以监视 flow()方法，flow() 是使用 CTG 服务器来发送和检索数据的主要接口。这使我们能够监视在后端上花费的时间而不必显式地监视远程大型机应用程序或内部网。您可以从 Web 应用程序中清楚地看出任何后端性能问题。CICS PowerPack 还带有监视 CTG 服务器上重要的方法的伪指令。

SQL 代理程序模块

SQL 代理程序是另一个 Introscope 模块，它可被用来准确地找出在 Java 应用程序中造成性能问题的确切的 SQL 语句。它组合了组件级别的监视和特定于数据库的测量以监视个别 SQL 语句的性能并提供有关 JDBC 连接的详细信息。它给出关于个别 SQL 语句、SQL 和 Java 应用程序服务器的交互的统计信息，还报告标准的 JDBC 驱动程序连接的应用程序的可用性。

SNMP 陷阱生成

Introscope 能够通过生成 SNMP 陷阱来集成中央监视解决方案（例如 HP OpenView 或 Tivoli NetView 上的网络管理员的控制台）。您可以针对由 Introscope 收集的性能和故障数据来设置各种类型的警告（例如电子邮件或控制台警告）。Introscope 中预先定义的阈值设置可触发警告的生成。通过适当的配置，任何 Introscope 测量的指标可被转换成 SNMP 陷阱。Wily 目前提供的功能可针对警告启动外壳程序脚本以生成 SNMP 陷阱。预计 Introscope 3.0 将提供描述它生成的 SNMP 陷阱的 MIB。

回页首

大规模安装的性能

为了为 Web 应用程序（这些应用程序以前出现过与代码相关的问题）提供应用程序监视，Introscope 被引入大规模 WebSphere Application Server 环境。应用程序在生产环境中被安装和运行。虽然在 Web 应用程序上花去了许多工作时间以纠正以前的问题，但是对于新问题是否可被具体地归咎于应用程序或硬件和网络基础结构仍存有较大的疑惑。 图 1说明了相应的硬件和网络配置。

以上讨论的情形来自于对这个大规模 WebSphere Application Server 安装的性能的监视。这里，我们将分析硬件以及它是如何与软件相对应的。

Introscope 数据的示例

在相同的项目中，我们以为我们在测试环境中看到了使初始会话数据与 DB2 保持一致时所发生的不能解释的延迟。在把负责 DB2 和网络跟踪的工作人员叫来以前，我们需要更多的证据以证明问题不在于应用程序。为了证明问题存在的地方，我们使用了由 Introscope 收集的数据，如图 10 所示。

在图 10 中，Introscope 中启用了跟踪以测量会话调用时间。对于原始数据的每 15 秒的间隔，Introscope 记录采样数量 （Value Count）、平均时间 （Integer Value）、最短时间 （Integer Min）和最长时间 （Integer Max）。

数据显示我们有不错的平均响应时间（小于一秒）和最短响应时间。但是 Introscope 记录的最长调用时间有 56 秒之长。有了这些证据后，我们就能够使网络跟踪小组参与进来，他们确定 DB2 的响应速度确实很慢。进一步的调查揭示 Solaris 服务器上的磁盘 I/O 的性能较差。

这一特殊情形的重要性在于我们能够从“意识到的”减速问题中找出根本原因，因为网络管理员可以收集详细的时间信息并证明问题确实存在。

回页首

结束语

网络管理（尤其是大规模 WebSphere Application Server 安装中的网络管理）常常是一个令许多管理员感到害怕的敏感领域。Wily 的 Introscope 是一个在大规模安装中很有价值的工具，它的开销很小但可提供 WebSphere Application Server 自身和任何与 JVM 一起运行的 Web 应用程序的详尽的监视数据。组合了查看实时数据和历史数据的功能的 Blame 技术可在生产环境中具体地、实质性地确定问题并提供解决问题的更清晰的思路。

参考资料

• IBM WebSphere Application Server: Event Handler and SNMP Trap Notifications
  
  
• Wily Technology
  

关于作者

		Alexandre Polozoff是 Software Services for WebSphere 的顾问，他参与了大容量和大规模安装的性能做法和技术的开发。他的专长包括第三方工具的评估和进行事后分析的最佳实践。Alexandre 还继续参与了开放技术标准（例如 SNMP、TMN 和 CMIP）的制定。您可以通过 polozoff@us.ibm.com与他联系。

对本文的评价

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

回页首