Peek at performance
Performance monitoring is an important task for any enterprise-grade network monitoring system. Zenoss uses the RRDtool system, made popular by MRTG and Cacti, to collect performance data from network devices, create graphs for easy analysis by a human, and generate threshold-based alerts. By default OpenNMS uses a Java implementation of RRDtool's functionality to provide the same performance data collection and presentation services, but it can be configured to use RRDtool proper for compatibility with other tools that read RRDtool's data files. Both systems collect and graph all available incrementing data via SNMP for monitored devices by default. In addition to the usual network traffic statistics and RAM and CPU utilization, OpenNMS and Zenoss can track disk utilization as well as I/O throughput on supported systems. And both systems provide a way to collect and graph custom data, or perform modifications to collected data as well as calculations before graphing.
An important aspect of any open source software project is its community of supporters and developers, and both OpenNMS and Zenoss have strong followings. At the OpenNMS Group (the company), all but one of the employees are developers, while approximately 60 percent of the OpenNMS project development team is composed of community programmers who have no direct affiliation with the OpenNMS Group. Zenoss is developed almost entirely by company employees, but the community of Zenoss users and customers has produced more than 100 ZenPacks to provide additional functionality for Zenoss.
For an application of the magnitude of these two network monitoring systems, you will almost certainly run into some configuration issues or unclear features, so support is important. As part of my research for this review, I made use of the support groups at both companies for help with their respective products. OpenNMS and Zenoss both did a great job with support. They were able to answer my questions quickly and were completely courteous and friendly at all times.
OpenNMS: Superior value
OpenNMS is a purely open source software project. This means that you get the full version of the software for free as open source; there is no extended, "enterprise" version. The business model used by the OpenNMS company is to sell support and training services for the OpenNMS open source software. Most of the company's employees are developers or contributors to the open source project. There is also a healthy development community behind the project. While the company does not have large financial backers, it likes to brag of its prudent accounting strategy: "We spend less than we make."
One of my favorite features of OpenNMS is the ability to integrate with several help desk software applications, including Request Tracker (RT), ConcourseSuite, JIRA, OTRS, and Intuit's QuickBase. Unlike some monitoring systems (including Zenoss), OpenNMS does not merely open help desk tickets by sending e-mails to the application. OpenNMS uses the API for the help desk application, which allows OpenNMS to open, update, and close tickets, as well as provide links from the OpenNMS Web interface to the appropriate ticket in the help desk application's Web interface. As part of our GreenLight Project on-site consulting, we had the OpenNMS server tied in to my company's Request Tracker help desk system and configured OpenNMS to open tickets for network device down alerts, and update and close the tickets once the network device came back online.
Another strong point of OpenNMS is its alerting and notification system, which abstracts alarms into event notifications and user notification paths. Event notifications define what sort of changes in the network will trigger an alert. User notification paths define who gets notified, how they get notified, and when they get notified, as well as a notification escalation procedure for alerts. Although setting up alerts in OpenNMS is not quite intuitive, the OpenNMS design gives the user a great amount of flexibility. The event notifications and user notification paths can be reused. Once you've configured an event notification rule for one network device (to watch for high network throughput, for instance), you can use that same rule for other network devices. And if you have a standard set of employees for day shift and night shift, then you might need only a handful of rules for thousands of devices. The more devices you monitor, the more you'll appreciate the OpenNMS notification system.
OpenNMS supports several methods of alert notification. Of course e-mail and e-mail-based pager notifications are supported out of the box, but OpenNMS can also send IM alerts via the XMPP (Jabber) protocol, as well as traditional numeric and text pager services. If you have another type of notification service that you want to receive, then you can designate an OpenNMS XML configuration file to use a command-line utility of your choice to send notification messages. OpenNMS uses the concept of a duty schedule to provide further flexibility and reusability of the alert and notification rules. Duty schedules can be applied to users, groups, and roles, preventing off-duty employees' pagers from waking them up in the middle of the night when they're not supposed to be working.
My company has used various versions of OpenNMS in production for more than five years now, and we have seen that it scales up very well to monitor thousands of devices. In fact, OpenNMS has at least one customer with 144,000 devices being monitored. Of those 144,000 devices, SNMP performance data is collected on 50,000 interfaces, resulting in 450,000 data points being amassed every five minutes.