WEB开发网
开发学院软件开发Java 监视 IBM WebSphere Extended Deployment 环境 阅读

监视 IBM WebSphere Extended Deployment 环境

　2010-01-18 00:00:00　来源：WEB开发网　　　
核心提示：引言操作监视可查找生产环境中的更改，在大多数环境中，监视 IBM WebSphere Extended Deployment 环境，这意味着不是由操作员发起的任何更改都可能会向系统团队发送警报，我们做此假设的原因是大多数环境都是静态运行的，通过构建自定义的管理客户端，有助于筛选此信息，在启动之后，它们自己不会更改

引言

操作监视可查找生产环境中的更改。在大多数环境中，这意味着不是由操作员发起的任何更改都可能会向系统团队发送警报。我们做此假设的原因是大多数环境都是静态运行的，在启动之后，它们自己不会更改。

但是，以前的假设并不适用于更为自主的环境。一个较好的示例就是 IBM WebSphere Extended Deployment（下文称为 WebSphere XD）产品。WebSphere XD 调整应用程序服务器实例，为关键应用程序提供维护可接受的响应能力所需的资源。在其功能中，WebSphere XD 支持“监督”模式（由 WebSphere XD 提出建议，但由操作员选择是否对其采取措施）和“自动”模式（WebSphere XD 基于规则自动启动和停止环境中的实例）。

那么发生预期更改时我们如何进行监视？在此情况下，我们将预期更改与异常更改（或者至少为值得注意的更改）进行了区分。本文讨论在 WebSphere XD 环境和技术中，通过 IBM WebSphere Application Server Network Deployment 中的 Java Management Extensions (JMX) 获取这些状态通知的一些可能需要关注的条件。

传统监视

有多个监视方法，许多组织使用各个策略的组合来获取其环境的全面情况。图 1 显示了基本监视点的高级视图。


图 1. 基本监视点
监视 IBM WebSphere Extended Deployment 环境

许多组织通过测量最终用户的响应时间来获得总体的性能情况。测量响应时间非常有用，我们可以通过它了解特定应用程序是否符合服务水平协议 (Service Level Agreements) 要求的响应能力或可用性，但这并不是一定能够预测的。如果我们同时监视计算机和进程的运行状态，则可以预见将会影响站点性能的某些条件（是继续良好运行还是越来越糟），从而使我们能够在最终用户体验到降级之前就采取措施。例如，如果某个特定计算机的 CPU 使用率达到了预定的阈值（例如 85%），则监视系统应向操作员发出警报。该阈值警报有望为操作员提供采取纠正措施的机会，而不会导致 CPU 使用率持续增长而导致不可接受的响应时间。

除了这些度量外，有些组织还选择收集详细的响应时间测量结果，来帮助确定问题或向他们警报潜在的站点性能降级问题。有一些工具和规范可支持该方法，并为组织提供了跟踪生产环境的各个层面所需的响应时间。WebSphere Application Server 可在产品内的关键位置提供“应用程序响应度量 (ARM)”检测点。这些度量可让操作小组跟踪给定事务在网站多个组件中的响应时间。IBM Tivoli Component Application Monitor for Response Time Tracking 提供了一个查看这些 ARM 度量的一个界面，还在自定义应用程序代码中采用了 ARM 测量（如果启用了 ARM）。

WebSphere XD 监视

传统监视的许多方面在 WebSphere XD 环境中都是相同的。大多数组织认为监视最终用户的响应时间仍然非常有用。尽管 WebSphere XD 从 WebSphere Application Server 和 On Demand Router (ODR) 角度监视响应能力，但具有说明不受 WebSphere XD 管理的前端网络和其他基础结构组件响应时间的全面视图仍十分有用。

WebSphere XD 还引入了一个监视系统和进程的新方法。WebSphere XD 产品本身可以监视应用程序服务器及其运行时环境，并进行必要的调整，为高优先级应用程序提供维护性能所需的资源。许多以前由操作员手动处理的警报（例如 CPU 使用率过高、响应时间较差等）现在可以由 WebSphere XD 自动处理。

例如，假设有两个应用程序（客户的银行业务和雇员津贴）分别以两个不同的应用程序服务器实例运行于同一个物理服务器上。如果客户的银行业务向 WebSphere XD 定义为高优先级应用程序，则在服务器的 CPU 出现较高的使用率，并且客户银行业务应用程序有可能发生超出其响应时间最大值的危险时，WebSphere XD 将限制对雇员津贴实例的请求。

那么应该监视 WebSphere XD 的哪些度量？从系统角度看，尽管我们可以在某些情况下选择发送信息性消息，而不是全部发送警报，或者在某个条件持续指定的时间段时仅发送一个警报，但测量关注的内容是相同的。

