原文：http://www.ibm.com/developerworks/cn/java/j-jmx3/index.html
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 代理方面的细节还悬而未决（在写本文时是这样的）。
扫一扫
2470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
