Over the past few weeks, I’ve written articles on Big Brother, MRTG and RRDtool, all free, open source network monitoring tools, which allow the administrator to properly maintain the computing environment.
The missing piece is a comprehensive, open source monitoring package capable of monitoring every aspect of your environment and presenting this data in a well-designed, Web-based interface. This product is OpenNMS.
In this Daily Drill Down, I'll give you the background on OpenNMS, go through a typical installation of the product, and explain how to set up a minimal configuration.
A group of network professionals created OpenNMS to provide organizations with a simple, full-featured network management platform that could quickly respond to change. You can download the free software from their Web site.
Unlike some other open source packages, the creators of OpenNMS extensively support the product by offering fee-based installation support, subscription-based support contracts, and other customer support options. They even travel the country giving one-day seminars on the product. They also offer an OpenNMS Green Light package, in which they supply an on-site engineer for one week to completely install and configure the OpenNMS product for your organization and to train a member of your staff to support the product.
Bear in mind these services cost money, though; for example, the Green Light support option is listed on the OpenNMS Web site at $17,995. However, many commercial and proprietary network-monitoring packages cost much more than that just for the software.
The feature set
So what can the OpenNMS system do for you? It can help you monitor the following services:
- SNMP (version 1 for data collection)
- Router (checks IPforwarding via SNMP)
- SQLServer (TCP)
- Informix (TCP)
- Sybase (TCP)
- Oracle (TCP)
- MS Exchange (relies on banners to identify Exchange servers)
The product offers a comprehensive Web interface to set up the monitoring and watch what's happening on your network.
How to get it
As of this writing, OpenNMS version 0.9.5 is available and can be downloaded from the OpenNMS Web site. While I generally prefer to build software from the source files, with OpenNMS, that was easier said than done. I ended up opting for the automated RPM installation. Note that the installation for OpenNMS is not for the weary; it's extremely complex, and there are dependencies galore to deal with.
In a typical installation, OpenNMS makes use of all the following packages (and more):
- A Java 1.3+ development environment
- PostgreSQL database servers
- Tomcat servlet server
- JBossmq Java server
- RRDTool graphing engine
Because OpenNMS is such as complex package, I installed it onto a freshly built Red Hat 7.1 server. For the installation type, I chose Server and made sure to install many of the development packages, especially tk, which is required by one of the PostgreSQL RPM installations.
The package also has hefty system requirements for a typical installation, which is why I installed it onto a new server. According to the documentation, OpenNMS requires a server with at least 512 MB of RAM.
May I have a cup of Java with that?
OpenNMS depends heavily on Java, so before installing the package, you must download, install, and configure a Java package. The OpenNMS folks prefer IBM’s Java development environment to that of Sun, so I used the IBM development for the examples in this article.
Then, make sure that you are logged in to your server as a root user. IBM's download site's IBMJava2-SDK-1.3-10.0.i386.rpm is the latest version of their SDK, as of this writing.
The installation of the Java SDK from IBM is as simple as issuing one command at the command line:
rpm –install IBMJava2-SDK-1.3-10.0.i386.rpm
Once the RPM is installed, you need to set environment variables so that OpenNMS can find what it needs. To set these, you will use your favorite text editor (mine is Pico) and make the following changes to .bash_profile in your home directory (as well as for the root user):
Add the path to Java:
PATH = $PATH:/usr/java/jdk1.3.1_02/bin
Add the following variable so that OpenNMS can find Java:
Add the JAVA_HOME variable to the export line in .bash_profile as well. To do this you will change:
export USERNAME BASH_ENV PATH
export USERNAME BASH_ENV PATH JAVA_HOME
Then, the .bash_profile must be re-read so that the variables that were set up become active. This can be done by typing source .bash_profile at the command line while still in the home directory for the logged in user.
If everything works as planned, you should make these variables a part of your /etc/profile so that this only has to be done once.
Once these steps are completed, Java will be available for OpenNMS to use for this session.
The installation of OpenNMS is quite difficult if you decide to build from source. Even using the distribution of RPMs provided can be a challenge if they are installed in the wrong order. For this article, I chose an installation method provided by the OpenNMS that automatically downloads and installs the latest version of the product and all of its supporting RPMs in the correct order.
The following, seemingly simple command does more than you think. It not only installs all of the OpenNMS dependencies in the correct order, it also installs OpenNMS itself.
lynx -source http://install.opennms.org | sh
Once this script finishes, you can log out and then back in, which will set up all the environment variables OpenNMS requires.
However, this install script may not run properly the first time around. If you are doing this in your own lab, pay attention to the error messages. In many cases, one of OpenNMS’s supporting RPMs failed because of a missing dependency. If this happens, you will know what the problem is by reading the error messages and can fix the problem and run the script again.
It’s installed. Now what?
Once OpenNMS has been properly installed, all of its services must be started. Assuming that a typical installation was followed, these commands will start the services:
/sbin/service jbossmq start
/sbin/service tomcat4 start
/sbin/service opennms start
If the system is rebooted, these services will start automatically.
Issuing the command /opt/OpenNMS/bin/opennms.sh status will output the current status of all of the OpenNMS processes, such as the Poller and the Discovery modules (see Figure A).
|Running the opennms.sh command with the status switch shows the status of all 10 OpenNMS processes.|
To get a minimal OpenNMS configuration up and running, there are three configuration files to be modified in the /opt/OpenNMS/etc directory (discovery-configuration.xml, poller-configuration.xml, and capsd-configuration.xml). For my test lab, I have only one subnet, 192.168.65.0/255.255.255.0 that I want to monitor, so I will add that subnet to the configuration files.
The first file that needs to be modified is discovery-configuration.xml. In the section labeled include-range, make the modifications shown in Listing A.
In the poller-configuration.xml file’s include range, I will add the following:
<include-range begin=”192.168.65.1” end=”192.168.65.254”/>
And finally, in capsd-configuration.xml, I need to tell OpenNMS which networks I want to manage. For this file, I will modify the ip-management policy section with the code shown in Listing B.
After these changes are made, it’s best to restart OpenNMS to force it to reread the configuration files using these commands:
/sbin/service opennms stop
/sbin/service opennms start
Once the OpenNMS services restart, the Web-based management system will be available at http://YOUR_SERVER:8080/opennms, where YOUR_SERVER is the address of your server (see Figure B).
When first browsing to the OpenNMS page, there isn’t much there, because the OpenNMS discovery service takes time to scan the network with the properties set up in the configuration files in order to find services to watch. After having been set up for a few hours (Figure C), my Open NMS system found targets to watch and reported that one of the targets, 192.168.65.134, was down (see the Outages page in Figure C).
For people who support networks with associated service level agreements, it's critical to accurately report on availability, even down to a particular service running on a particular node. In Figure D, you'll see the statistics for a node named PEAR, which is a PostgreSQL database server on my test network.
|The Node Availability Report gives the administrator a general overview of a particular node.|
OpenNMS provides much more than a simple description of an event. Clicking on an event code, the clickable number inside the Node Availability Reports Recent Events box, produces a detailed explanation of the event and explains other possible repercussions.
Overall, OpenNMS has the potential to be an asset for many organizations at an unbeatable price; however, it's extremely complex. Installing OpenNMS can be difficult, especially if you're building it from source code. Its installation routine almost precludes it from being installed on anything except a perfectly clean server, and the online documentation isn't complete, which makes it even more difficult to get it up and running properly. With proper documentation and a community of users supporting it like they do other open source software, I am sure that OpenNMS could become an extremely popular option for administrators.
Need more in-depth coverage of OpenNMS? If so, give Jack a shout and let him know.