例如，WebSphere XD 监视环境仍将包括 CPU 使用率的监视。长时间的高 CPU 使用率是非常有意义的关注内容，因为这可能表明站点通信量猛增，我们没有足够的硬件容量来支持这一通信负荷。高 CPU 使用率还可能表明新代码的部署存在问题，计算机上不在 WebSphere XD 控制之下的某个进程（如数据库）的行为不正常，或者只是定义了低下的 WebSphere XD 规则而导致了不适当的工作发送。类似地，其他需要关注的系统度量包括：

内存

I/O

分页。

除系统度量之外，应用程序服务器的某些状态和 ODR 本身也是需要关注的内容。另外，由 ODR 启动、用于解决潜在错误条件的一些任务也是提供监视警报的较好备选方法。

大多数监视解决方案将报告系统度量（CPU、内存等）作为其基本功能的一部分，因此这里将不讨论对它们的收集。不过，我们如何就 WebSphere XD 处理的需要关注的条件向操作员发送警报？例如，如果 WebSphere XD 选择启动或停止实例，或者某个实例违反了运行状态策略，我们需要向操作员发出警报。

WebSphere Application Server 可通过 Java Management Extensions (JMX) 报告应用程序服务器实例的状态。WebSphere XD 还使用内置的 JMX 服务来报告由 WebSphere XD 启动用来管理其环境的任务。我们可以使用通过 JMX 服务报告的 WebSphere Application Server 和 WebSphere XD 信息来调整整个监视解决方案的信息。

使用 JMX 监视 WebSphere XD

JMX 是 Java 2 Platform Enterprise Edition (J2EE™) 规范的一部分，它提供一组向其他程序公开 J2EE 应用程序服务器资源的标准 API。一般情况下，其他程序是系统管理基础结构的组成部分。由于 WebSphere XD 基于 WebSphere Application Server Network Deployment 产品，所以，该产品的 Network Deployment 版可用的所有 JMX API 也可用于 WebSphere XD。另外，WebSphere XD 还提供一套自己的 JMX API。

JMX API 通常指定和控制 J2EE 应用程序服务器的配置设置和运行时策略，支持设置 JVM 堆大小或启动应用程序服务器之类的任务。JMX API 还提供用于监视 J2EE 应用程序服务器运行时环境的接口。

在这一部分中，我们将讨论如何利用 JMX API 在 WebSphere XD 环境中执行基本监视。我们需要将这些 API 中的关键消息和信息与组织的监视系统集成在一起，然后将这些信息转换为监视控制台的警报或屏幕信息。

但是，许多监视系统没有从 JMX 接口获取信息的内置功能。在此情况下，我们可以编写自己的管理客户端，将 JMX API 的信息反馈给监视系统。（WebSphere Application Server Network Deployment V6.0x Information Center 提供了此类客户端的一个示例。）此客户端本身作为独立的 Java 进程运行，用于在 WebSphere Application Server 安装和监视系统之间沟通信息。

使用 MBean 监视 Java 进程

上文提到的 Java 应用程序资源是以 MBean 的形式通过 JMX API 公开的。图 2 显示了将通知信息从 JMX API 反馈给监视工具的自定义管理客户端的一个示例。请注意，客户端连接到位于 WebSphere Application Server 环境的部署管理器中的 MBean 服务器。该服务器可让客户端访问由计算单元中的应用程序服务器、节点代理和 ODR 生成的 JMX 通知。


图 2. 自定义管理客户端的示例
监视 IBM WebSphere Extended Deployment 环境

WebSphere XD 监视最需要关注的 MBean 对象是 Server、NodeAgent、DeploymentManager 和 TaskMangement MBean。Server、NodeAgent 和 DeploymentManager MBean 是 Network Deployment JMX API 的一部分；TaskManagement MBean 是 WebSphere XD API 的一部分。Network Deployment 和 WebSphere XD 的完整 JMX/MBean API 可以在各自的信息中心找到。

这些 MBean 代表什么？在 Network Deployment 环境中：

您可能会想到，Server MBean 代表应用程序服务器的管理对象，它可以是一个单独的实例或者集群的一个成员。

另外，Server MBean 还代表节点代理和部署管理器。

在 WebSphere XD 环境中：

Server MBean 还代表 ODR 和动态集群成员。

因此：

如果管理客户端查询 MBean 服务器，以查找环境中的所有活动的 Server 类型的 MBean，则返回的集将包括每个应用程序服务器（独立服务器、集群成员或动态集群成员）、每个 ODR、每个节点代理和部署管理器的 MBean。

对于节点代理和部署管理器，还存在独有的 MBean。NodeAgent 和 DeploymentManager MBean 可以为我们提供 Server MBean 不能提供的其他信息。（Server MBean 仅代表没有其他独有 MBean 的 ODR 和动态集群成员。）

