NMS开源软件选型分析评估报告

目录

1  标准和目标. 1

1.1 前言. 1

1.2 目标. 1

1.3 标准. 1

2  评估. 2

2.1 筛选. 2

2.1.1 候选软件. 2

2.1.2 License评估. 2

2.1.3 软件功能评估. 3

2.1.4 开发语言评估. 5

2.1.5 小结. 6

2.2 开发接口调查. 7

2.2.1 Nagios 7

2.2.2 Opennms 8

3  结论. 14

4  MISC 14

1    标准和目标

1.1   前言

目前开源的网管软件众多，时间关系只能通过网络上的资料介绍和其他用户的体验进行评估。对于重点调查的开源软件通过运行环境搭建、开发环境搭建的方法进行实践。

如果只是对通用网络设备的管理，被调研的软件只要经过适当的配置就可以满足要求。对于我们的需求，这些软件不能满足我们100%的需求，必须进行二次开发，对软件二次研发的接口的调研就成为我们考察软件的一个重要的组成部分。

部门对网管软件的定位应该不会投入过多的资金，商用软件价格高昂应该不在考虑范围之内，也尽量不选用开源软件商用版本，重点放在纯开源软件上。

选择了一种开源软件也就选择了一种架构，所以架构的选择也要适合我们部门的开发能力。

1.2   目标

选择一款适合的开源软件，在此基础上进行整合和二次开发，构建部门设备网管平台。

1.3   标准

选型标准：

²  License

不仅仅是免费，无license限制是首选；

²  市场占有率

广泛的市场占有率，说明软件得到过足够多的验证；针对于成功的开源软件，可以找到一些第三方的扩展资源，我们只要遵循拿来主义就好；

²  功能

一些功能可以直接拿来使用，或者简单的改造，可以节约成本；

²  完备的扩展开发接口

被选择的开源软件是否已经提供完备的二次开发接口，满足二次开发的要求；

²  开发技术

选择开源软件的另外一个层面考虑是尽量考虑使用部门成员最熟悉的开发技术，尽量避免涉及相对部门来说的新技术、开发语言，这样可以进一步研发降低成本；

²  开源架构

就我们目前的需求，开源网管软件的功能，我们能用到的部分并不多。选择了开源其实主要就是选择它的架构。架构的开放性，易扩展性将直接决定我们的研发成本。

2    评估

开源网管软件的市场占有情况

上图是网络监控软件的占有率。其中以Nagios和Opennms占有率最高。

2.1   筛选

2.1.1候选软件

²  Nagios

²  Opennms

²  Cacti

²  Zenoss

²  Zabbix

²  SugarNMS

2.1.2License评估

2.1.3软件功能评估

The NRPE addon is designed to allow you to execute Nagios plugins on remote Linux/Unix machines

2.1.4开发语言评估

2.1.5小结

关于license，Opennms的license网站描述如下

其他软件基本上都是在GPL限制下进行。如果我们选用了，在不付费的情况下就是涉及开放源码的问题。但也可以打擦边球“一个关于GPL重要的争议是，非GPL软件是否可以动态链接到GPL库”。

从市场占有率来讲，Nagios和opennms应用的比较广，也意味着更多的资料可以获取，更多的经验可以借鉴。

从开发语言来说，Nagios使用c开发，界面PHP，cgi也是由c来开发的，由于c的复杂性，扩展开发上存在一定的难度，但是c对我们部门来说还是比较熟悉的。Opennms是基于java的，Web管理界面是基于JSP/ Servlet，Spring MVC。

但是Nagios没有配置界面，配置需要直接修改配置文件。如果选用建议推翻所有目前的cgi方式的管理界面，全部重新开发，或者再结合其他的管理软件。

Cacti基于PHP，zenoss基于python，zabbix基于c和php，SugarNMS开源程度不够，所以不做过多调研。

从以上分析，倾向选择Nagios和opennms中的一种。

调研过程中分别搭建了Nagios和Opennms的运行环境。搭建了Opennms的开发环境，（Nagios的编译环境，源码包解压缩就是开发环境，无所谓搭建了）。在搭建Opennms的过程中遇到一点点麻烦。

Opennms的安装和编译环境搭建都比较费力，Opennms的编译环境依赖于Maven，eclipse的开发环境也需要花上一定的时间，尤其是公司的网络有诸多限制。

