JMX 是一种流行的、对 Java 平台新的标准扩展，它支持通过现代的网络管理系统（NMS）来管理、控制和监控设备、应用程序和服务。为了更好地洞察 JMX 是如何方便软件应用程序／设备的管理，我们将通过使用实际的 OpenNMS 开放源码 NMS 来试图监控 ClickMeter 应用程序（本系列 第 2 部分 中 所开发的应用程序）。我之所以选择 OpenNMS 是因为它具有广泛开放的可用性，以及它在设计上的简单性。您也可以将本文将所描述的集成技术应用到其它 NMS 产品。在讨论 OpenNMS 的具体细节之前，让我们先看一下大多数 NMS 产品所共有的一些常见设计元素和运作模型。
在本系列的 第 1 部分 中，我们通过现代联网的历史追溯了 NMS 的变革。由于网络管理用户群体的多样性（以及解决方案厂商的沿袭性），现代 NMS 产品越来越趋向成为最大和最复杂的软件系统。例如，与需要在同一个州或同一个省内管理其跨部门的虚拟专用网（VPN）、PC 资产、数据通信资产和应用程序服务器的地区性企业相比，通过一组分布式操作中心来管理和监控其电信网络设备的跨国组织的需求将有很大的不同。
典型 NMS 必须管理数千、数万，或者甚至数十万个端点（节点）。NMS 的目标客户往往是中型或大型组织。由于每个客户所做的业务可能各不相同，所以 NMS 必须具备高度可适用性的配置机制和用户界面以满足客户的各种需求。另外，许多早期的 NMS 解决方案都是那种专有的以黑盒控制为主的控制台 ― 在过去的某段时期，这正是这些解决方案的各个供应商（IBM、HP 和 Sun 等）在该业务上保持竞争力的关键所在 ― 您会感触到这种系统的复杂性。然后，您也许会明白为什么典型的 NMS 解决方案成本都很高。
OpenNMS 是一种开放源码软件系统。其目的在于，向开发社区免费地提供可执行文件和源代码，它可以适用于复杂但具有适用性的 NMS 解决方案。请参阅 参考资料 ，其中有关于详细信息的链接，另外还包括下载 OpenNMS 最新版本的链接。也可参见侧栏“ OpenNMS 的简史 ”，其中描述了这个系统的起源。
由于 OpenNMS 自从诞生之日起就不存在历史遗留问题（即，它不是源自“黑箱”式的厂商），所以它采用了相当新颖的设计方法。OpenNMS 是一个“以用户为中心”的 NMS，它将典型的网络管理员（或网络管理团队）作为自己唯一关注的焦点，以此来决定所需要的功能。最初，团队中一些成员来自网络管理顾问，他们把自己的 知识很好地付诸于实践 ― 围绕网络管理员通常所关注的对象、任务和工作流来定义其运作模型。这与一些商业 NMS 产品（这些产品因其厂商的沿袭性而通常以设备、网络或软件服务为中心）形成了对比。
如果不考虑其具体应用的领域、代码沿袭或厂商，许多 NMS 产品在层次组成上都有类似的概念。图 1 显示了这种常见的组成。
这个组成通常有三层。前端这一层与管理的设备和服务的网络、使用该系统的用户和外部系统连接在一起。中间这一层包含大量逻辑，这些逻辑提供了 NMS 各种特性。后端这一层负责保存和操作数据。
由于要动态（但还要健壮）地跟踪复杂的相互关系和大量信息，NMS 在后端这一层不可避免地部署了商业级关系数据库管理系统（RDBMS）。
在第一层内，监控、管理和控制组件通常包含许多必须在 NMS 操作期间执行的并发任务。第一层负责发现活动网络，轮询服务和设备是否出故障，以及截获或处理来自设备、服务或更高层分布式代理的异步事件。这个组件还可以执行由 NMS 中间层中的配置逻辑、供应逻辑、工作流执行器或其它定制逻辑所驱动的操作。
在前端这一层还有用户界面组件。NMS 可以有“胖客户机 GUI”界面，以及易于定制的基于 Web 的用户界面。报表工具驻留在这一层，它可以与 UI 交互以提供实时的软拷贝报表和批处理形式的硬拷贝报表。
第一层中的外部接口组件可以处理给用户和／或外部系统的通知。这可以采取寻呼、电子邮件、电话或发给外部管理系统的特定事件等形式。API 和扩展插件基础结构使得可以定制 NMS，以及将 NMS 与其它系统连接在一起，或者将 NMS 与其它系统集成。
中间层是 NMS 逻辑所在之处。它向 NMS 提供个性化以及与众不同的特性集合。还提供一些常见的特性，譬如，库存或资产管理、数据收集和分析、用户或角色管理以及工作流管理／执行。
库存（或资产）管理是大多数 NMS 产品的主要功能。但其中所跟踪的项目随不同的 NMS 而各不相同，譬如设备、线路、服务器、安装的软件服务和应用程序等。该组件的用户界面和应用程序逻辑必须能灵活地适应可能要管理的各种项。
数据收集和分析特性可以提供有关所管理设备和服务的当前和历史统计。它还可以提供统计分析，从而揭示网络和子网的性能以及设备／服务的可用性等。该组件还可以与工作流执行逻辑交互以处理定制的工作流。
用户和角色管理组件提供对 NMS 不同级别的访问。大多数大型网络是由一个团队或多个团队的人员来管理的。分配给用户的角色可以用在定制安全策略的设计和实现中，以及定制的工作流和事件升级流中。
工作流管理和执行是针对短期和长期管理任务的管理和自动执行而提供的。为了使 NMS 适应不同组织对各种业务的需求，定制自动化工作流是有必要的。
虽然并不是每个 NMS 都会具备所有这些组件 ― 甚至有些可能会有其它更专门化的变体 ― 但这里所提到的组件已足够用来概述 NMS 的组成部分。
将 图 1 作为参考，可以在供参考的组成与 OpenNMS 体系结构之间作具体的比较。图 2 显示了构成 OpenNMS 的各组件。
在后端这一层，OpenNMS 使用 PostgreSQL（请参阅 参考资料 ）作为它的 RDBMS。在前端这一层，它使用 Apache Jakarta Tomcat（请参阅 参考资料 ）免费的 JSP 和 servlet 技术来提供灵活的可定制的用户界面。也可用以前基于 Perl 的用户界面。有几个管理实用程序是用 UNIX shell 脚本和 Perl 编写的。OpenNMS 使用一套与 图 1 中的监控、管理和控制组件相对应的并发 Java 任务来提供该功能。在图 2 中用圆圈表示的就是这些并发任务。
OpenNMS 的监控、控制和数据收集特性是由一组称为守护程序（BSD UNIX 约定）的并发任务来处理的。表 1 统计了这些并发管理任务，图 2 中也描述了这些任务。
| 并发任务 | 守护程序名称 | 描述 |
| 操作守护程序 | actiond | 自动操作执行工具，用于根据入站事件自动操作（工作流）。 |
| 收集守护程序 | collectd | 从受管节点收集数据。 |
| 功能守护程序 | capsd | 对所发现的节点执行功能检查。它通常检查某个接口的端口，看它是否支持已知的服务协议。 |
| DHCP 守护程序 | dhcpd | 为 OpenNMS 提供 DHCP 客户机功能。 |
| 发现守护程序 | discovery | 对受管网络节点进行初始的发现以及持续进行定期发现。 |
| 事件管理器守护程序 | eventd | 管理来自其它并发任务的事件，并将它们存储到 RDBMS |
| 通知守护程序 | notifd | 向用户执行外部通知。 |
| 故障管理器守护程序 | outaged | 合并事件，以为每个受管节点／服务提供持续的历史故障视图。 |
| 轮询器守护程序 | pollerd | 定期轮询受管节点／服务，以决定操作状态。 |
| RTC 管理器守护程序 | rtcd | 实时收集数据，为用户定义的各类受管节点／服务提供可用性信息。 |
| SNMP 陷阱守护程序 | trapd | 处理 SNMP 陷阱（事件）。 |
| 阈值服务守护程序 | threshd | 根据属性值是否达到指定的阈值来监控受管节点／服务。 |
在 OpenNMS 前端这一层，使系统适应特定垂直应用程序领域变得非常简单。这要感谢 JSP 技术的灵活性，Java 开发人员可以很容易地定制 OpenNMS 的用户界面。通过组合 JSP 文件和／或 servlet 编码，也可以方便地添加新的 NMS 应用程序逻辑。
OpenNMS 带有健壮的、用于受管设备／服务的 SNMP 支持。SNMP 是目前业界用于可管理设备／服务事实上的标准。该标准使 OpenNMS 可以管理大量在 TCP/IP 网络上存在的设备。
在 SNMP 之外，OpenNMS 还可以检测和管理现在流行的软件服务（FTP、文件服务器和数据库服务器等）。它提供了一套特定于服务的插件（用于协议扫描）和监控程序（用于轮询）来完 成这些任务。通过创建新的插件和监控程序，可以扩展 OpenNMS 以检测和监控任何新的设备或服务 ― 包括支持 JMX 的 ClickMeter 应用程序。
OpenNMS 的发现守护程序（ discovery ）负责在初始以及以后的执行过程中发现受管网络。一旦 discovery 发现一个节点（通常通过 ICMP ping），它会请能力守护程序（ capsd ）来确定该节点支持什么服务。通过对指定的协议插件集合进行循环处理，该功能守护程序检查所支持的服务。编写一个定制的协议插件使它适合 OpenNMS 的任何新服务非常简单。所涉及的步骤为：
1. 创建一个实现 org.opennms.netmgt.capsd.Plugin 接口的类。这里特别指出的是，这个接口有三个插件必须实现的方法，请参见表 2：
表 2. 接口 org.opennms.netmgt.capsd.Plugin 的方法
| 方法名称和说明 | 描述 |
String getProtocolName(); | 返回创建这个插件所针对的协议名称。 |
Boolean isProtocolSupported(java.nnet.InetAddress address); boolean isProtocolSupported(java.nnet.InetAddress address, java.util.Map properties); | 使用所提供的用于传入的参数的特性映射（如果必要的话）来确定所指定的 InetAddress 是否支持该协议。 |
2. 在 /etc/capsd-configuration.xml 文件中创建协议插件定义。在启动期间， capsd 将读取这个文件，以确定使用哪个协议插件。
我们不久将会看到如何编码和配置 OpenNMS 协议插件的详细信息。
在 OpenNMS 确定了受管节点上的服务之后，它将使用轮询器守护程序（ pollerd ）来定期轮询受管设备／服务，以确保它们是可操作的。通过对轮询器监控程序“插件”的指定集合进行循环处理， pollerd 对个别服务进行轮询。为了给新协议创建轮询器监控程序，需要：
1. 创建实现 org.opennms.netmgt.poller.ServiceMonitor 接口的类。这里特别指出的是，这个接口有五个监控程序必须实现的方法，请参见表 3：
表 3. 接口 org.opennms.netmgt.poller.ServiceMonitor 的方法
| 方法名称和说明 | 描述 |
void initialize(java.util.Map parameters); void initialize(org.opennms.netmgt.poller.NetworkInterface iface); | 在启动期间，调用第一种形式，使插件在初始化期间有机会禁用自己（通过抛出异常）。每当发现新的、支持该服务的节点，并在第一次调用 poll() 之前，都调用第二种形式。 |
void release(); void release(java.net.NetworkInterface iface); | 在 OpenNMS 关闭期间，调用第一种形式。每当从以后的轮询调度表中除去所发现的、支持该服务的节点时，都调用第二种形式。 |
int poll(java.net.NetworkInterface iface, org.opennms.netmgt.utils.EventProxy eproxy, java.util.Map parameters); | 这是用于确定正在被监控的服务是否仍然可用的方法。它应该返回 ServiceMonitor. SERVICE_AVAILABLE 以表示服务正在运行，否则将返回 ServiceMonitor. SERVICE_UNAVAILABLE 。 |
2. 在 /etc/poller-configuration.xml 文件中创建服务定义和监控程序定义。这是 pollerd 在启动期间将读取的文件，以确定轮询每个服务的间隔时间，以及在操作期间所使用的监控程序“插件”。
我们接下来将为 ClickMeter 创建轮询器监控程序。
使用 OpenNMS 来监控支持 JMX 的 ClickMeter
现在我们知道创建 capsd 插件和 pollerd 监控程序使我们能将 OpenNMS 与支持 JMX 的 ClickMeter 集成在一起。然而，还有一个问题：为什么 OpenNMS 不是以本机方式支持 JMX ？
即使在一些流行的商业 NMS 产品中，您会发现同样具有这一普遍趋势 ― 也没有以本机方式支持 JMX。部分原因是由于存在这样的事实：刚出现支持 JMX 的设备和服务，另外 SNMP 的兼容性已足够管理大多数“第三方设备和服务”（它们不是出自 NMS 厂商）。
还有一个重要的原因是，在 NMS 厂商中，JMX 的集成进度相对比较缓慢：即使 1.1 规范已经详细定义了 JMX 工具层和代理层，但就如何跨网络来访问 JMX 代理方面的细节还悬而未决（在写本文时是这样的）。
网络管理应用程序或分布式服务可以通过 远程 JMX（JMX Remoting） 的方式跨网络地访问 JMX 代理，远程 JMX 也是 JSR 160 的主旨所在（请参阅 参考资料 ）。远程 JMX（JMX Remoting）也是即将发布的 JMX 1.2 参考实现发行版的新的主要特征。
JSR 160 将详细说明在一个网络上应该如何执行 JMX 代理的发现以及远程访问代理能力的具体方式。这将包括一些有关所使用的协议适配器的具体细节。在最终完成远程 JMX 1.2 规范之前（很可能在 2003 年发布），我们必须寻找一种在 OpenNMS 和用来管理 ClickMeter MBean 的 JMX 代理之间进行通信的替代方法。
当然，JMX 代理的主要目的之一是提供对它所管理 JMX MBean 的远程访问（虽然，可以将某些 JMX 代理设计成增值服务，可能不会公开它们所有的受管 MBean）。正如在本系列 第 2 部分 中所讨论的，代理可以使用连接器和协议适配器来与 NMS 应用程序或分布式服务进行通信。
在 ClickMeter 这种情况中，我们使用 JMX 参考实现中的一个简单的代理，这个实现包括了一个 HTTP 协议适配器。这个简单的代理通过 HTTP 协议适配器公开它管理的所有 MBean 的属性和操作。
可以方便地使用 JMX 参考实现中的这个简单代理和 HTTP 协议适配器来进行 OpenNMS 和 ClickMeter MBean 之间的通信。图 3 显示了我们所提议的通信方法。在操作期间，OpenNMS 的 capsd 将扫描已检测到的节点，以确定是否支持“CLICKMETER”服务。轮询器守护程序 pollerd 将定期轮询已检测到的服务以确保它们是可操作的。为了提供这两种探测，可以使用由 ClickMeter MBean 公开的 incPanelValue 操作。使用 incPanelValue 作为探测机制所带来的好处是我们能够以可视化的方式看见 OpenNMS 的检测和轮询操作。每一次探测会使 ClickMeter 的值递增。
然后，唯一剩下要做的是，确定如何使用 HTTP 协议适配器来访问对 ClickMeter MBean 的 incPanelValue 操作。可以使用浏览器来访问 JMX 代理，其中 URL 为：
http://<host of agent>:8082/ |
当然，在做这之前，请确保该代理正在运行。（如果您需要重新温习如何去做，请参阅本系列的 第 2 部分 ）。然后，单击按钮，尝试执行已公开的 incPanelValue 操作。您应该看到类似于图 4 的页面。
在图 4 中，请注意用来访问该操作的所使用的 URL 为：
http://<host of agent>:8082/InvokeAction//MBean:name=ClickMeter/ action=incPanelValue?action=incPanelValue |
还要注意，如果 ClickMeter 应用程序运行正确，产生的页面将包含短语 incPanelValue Successful 。我们将用该信息来从 OpenNMS 远程地访问 MBean。
现在准备将新的“CLICKMETER”服务集成进 OpenNMS。要做到这一点，将创建用于功能守护程序（ capsd ）的插件和用于轮询器守护程序（ pollerd ）的监控程序。
用于 OpenNMS 发现的 ClickMeterPlugin
在源码分发中提供了功能守护程序插件的代码，它在 org.opennms.netmgt.capsd.ClickMeterPlugin 类中。我们知道该插件必须实现 org.opennms.netmgt.capsd.Plugin 接口。清单 1 显示了从 AbstractPlugin 派生而来的这个类。这个 OpenNMS 所提供的抽象类提供了两个抽取参数的方法（ getKeyedInteger() 和 getKeyedString() ），这两个参数对我们的编码会有帮助。
public final class ClickMeterPlugin extends AbstractPlugin {
private static final String PROTOCOL_NAME = "CLICKMETER";
private static final int DEFAULT_PORT = 8082;
private final static int DEFAULT_RETRY = 0;
private final static int DEFAULT_TIMEOUT = 5000; // in milliseconds
|
清单 2 中代码是 getProtocolName() 方法很普通的实现：
public String getProtocolName() {
return PROTOCOL_NAME;
}
|
清单 3 中的代码是 isProtocolSupported() 方法很简短的实现：
清单 3. isProtocolSupported() 方法
public boolean isProtocolSupported(InetAddress address) {
return isClickMeter(address, DEFAULT_PORT, DEFAULT_RETRY, DEFAULT_TIMEOUT);
}
|
在 isProtocolSupported() 方法的长版本中，我们处理传入的参数以用于构造访问远程 JMX 代理的 URL。一旦从这些参数中获得了 IP 和端口，则 isProtocolSupported() 调用 isClickMeter() 方法以确定该节点上的 ClickMeter 是否处于活动状态。清单 4 显示了 isClickMeter() 代码。注意：为 URL 而定义的两个常量对应于用于 ClickMeter incPanelValue 操作所需的 HTTP 协议适配器访问 URL。
private final static String CLICK_METER_BEAN_LOCATOR_URL =
"/InvokeAction//MBean:name=ClickMeter/action=incPanelValue?
action=incPanelValue";
private final static String CLICK_METER_ID = "incPanelValue Successful";
private boolean isClickMeter(InetAddress host, int port,
int retries, int timeout) {
Category log = ThreadCategory.getInstance(getClass());
boolean foundClickMeter = false;
for (int attempts=0; attempts <= retries && !foundClickMeter;
attempts++)
{
URL jmxLink = null;
InputStream iStream = null;
try {
String hostIP = host.getHostAddress();
jmxLink = new URL("http", hostIP, port,
CLICK_METER_BEAN_LOCATOR_URL);
if (scanURL(jmxLink, CLICK_METER_ID, log)) {
foundClickMeter = true;
break; // get out of the for loop
}
}
catch(IOException e) {
log.info("ClickMeterPlugin: Error communicating
with host " + host.getHostAddress(), e);
foundClickMeter = false;
}
}
return foundClickMeter;
}
|
清单 5 中所显示的 scanURL() 方法是一个助手方法，它可接受作为参数的 URL 和字符串。然后，访问这个 URL，并在产生的页面中搜索所指定的字符串。如果找到该字符串，则返回 true 。否则，返回 false 。在这里，在访问用于 ClickMeter 的 incPanelValue 操作的 URL 之后，查寻 incPanelValue Successful 字符串。
private boolean scanURL(URL inURL, String toSearch, Category log) {
InputStream iStream = null;
try {
iStream = inURL.openStream();
BufferedReader urlReader =
new BufferedReader(new InputStreamReader(iStream));
String curLine = urlReader.readLine();
do {
if (curLine.indexOf(toSearch) != -1) {
return true;
}
curLine = urlReader.readLine();
} while (curLine != null);
}
catch (IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
Error reading from URL:"
+ inURL, e);
}
finally {
try {
if(iStream != null)
iStream.close();
}
catch(IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
Error closing stream to URL.", e);
}
}
return false;
}
}
|
集成该插件所需的第 2 步将编辑 <OpenNMS 安装目录 >/etc/capsd-configuration.xml 文件，并添加清单 6 中所显示的 protocol-plugin 定义：
<protocol-plugin
protocol="CLICKMETER"
class-name="org.opennms.netmgt.capsd.ClickMeterPlugin"
scan="on" >
<property key="port" value="8082"/>
<property key="timeout" value="2000"/>
<property key="retry" value="1"/>
</protocol-plugin>
|
您可能还希望编辑 discovery-configuration.xml 文件以限制 OpenNMS 扫描受管节点的 IP 范围。在清单 7 中，我们将其限制为两个节点，这样可以快速地找到 ClickMeter 应用程序：
<include-range retries="2" timeout="3000">
<begin>192.168.23.75</begin>
<end>192.168.23.76</end>
</include-range>
|
用于 OpenNMS 的 ClickMeterMonitor
接下来，创建轮询器守护程序（ pollerd ）监控程序插件： org.opennms.netmgt.poller.ClickMeterMonitor 类。该类必须实现 org.opennms.netmgt.poller.ServiceMonitor 接口。OpenNMS 提供了一个基类（ org.opennms.netmgt.poller.IPv4Monitor ），这个接口中的所有方法都有缺省实现。因为不需要任何特殊的初始化或资源释放，所以只需要覆盖 poll() 方法，如清单 8 所示：
public int poll(NetworkInterface iface, Map parameters) {
if(iface.getType() != NetworkInterface.TYPE_IPV4)
throw new NetworkInterfaceNotSupportedException("Unsupported
interface type, only TYPE_IPV4 currently supported");
Category log = ThreadCategory.getInstance(getClass());
int retry =
getKeyedInteger(parameters, "retry", DEFAULT_RETRY);
int port =
getKeyedInteger(parameters, "port", DEFAULT_PORT);
int timeout =
getKeyedInteger(parameters, "timeout", DEFAULT_TIMEOUT);
InetAddress ipv4Addr = (InetAddress)iface.getAddress();
String hostIP = ipv4Addr.getHostAddress();
if (log.isDebugEnabled())
log.debug("ClickMeterMonitor.poll: Polling interface: "
+ hostIP + " timeout: " + timeout + " retry: " + retry);
int serviceStatus = ServiceMonitor.SERVICE_UNAVAILABLE;
for (int attempts=0; attempts <= retry && serviceStatus !=
ServiceMonitor.SERVICE_AVAILABLE; attempts++) {
URL jmxLink = null;
InputStream iStream = null;
try {
jmxLink = new URL("http", hostIP, port,
CLICK_METER_BEAN_LOCATOR_URL);
if (scanURL(jmxLink, CLICK_METER_ID, log)) {
serviceStatus = ServiceMonitor.SERVICE_AVAILABLE;
break; }
}
catch(IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
IOException while polling address: "
+ ipv4Addr, e);
}
} // of for
return serviceStatus;
}
|
注意清单 8 中访问 ClickMeter MBean 的 scanURL() 助手方法的用法。
在 <OpenNMS 安装目录 >/etc/poller-configuration.xml 文件中，必须添加一条 service 定义项。在清单 9 中，将指定轮询间隔时间为 10000 毫秒（或 10 秒）：
<service name="CLICKMETER" interval="10000"
user-defined="false" status="on">
<parameter key="timeout" value="3000"/>
<parameter key="port" value="8082"/>
</service>
|
在同一个 poller-configuration.xml 文件中，我们还应该插入 monitor 定义，如清单 10 所示：
<monitor service="CLICKMETER" class-name="org.opennms.netmgt.poller.ClickMeterMonitor" /> |
为了从源代码构建这两个插件，我们使用了所提供的 compile.bat 文件。您需要将几个 OpenNMS 库文件复制到 < 文章代码分发 >/lib 目录（有关详细信息，请参阅 README.txt 文件）。compile.bat 文件将创建 dwClickMeterJMX.jar 。将这个产生的 JAR 文件放入 <OpenNMS 安装目录 >/lib 目录，OpenNMS 在启动时会自动装入这个新插件。
为了用 ClickMeter MBean 测试 OpenNMS，首先启动正在受管理节点上的 ClickMeter 实现之一（来自本系列的 第 2 部分 ― 标准、动态或模型 MBean）。接下来，重新启动 OpenNMS。通常通过重新引导系统或使用 <OpenNMS 安装目录 >/bin/opennms.sh 脚本来做到这一步。
通过访问 OpenNMS 的基于 Web 的 GUI 来确信 OpenNMS 系统已经启动。通常，URL 为：
http://<host of OpenNMS>:8080/opennms/ |
当出现提示时，在 userid 这一栏填写 admin ，在 password 这一栏填写 admin 。图 5 显示了成功启动后的 GUI：
在 OpenNMS 启动期间，您应该看到 ClickMeter 计数快速地增加了两次（一次是由 capsd 扫描引起的，另一次是由初始的 pollerd 轮询引起的）。然后，当 pollerd 开始工作后，ClickMeter 将每隔 10 秒定期地增加其计数。
一旦 capsd 检测到 ClickMeter 应用程序，则将 ClickMeter 添加到 RDBMS，作为一个受管服务。在生产中，可以使用 OpenNMS 的资产管理特性来进一步分类和标记该服务。对于我们这个实验，可以使用 OpenNMS GUI 来深入研究 ClickMeter 服务，看所涉及事件的详细信息，如图 6 所示：
图 6. 管理 ClickMeter 服务的 OpenNMS
在这个系列中，我们回顾了网络管理从最普通的原始状态（作为“黑盒”设备控制终端仿真器）到目前角色（作为当今 IT 支持结构中的精髓要素）的变迁。现代的 NMS 是一个多层的、企业级管理系统，用它来控制、管理、提供和监控设备、计算机装置、通信线路和软件服务的大网络。
我们了解到了 JMX 是一项怎样的成熟技术，它使应用程序员和设备设计者快速地将工具添加到任何软件应用程序或服务中。所产生的这个工具是独立于管理协议和 NMS 的。一旦该工具到位，则可以通过几乎任何一种 NMS（它通过使用协议适配器和连接器）来管理和监控 JMX 设备。
JMX 规范正在制订当中。一旦更好地定义了远程 JMX 和 JMX 体系结构中的分布式服务层，则 JMX 可能成为分布式管理的基石 ― 尤其对于以后的 NMS 产品，这些产品将利用 Java 平台对 GUI 和 Web 应用程序开发的支持、健壮的 RDBMS 支持和“一次编写，到处运行”，这将不需要维护这些复杂系统的多种实现。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