下面是一个非常简单的管理客户端示例，该示例仅获取 NodeAgent MBean 并输出关于它的信息。

package　com.ibm.my.jmx;　
　
import　java.util.Properties;　
import　java.util.Set;　
import　java.util.Iterator;　
　
//management.jar　
import　javax.management.MalformedObjectNameException;　
import　javax.management.ObjectName;　
import　javax.management.*;　
　
//　admin.jar　
import　com.ibm.websphere.management.*;　
import　com.ibm.websphere.management.AdminClient;　
import　com.ibm.websphere.management.AdminClientFactory;　
import　com.ibm.websphere.management.exception.AdminException;　
import　com.ibm.websphere.management.exception.ConnectorException;　
　
//　runtimefw.jar　
import　com.ibm.ws.runtime.component.ComponentImpl;　
　
public　class　JMXAdminClientSimple　{　
　private　AdminClient　adminClient;　
　private　ObjectName　nodeagent　=　null;　
　
　public　void　initialize()　throws　Exception　{　
　try　{　
　　//　Initialize　the　AdminClient.　
　　Properties　adminProps　=　new　Properties();　
　　adminProps.setProperty("type",　AdminClient.CONNECTOR_TYPE_SOAP);　
　　adminProps.setProperty("host",　"localhost");　
　　adminProps.setProperty("port",　"8879");　
　　adminClient　=　AdminClientFactory.createAdminClient(adminProps);　
　}　catch　(Exception　ex)　{　
　　ex.printStackTrace(System.out);　
　　throw　ex;　
　}　
　}　
　
　
public　void　getNodeAgentMBean()throws　AdminException　{　
　Iterator　iter;　
　try　{　
　　String　query　=　"WebSphere:type=NodeAgent,*";　
　　ObjectName　queryName　=　new　ObjectName(query);　
　　Set　s　=　adminClient.queryNames(queryName,　null);　
　　if　(!s.isEmpty())　{　
　　　System.out.println("Found　NodeAgent...");　
　　　iter　=　s.iterator();　
　　while　(iter.hasNext())　{　
　　　nodeagent　=　(ObjectName)　iter.next();　
　　　System.out.println("*********************************************");　
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　　System.out.println("KeyPropertyList:　"　+　nodeagent.getKeyPropertyListString());　
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　}　
　　}　
　　else　{　
　　throw　new　AdminException("NodeAgent　MBean　was　not　found");　
　　}　
　}　catch　(MalformedObjectNameException　e)　{　
　　System.out.println(e);　
　　e.printStackTrace();　
　}　catch　(ConnectorException　e)　{　
　　System.out.println(e);　
　　e.printStackTrace();　
　}　catch　(Exception　e)　{　
　　System.err.println(e);　
　　e.printStackTrace();　
　}　
　return;　
　}　
　　　
　public　static　void　main(String[]　args)　{　
　JMXAdminClientSimple　jmxAdminClient　=　new　JMXAdminClientSimple();　
　try　{　
　　jmxAdminClient.initialize();　
　　jmxAdminClient.getNodeAgentMBean();　
　
　}　catch　(Exception　e)　{　
　　System.err.println("The　error　is　"　+　e.getMessage());　
　}　
　System.exit(0);　
　}　
}

当上述管理客户端运行时，在系统输出中将显示如下信息：

Found　NodeAgent...　
**************************************************　
KeyPropertyList:　platform=common,cell=rhaalab4Cell03,version=6.0.2.5,　
name=NodeAgent,mbeanIdentifier=NodeAgent,type=NodeAgent,　
node=rhaalab4Node07,process=nodeagent

（示例管理客户端通过部署管理器 SOAP 端口连接到 MBean 服务器。）

关于 MBean

现在我们已经了解到 MBean 接口的工作方式，但它能够提供哪些有助于操作监视的信息呢？前面已经提到，WebSphere XD 通过自动启动和停止应用程序实例来保证高优先级应用程序的响应能力。当发生这种情况时，我们可能需要向监视台生成通知，特别是在部署过程的早期，当我们需要验证针对应用程序优先级向 WebSphere XD 提供的规则时。另外，大多数操作员还需要知道应用程序服务器实例何时意外终止。

MBean 接口可提供涉及进程状态的通知。根据 API 文档，Server MBean 生成下列状态：

j2ee.start.starting

j2ee.state.running

j2ee.state.stopping

j2ee.state.stopped

j2ee.state.failed.

类似地，NodeAgent MBean 可生成下列通知：

websphere.process.starting

websphere.process.running

websphere.process.stopping

websphere.process.stopped

websphere.process.failed.