Nagios编译和部署非常的顺畅，可以下载源码包直接编译安装。

2.2   开发接口调查

基于上文中的调查，对于开发接口的调查只针对于Nagios和Opennms。

2.2.1Nagios

Nagios支持插件开发。支持C/C++,JAVA,脚本，并且有大量开发好的Plugins。

插件是编译的可执行文件或脚本（Perl脚本，shell脚本等），可以从命令行运行检查状态或一个主机或服务。 Nagios的插件的使用结果来确定网络上的主机和服务的当前状态。

Nagios在需要时执行Plugin检查服务或主机状态。

NRPE方式：

NRPE是一个插件，允许执行远程Linux/ Unix主机上的插件。如果需要监控远程主机上的资源和属性，如磁盘使用情况，CPU负载，内存使用等，需要使用这种方式。通过使用check_by_ssh插件可以实现类似的功能。

NSCA方式：

NSCA是一个插件，允许你发送被动检查结果从远程Linux/ Unix主机到Nagios监控服务器上运行的守护进程。在分布式和冗余/故障监测设置，这是非常有用的。

NDOUtils方式：

NDOUtils是一个插件，允许把所有状态信息存储在MySQL数据库中的Nagios。 Nagios的多个实例都可以存储在一个集中的报告的中央数据库的信息。这可能会作为一个新的基于PHP的未来的Nagios的Web界面的基础上。

Nagios提供了Nagios Plugin API。但是并没有提供除Nagios提供的功能外的其他功能的开发。添加新的服务需要阅读c代码，难度上相对比较大。基于这一点，Nagios并不能满足我们的要求。

2.2.2Opennms

Opennms是装配式的，支持根据配置装载服务和插件，扩展性很强。

上图为opennms的架构图，其中一些部分在最新版中有所变化。

下表是opennms并发的进程

支持总控/调度，发现，配置采集，性能采集，事件（告警）收集，轮询服务。通过在 service-configuration.xml配置需要的服务。

OpenNMS系统配置信息通过XML数据存储，基于linux系统和Postgres数据库的网络管理系统。网络数据通过JDBC对数据进行持久化，Web采用JSP/Servlet。OpenNMS是一个Open Source Framework，它采用了诸多的开源组件与框架，使用了各种协议的开源实现。每一个层面服务、功能都有自己的配置文件。

OpenNMS采用了xml数据绑定技术（opennms采用的是castor）。根据xml文件的schema定义文件（xsd文件）生成对xml文件到java对象的映射，这样就不需要写解析xml文件的代码而是针对java对象进行操作。因此这些类都是在系统编译过程中由castor包根据xsd文件生成的。(Castor是一个Java开源数据绑定框架，它主要目标是提供Java对象与XML 的绑定，Java到SQL的持久化等.)

Cleanimports是对java文件中的无用的imports作清理，并通过配置文件提供的格式对imports代码段进行格式整理。

各种单元测试手段，HttpUnit，jWebUnit，Junit。

 nekohtml解析HTML，Html Tidy对html 字符串进行修正，并做标准化的处理。

Avalon主要是一种Server的架构，可以满足配置、日志等服务器程序的需要。

Jdhcp,java DHCP的实现。

Xerces解析XML，API与实现有:xmlParserAPIs, xml-apis, xercesImpl。

 jCIFS，用Java开发的SMB客户端库。

 ldap-impl，LDAP java实现。

 smtp.jar pop3.jar，SMTP，POP3协议Java实现。

JRobin基于LGPL授权的网络性能监控系统，是RRDTool的一个纯Java实现。

joeSNMP，Java SNMP类库。

WebUI：

OpenNMS框架逻辑上采用了MVC架构，准确来说是JSP MVC Model 1，采用此架构的主要理念是尽量把逻辑与表示分离，这有利于系统健壮性，代码重用和结构清晰，便于重新设计，并长期维持。在OpenNMS中MVC各部分主要代表如下：

²  视图（JSP）

OpenNMS的页面通过Model请求回来的内容以HTML，XML/XSL，图表等形式呈现给客户端。

²  控制器（Servlet）

OpenNMS的控制器采用Servlet方式的，配置在web.xml文件中，用来接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。

²  模型(Bussiness Object/Java Bean)

模型表示企业数据和业务规则。模型允许重用相同的代码跨数个不同的用户界面组件。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

开发接口：

OpenNMS提供了一个简单快速的框架用来扩展设置缺省服务与协议，为了扩展OpenNMS管理一个可定制的服务或协议需满足如下要求：

以Caspd plugin为例

²  编写代码capsd plugin(插件)测试网络接口是否有支持期望的协议或服务

²  添加一个<protocol plugin>元素，在$OPENNMS_HOME的/etc/capsd-configuration.xml config定义新的服务。

²  编写代码poller插件，在某一特定的网络接口，监测当前期望的协议或服务的状态。

²  在$OPENNMS_HOME的/etc/capsd-configuration.xml config配置文件中添加<service>和<monitor>元素定义新的调用服务。

1.      编写Plugin

Capsd使用plugin执行设备的性能检测，一个Plugin是一个实现org.opennms.netmgt.capsd.Plugin接口的Java类。

下列接口中的方法必须实现：

public interface Plugin {

    public String getProtocolName();

    public boolean isProtocolSupported(InetAddress address);

    public boolean isProtocolSupported(InetAddress address, Map qualifiers);

}

在配置文件capsd-configuration.xml添加，比如FtpPlugin

<protocol-plugin protocol="FTP"

class-name="org.opennms.netmgt.capsd.plugins.FtpPlugin" scan="on">

        <property key="port" value="21" />

        <property key="timeout" value="20##" />

        <property key="retry" value="1" />

   </protocol-plugin>

在运行时，性能daemon调用isProtocolSupported()方法。此方法是每一加载的plugin通过它java.net.InetAddress对象的每一个被发现的守护daemon,发现任何支持此接口的服务将通过接结点标识符与IP地址增加到ifservices数据表中。

创建Poller Plugin

Poller daemon使用Poller Plugin轮询受管制接口所支持的服务当前状态。一个Poller Plugin是一个实现org.opennms.netmgt.poller.monitors.ServiceMonitor接口的Java类。实现下面的poller plugin接口。

public void initialize(java.util.Map parameters);

   

public void release();

public void initialize(org.opennms.netmgt.poller.NetworkInterface iface);

public void release(java.net.NetworkInterface iface);

public int poll(java.net.NetworkInterface iface,

              org.opennms.netmgt.utils.EventProxy eproxy,

              java.util.Map parameters);

在poller-configuration.xml中添加一个新的服务，<service>元素定义服务名称，多少时间间隔与预定时间，参数列表需定义在<parameter>元素中。配置参数将通过poll()方法中的java.util.Map传递给plugin

<service name="FTP" interval="300000">

              <parameter key="timeout" value="3000"/>

              <parameter key="port" value="21"/>

              <parameter key="userid" value="ftp"/>

              <parameter key="password" value="anonymous@"/>

</service>

在poller-configuration.xml文件中添加一个新的<monitor>元素，在这个元素中说明服务名称与类名：

<monitor service="FTP" class-name="org.opennms.netmgt.poller.FtpMonitor"/>

每一种服务都有自身plugin的开发接口，方便扩展。

2.      开发daemon

开发plugin只能在现有服务的基础上进行扩展，但要增加基础服务，就必须开发daemon一级的服务。

由于opennms是基于配置动态加载，我们可以模仿已有的daemon开发服务需要的服务进程。

当然这需要相关代码比较熟悉。

3    结论

基于这段时间调研，感觉opennms比较适合我们的需要。

Opennms前期需要投入一定的时间和人力进行调研，把相关层面的问题弄清楚。

由于开始选型时设定了一个范围，会遗漏重要的软件，只盯在网管开源软件这个领域，也可能会错过其他一些更加符合我们的需要的开源架构软件。

个人知识面的局限和偏执也会造成偏差。

4    MISC

如果部门决定选用opennms，那么下一步工作就是对opennms进行较为细致的实验。搭建实验环境。

规划功能和制定开发计划。

对开发接口进行实验。

调研数据存储，数据库部分。

然后就是功能裁剪。

重新整合并发进程。逐步研发并添加一些需要的功能进来。

对webUI部分进行改造，或者重新开发。