DeploymentManager MBean 可生成：

websphere.process.running

websphere.process.failed.

而且，即使 API 文档中没有显示（当然在不断更改或者即使受支持的文档上也不能保证显示），我们测试的 DeploymentManger MBean 版本还会生成：

websphere.process.stopping

websphere.process.stopped.

接下来，我们需要了解导致产生这些通知的情形。DeploymentManager MBean 仅为节点代理生成通知。类似地，NodeAgent MBean 仅为服务器生成通知。Server MBean 将为这三种类型中的每一种类型生成通知，但不像 DeploymentManger MBean 或 NodeAgent MBean 那样生成所有状态更改。例如，Server MBean 仅生成“stopping”状态更改，而 NodeAgent MBean 则生成“stopping”和“stopped”两种状态更改。

下表说明了如何在自定义管理客户端中设置通知，使之接收有关 J2EE 进程状态更改的最完整的信息。


表 1. MBean 通知表

被监视的 MBean通知 MBean 类型生成正常启动通知生成正常停止通知生成异常停止通知
ServerNodeAgentwebsphere.process.starting
websphere.process.running		websphere.process.stopping
websphere.process.stopped		websphere.process.failed
websphere.process.starting
websphere.process.running
NodeAgentDeployment managerwebsphere.process.runningwebsphere.process.stopping
websphere.process.stopped		websphere.process.failed
Deployment managerServernothing generatedj2ee.state.stoppingnothing generated

例如，ODR 由一个 Server 类型的 MBean 以独占方式表示。要在 ODR 可能启动时得到通知，必须设置自定义管理客户端，使之从代表运行 ODR 的节点的 NodeAgent MBean 接收通知。（对于本示例，我们假设 ODR 是该特定节点上仅有的应用程序服务器进程。否则，当节点代理启动或停止共享该节点的其他进程时，我们将会得到通知。）

自定义管理客户端必须执行两项操作才能接收这些通知。首先，自定义管理客户端必须注册了通知，其次，它必须提供一个通知处理程序。通过执行下列操作可增强自定义管理客户端接收通知的能力：

更改类定义使之包括 implements NotificationListener，如下所示：

public　class　JMXAdminClientSimple　implements　NotificationListener　{

添加 registerNodeagentNotificationListener 方法、handleNotification 方法和 runUntilKilled 方法：

　　private　void　registerNodeagentNotificationListener()　
　　{　
　　　　//　Register　this　object　as　a　listener　for　notifications　from　the　NodeAgent　MBean.　
|--10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　　　//　Don't　use　a　filter　and　don't　use　a　handback　object.　
　　　　try　
　　　　{　
　　　　　　adminClient.addNotificationListener(nodeagent,　this,　null,　null);　
　　　　　　System.out.println("Nodeagent　Registered　for　event　notifications");　
　　　　}　
　　　　catch　(InstanceNotFoundException　e)　
　　　　{　
　　　　　　System.out.println(e);　
　　　　}　
　　　　catch　(ConnectorException　e)　
　　　　{　
　　　　　　System.out.println(e);　
　　　　}　
　　}　
　
　　public　void　handleNotification(Notification　ntfyObj,　Object　handback)　
　　{　
　　　　//　Each　notification　that　the　NodeAgent　MBean　generates　will　result　in　
　　　　//　this　method　being　called　
　
　　　　System.out.println("***************************************************");　
　　　　System.out.println("*　type　　　=　"　+　ntfyObj.getType());　
　　　　System.out.println("*　message　　=　"　+　ntfyObj.getMessage());　
　　　　System.out.println("*　source　　=　"　+　ntfyObj.getSource());　
　　　　System.out.println("*　seqNum　　=　"　+　Long.toString(ntfyObj.getSequenceNumber()));　
|--10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　　　System.out.println("*　userData　=　"　+　ntfyObj.getUserData());　
　　　　System.out.println("***************************************************");　
　　}　
　　　
　　private　void　runUntilKilled()　
　　{　
　　　　try　
　　　　{　
　　　　　　while　(true)　
　　　　　　{　
　　　　　　　　Thread.currentThread().sleep(120000);　
　　　　　　　　System.out.println("***************************************************");　
|--10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　　　　　}　　
　　　　}　
　　　　catch　(InterruptedException　e){}　
　　　}

按如下所示向主方法添加两行代码，以便调用 registerNodeagentNotificationListener 和 runUntilKilled 方法。

public　static　void　main(String[]　args)　{　
　JMXAdminClientSimple　jmxAdminClient　=　new　JMXAdminClientSimple();　
　try　{　
　　jmxAdminClient.initialize();　
　　jmxAdminClient.getNodeAgentMBean();　
　　jmxAdminClient.registerNodeagentNotificationListener();　
　　jmxAdminClient.runUntilKilled();　
　
　}　catch　(Exception　e)　{　
　　System.err.println("The　error　is　"　+　e.getMessage());　
　}　
　System.exit(0);　
　}

在完成这些增强之后，重新启动自定义管理客户端。它将进入接收通知的等待状态。如果在目标节点启动 ODR 服务器，则在系统输出中将显示以下内容：

Found　NodeAgent...　
**************************************************　
KeyPropertyList:platform=common,cell=rhaalab4Cell03,version=6.0.2.5,　
name=NodeAgent,mbeanIdentifier=NodeAgent,type=NodeAgent,　
node=rhaalab4Node07,process=nodeagent　
Nodeagent　Registered　for　event　notifications　
***************************************************　
*　type　　　=　websphere.process.starting　
*　message　　=　null　
*　source　　=　WebSphere:platform=common,cell=rhaalab4Cell03,version=6.0.2.5,　
name=NodeAgent,mbeanIdentifier=NodeAgent,type=NodeAgent,　
node=rhaalab4Node07,process=nodeagent　
*　seqNum　　=　14　
*　userData　=　{processName=ODR01}　
***************************************************　
***************************************************　
***************************************************　
*　type　　　=　websphere.process.running　
*　message　　=　null　
*　source　　=　WebSphere:platform=common,cell=rhaalab4Cell03,version=6.0.2.5,　
name=NodeAgent,mbeanIdentifier=NodeAgent,type=NodeAgent,　
node=rhaalab4Node07,process=nodeagent　
*　seqNum　　=　15　
*　userData　=　{processName=ODR01}　

我们还可以根据上面的表继续增强自定义管理客户端，使之接收节点代理和部署 mManager 的状态更改，但请注意，当监视部署管理器时，注册通知的 MBean 必须是 Server 类型。自定义管理客户端需要查询 Server 类型的 MBean，然后在一组返回的 MBean 中确定代表部署管理器的 MBean。然后必须为该 MBean 注册通知。执行此操作后将增加识别功能，可以知道部署管理器何时停止。（自定义管理客户端将接收到部署管理器的 j2ee.state.stopping 通知。）

使自定义管理客户端通过该方式接收部署管理器通知后，它还会接收环境中其他组件（如应用程序组件）的其他 j2ee.state.* 类型的通知。在此情况下，可向自定义管理客户端添加一个过滤器，来识别仅应用于部署管理器的状态更改。

请注意，注册通知的代码使用的是 addNotificationListener 方法。有一个可选方法可让自定义管理客户端仅调用一次该方法就能添加多个通知侦听器。addNotificationListenerExtended 方法可接受 ObjectName 查询字符串的通配符。要注册自定义管理客户端，使之接收从所有 MBean 生成的所有通知，可考虑编写一个 registerNotificationListener 方法：

　　private　void　registerNotificationListener()　
　　{　
　　　　//　Register　this　object　as　a　listener　for　notifications　from　the　
　　　　//　all　MBeans.　Don't　use　a　filter　and　don't　use　a　handback　
　　　　//　object.　
　　　　try　
　　　　{　
　　　　　String　query　=　"WebSphere:*";　
　ObjectName　queryName　=　new　ObjectName(query);　
　adminClient.addNotificationListenerExtended(queryName,　this,　null,　null);　
　　　　　　System.out.println("All　MBeans　Registered　for　event　notifications");　
　　　　}　
　　　catch　(MalformedObjectNameException　e)　
　{　
　System.out.println(e);　
　e.printStackTrace();　
　　　}　
　　　　catch　(ConnectorException　e)　
　　　　{　
　　　　　　System.out.println(e);　
　　　　}　
　　}

使用 addNotificationListenerExtended 方法的缺点是自定义管理客户端可能会收到多余的通知。可以通过更改 ObjectName 查询字符串或对方法调用使用筛选参数来减少返回的通知。

无论使用 addNotificationListener 方法还是 addNotificationListenerExtended 方法，自定义管理客户端必须分析相应的通知，以确定它适应于哪个进程。请查看上面启动 ODR 时的示例输出。“type”值标识状态更改，但需要分析 userData 值来确定进行状态更改的进程。

使用 TaskManagement MBean 监视事件

到目前为止，我们讨论了 IBM WebSphere Application Server Network Deployment 和 WebSphere XD 通常用于描述进程状态的通知。现在，我们了解一下 WebSphere XD 产品独有的 MBean。

WebSphere XD 通过“任务”向最终用户警告由自动控制器启动的操作。对于某些任务，这包括 WebSphere XD 为响应某些条件需要采取的操作的描述。例如，如果违反了运行状态策略，并且 WebSphere XD 需要对相关实例启动一个线程转储，则会发出一个任务指示该情况。我们可以利用这些任务通知，并通过管理客户端将它们转发到监视系统。

WebSphere XD TaskManagement MBean 能够在创建 WebSphere XD 任务时通知侦听器，并能够在任务的状态更改时继续通知侦听器。可以生成的任务类型有应用程序放置任务（由 Application Placement Controller 生成）、运行状态策略违反任务（由 Health Controller 生成）和服务策略违反任务。

TaskManagement MBean 可以生成下面的通知：

websphere.taskmanagement.tasknew

websphere.taskmanagement.taskstatechange

websphere.taskmanagement.taskseveritychange

websphere.taskmanagement.taskstatus.

自定义管理客户端像对 NodeAgent 一样注册和处理 TaskManagement 通知。一篇标题为 Enabling Logging of Autonomic Tasks in WebSphere Extended Deployment 的优秀 developerWorks 文章详细描述了该过程，并提供了一个捕获和记录 websphere.taskmanagement.tasknew 通知的示例。该示例还说明了如何针对特定任务调用 TaskManagement MBean 上的 getActionPlan 方法。操作计划提供了有关任务的其他信息，这是通知本身所不能提供的。

我们监视任务管理通知的目的并不只是想知道创建了一个新任务。我们还需要知道是否对该任务采取措施，如果采取了操作，那么操作的结果是什么。要做到这一点，自定义管理客户端必须注册其他 websphere.taskmanagement.* 通知，并用 notificationHandler 方法处理它们。然后，自定义管理客户端必须与 TaskManagement MBean 上的 getActionPlan 方法一起调用 getCurrentState 和 getTask 方法来标识任务的状态（例如，Succeeded）、任务的原因（例如违反了某个特定的运行状态策略）和任务的操作目标（例如服务器）。

下面的示例说明了自定义管理客户端处理 TaskManagement 通知时可能用到的内容。已删除了某些代码的细节（但前面的示例中已有）。

//　get　the　TaskManagement　MBean　
private　ObjectName　taskManagement　=　null;　
public　void　getTaskManagementMBean()throws　AdminException　{　
　try　{　
　　　　String　query　=　"WebSphere:type=TaskManagement,*";　
　　　　ObjectName　queryName　=　new　ObjectName(query);　
　　　　Set　s　=　adminClient.queryNames(queryName,　null);　
　　　　　　　　　　if　(!s.isEmpty())　{　
　taskManagement　=　(ObjectName)　s.iterator().next();　
　　　　}　
　　　　　　　.　
　　　　　　　.　
　　　　　　　.　
　}　}　
　
　
//　register　Notification　Listener　for　TaskManagement　MBean　
private　void　registerNotificationListener()　{　
　　　　　　try　{　　　　
　　　　　　　　　String　query　=　"WebSphere:type=TaskManagement,*";　
　　　　ObjectName　queryName　=　new　ObjectName(query);　
　　　　　　　　　adminClient.addNotificationListenerExtended(queryName,　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　this,　null,　null);　
　　　　　　　}　
　.　
　.　
　.　
　}　
　
//　handle　notifications　generated　by　the　TaskManagement　MBean　
boolean　newtaskReceived　=　false;　
Object　parms[]　=　null;　
　public　void　handleNotification(Notification　ntfyObj,　Object　handback)　{　
　
　　　　　　System.out.println("****　next　notification　starts　here　
　　　　　　　　　　　　　　　　******************");　
　　　　　　System.out.println("type　　　=　"　+　ntfyObj.getType());　
　　　　　　System.out.println("userData　=　"　+　ntfyObj.getUserData());　
　
　　　　　　if　(ntfyObj.getType().equals("websphere.taskmanagement.tasknew")){　
　　　　　　　　newtaskReceived　=　true;　
　　　　　　　　String　taskID　=　ntfyObj.getUserData().toString();　
　　　　　　　　//　assume　format　of　user　data　for　a　new　task　is　always{task.id=nnnnnnnnnn}　　　　　　
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|　
|--------　XML　error:　The　previous　line　is　longer　than　the　max　of　90　characters　---------|　
　　　　　　　　taskID　=　taskID.substring(9,(int)　taskID.indexOf("}"));　
　　　　　　　　Long　taskLong　=　new　Long(taskID);　
　　　　　　　　Object　parmsTemp[]　=　{taskLong};　
　　　　　　　　parms　=　parmsTemp;　
　　　　　　}　
　
　　　　　　if　(newtaskReceived){　
　　　　　　　try　{　
　　　　　　　　　　　String　type[]　=　{"long"};　
　　　　　　　　　　　Object　taskState　=　adminClient.invoke(taskManagement,　
　　　　　　　　　　　　　　　　　　　　　"getCurrentState",　parms,　type);　
　　　　　　　　　　　Object　actionPlan　=　adminClient.invoke(taskManagement,　
　　　　　　　　　　　　　　　　　　　　　"getActionPlan",　parms,　type);　
　　　　　　　　　　　Object　displayTask　=　adminClient.invoke(taskManagement,　
　　　　　　　　　　　　　　　　　　　　　"getTask",　parms,　type);　
　　　　　　　　　
　　　　　　　　　　　//Send　the　information　to　System　Out　
　　　　　　　　　　　System.out.println("Task　State:　　"　
　　　　　　　　　　　　　　　　　　　　　+　taskState.toString());　
　　　　　　　　　　　System.out.println("Action　Plan:　"　　
　　　　　　　　　　　　　　　　　　　　　+　actionPlan.toString());　
　　　　　　　　　　　System.out.println("Task:　　　　　"　
　　　　　　　　　　　　　　　　　　　　　+　displayTask.toString());　
　　　　　　}

当创建一个任务并对它采取操作时，将生成一系列 TaskManagement 通知。如果由于违反监督运行状态策略生成了一个任务，则成功执行操作计划的一系列通知将如下所示：

type=websphere.taskmanagement.tasknew ...userData={task.id=n}

type=websphere.taskmanagement.taskstatechange ...userData={task.id=n, task.state=1

type=websphere.taskmanagement.taskstatechange ...userData={task.id=n, task.state=6}

type=websphere.taskmanagement.taskstatechange ...userData={task.id=n, task.state=13}

type=websphere.taskmanagement.taskstatus ...userData={task.id=n, task.status=30}

type=websphere.taskmanagement.taskstatus ...userData={task.id=n, task.status=30}

下表介绍了 task.state 值的含义。从表中可以看出，任务的状态从“New”转为“In Progress”，进而转为“Succeeded”。（请注意，不保证这些值在 WebSphere XD 的各版本之间都相同。在每个 WebSphere XD 新版本中使用这些值时，应重新验证自定义管理客户端。）


表 2. 任务状态和状态值的含义

通知类型值值的含义
taskstatechange task.state1New
2Renewed
3Expired
4Denied
5Suppressed
6In Progress
7In Progress Preview
8Previewed
9In Progress Commit
10In Progress Rollback
11Closed
12Failed
13Succeeded
14Unknown
taskstatus10Failed
20Completed with errors
30Completed
40Unknown

为满足与任务相关的操作要求，操作计划包括需要执行的一个或多个步骤。对于应用程序放置类型任务，典型的操作计划仅包括启动另一服务器这一个步骤。对于运行状态策略，可用于多数策略类型的操作是“重新启动服务器”。它们的操作计划将包括两个步骤：停止服务器，然后启动服务器。但停止/启动步骤的顺序以及启动哪台服务器取决于问题服务器是否为动态集群的一部分。如果是动态集群的一部分，则操作计划步骤的顺序将是启动动态集群的另一成员，然后停止问题服务器。如果不是动态集群的一部分，则操作步骤的顺序将是先停止问题服务器，然后重新启动问题服务器。

有两个运行状态策略可以被配置为具有多个“重新启动服务器”操作。可以将“过多请求超时”条件配置为“创建线程转储”，将“内存条件：内存溢出”条件配置为“采用 JVM 堆转储”。如果将这些操作中的任一操作与“重新启动服务器”操作一起配置，则结果操作计划将包括三个步骤。第一步创建转储，第二和第三步停止和启动服务器。

图 3 显示了运行上述示例代码的结果，其中显示了“内存条件：内存溢出”条件的结果。运行状态策略的操作被配置为“重新启动服务器”和“采用 JVM 堆转储”。在这些结果中，标注标识了一些需要关注的信息。我们可以看到这是生成新任务时产生的通知，下面是任务操作计划的三个步骤：

采用堆转储。

启动包含问题服务器的动态集群的另一成员。被启动服务器的名称为 MicroDC_rhaalab5Node06。

停止问题服务器。问题服务器的名称为 MicroDC_rhaalab5Node05。

注意，生成任务的原因是内存溢出这一条件。

在将这些条件报告给监视工具时，自定义管理客户端可能分析下面的消息以提取关键信息，如节点、服务器名称和进行中的操作。然后客户端可能将这些目标信息发送到监视控制台。根据消息的不同，可能将事件记录为信息性事件（如果启用了此级别的监视）或者标记为警报条件事件（如类似内存溢出的事件）。

我们可以决定将上一节中讨论的正常进程状态（停止、启动、失败等）信息与 WebSphere XD 启动的特定操作的覆盖范围合并在一起。通过监视这两组数据，操作团队可以看到 WebSphere XD 启动的操作与结果进程活动之间的因果关系，还可以注意到 WebSphere XD 检测到的任何运行状态问题。


图 3. 内存溢出测试结果
监视 IBM WebSphere Extended Deployment 环境

在 WebSphere XD 监视环境中使用 Tivoli 产品

我们已经讨论了自定义管理客户端如何从 WebSphere 环境接收信息，但客户端如何进一步将这些信息推送到监视工具呢？

大多数商业监视工具都为外部代理（如我们的自定义管理客户端）提供了接口，以便将信息反馈给系统。这些接口多种多样，而且许多产品都提供了用于通过外部代理发送警报的多种技术。

例如，IBM Tivoli® 产品系统支持与外部代理的多种通信协议。Tivoli Enterprise Console 和 Tivoli NetView 提供了 SNMP 接口，自定义管理客户端可以通过这些接口报告此类事件。Tivoli Monitoring 还提供了一组用于此目的的 C++ API。Tivoli Enterprise Console 还支持通过 Event Integration Facilities 发送警报。Tivoli Enterprise Console 还支持来自外部源的通用基本事件 (Common Base Event) 通知。有关更多详细信息，请参阅 Tivoli Enterprise Console 3.9.0 Feature Option 1。

其他 Tivoli 产品（如 IBM Tivoli Composite Monitoring for WebSphere、Tivoli Enterprise Portal 和 Tivoli Enterprise Console）还可以在不需要自定义管理客户端的情况下监视 WebSphere Application Server 环境，但目前这些产品中没有提供对 WebSphere XD 的特定支持。

WebSphere XD 可视化日志

可视化数据服务是 WebSphere XD 中的一项功能，可用来帮助监视 WebSphere XD 环境。在启动该服务后，将在日志文件中记录属于运行 WebSphere XD 环境的大量历史数据。

作为 WebSphere XD 监视环境的一部分，可以编写一个程序来检测这些日志文件，并报告重要的信息或事件。本文重点介绍了 Java 进程监视，在 Java 中，最需要关注的日志文件也许就是名为 ServerStatsCache.log 的日志文件。对于每个进程，此日志文件均包含以下信息：CPU 使用率、内存使用率、工作负荷管理平衡因素、响应时间和吞吐量。

下面显示了 ServerStatsCache.log 文件内容的一个示例。第一行是逗号分隔的标题，下面是数据栏。在本示例中，为便于阅读，已将第一行手动编辑为两行。日志文件中的每个条目都占一行，由 13 位数字组成的时间戳开头，并包含逗号分隔的数据。（为便于阅读，其中有几个条目已被手动从一行编辑为多行。）

timeStamp,name,node,version,weight,cpu,usedMemory,uptime,totalRequests,　
updateTime,highMemMark,residentMemory,totalMemory,　
db_averageResponseTime,db_throughput,totalMethodCalls　
　
1141845150078,server1,isswblade12Node01,XD　6.0.1.0,1,0.6611662872285986,　
　　　　　　　　　　　42217,1114274,21,1141845128199,,167371,167409,,,497　
1141845150078,MyDynamicCluster_isswblade12Node01,isswblade12Node01,XD　6.0.1.0,　
　　　　　　　0,,,,,1141845119548,0.0,,,,,　
1141845150078,ODRServer1,isswblade11Node01,,1,,,,,1141845119548,,,,,,　
1141845150078,server1,isswblade13Node01,,0,,,,,1141845119548,,,,,,　
1141845150078,MyDynamicCluster_isswblade13Node01,isswblade13Node01,,0,,,,,　
　　　　　　　1141845119548,0.0,,,,,1141845165088,server1,isswblade12Node01,XD　6.0.1.0,　
　　　　　　　1,0.6624458147699341,42648,1114289,24,1141845143220,,167684,167722,,,511　
1141845165088,MyDynamicCluster_isswblade12Node01,isswblade12Node01,XD　6.0.1.0,　
　　　　　　　0,,,,,1141845134549,0.0,,,,,　
1141845165088,ODRServer1,isswblade11Node01,,1,,,,,1141845134549,,,,,,

在启用任何日志记录时，请考虑对响应功能的影响，并制定一个计划来维护可用的磁盘空间。

结束语

IBM WebSphere Application Server Network Deployment 和 IBM WebSphere XD 的 JMX 功能提供了正确监视环境的洞察能力。它们还可以共享对操作小组有用的放置信息和运行状态策略信息。通过构建自定义的管理客户端，有助于筛选此信息，并将警报转发到监视解决方案。

Tags：监视 IBM WebSphere

编辑录入：爽爽　[复制链接] [打 印]
更多精彩
赞助商链接

热点阅读
焦点图片
最新推荐
精彩阅读