If you have a well-designed NOC with plenty of computer screen real estate, you'll enjoy the geographic network maps. Zenoss uses a Google Maps mashup to display your network across geographic locations. Companies with multiple sites across a large geographic area will find this quite useful as a quick at-a-glance overview of where problems are occurring. The caveat to this is that the free Google Maps API key requires the Web site using the key to be free and publicly available. Because Zenoss requires user authentication and companies typically want to keep their monitoring system information to themselves, they would be violating the licensing terms of the Google Maps API key. To use this feature, a company would therefore need to buy a Google Maps Premier (Enterprise) API key.
Zenoss Enterprise has a number of vendor- and technology-specific monitoring capabilities, such as Oracle databases, Tomcat server, IBM WebSphere, Active Directory, and more. OpenNMS generally matches these capabilities, though Zenoss does have more advanced VMware monitoring; whereas Zenoss covers the latest VMware vSphere 4, OpenNMS covers only VMware Infrastructure 3. Zenoss lacks the full integration with help desk systems that OpenNMS provides, but it can open tickets in the Remedy help desk system via e-mails. In fact, both monitoring systems can work with any help desk system that is able to process e-mails into tickets.
Zenoss has a polished Web interface with some nice AJAX features. My favorite UI feature is the use of small pop-up windows with a dark background and white text (similar to Growl notifications) to provide feedback when a setting has been successfully changed or an operation has completed. These windows provide useful feedback, without causing extra page loads or mouse clicks and without being annoying or obtrusive.
The Web interface also makes use of a sidebar navigation menu, tabbed information panels, and pull-down action menus. This format works well in most situations, but sometimes the pull-down menus are used when a simple clickable link would be more convenient. Such things are always subjective, but I found the Web interface to be quite usable, if a little busy at times.
Once a device has been discovered and classified, it will automatically collect performance data and create performance graphs. Zenoss uses the same RRDtool-based graphs as OpenNMS and so many other monitoring systems. The Zenoss graphs have one minor shortcoming compared to OpenNMS: I like the ability to look at all the performance graphs for a particular device on one page, as OpenNMS presents them. When troubleshooting problems on a device, it can be useful to see both interface performance graphs and device resource graphs (RAM, CPU, disk) in a single view, so you can more easily discover patterns, trends, and correlations, such as high numbers of network packets on a router whose CPU utilization spiked. Of course, when faced with this situation, I can just open two windows with the performance graphs that I need to compare and arrange them side by side.
Zenoss has better documentation than OpenNMS. The Zenoss docs are well organized, and they come in both PDF and HTML formats. The material is organized by task in the Installation and Getting Started guides, and written to take you step by step through the installation and configuration of your Zenoss system. However, these docs lack some important performance-tuning tips that will be crucial to larger companies using Zenoss to monitor thousands of devices. Thus, it is important that customers take advantage of the planning and installation support provided to Enterprise Platinum customers to achieve maximum performance of their monitoring systems.
Alerts are more intuitive to configure on Zenoss than they are on OpenNMS. However, the simplicity comes at a cost: Zenoss alerts lack the flexibility of the OpenNMS model, which is so useful to larger IT shops. Also, an alert escalation in Zenoss is built as a separate alert notification rather than as part of the alert notification you want to escalate. The Zenoss notification system appears to be designed for easier configuration in smaller IT departments, but will create extra work for companies with larger IT departments who have multiple tiers of network support and 24/7 staff.
IT shops might want to keep track of software programs installed on each machine to ensure licensing compliance and to watch for employees installing undesirable programs on company workstations. Zenoss Enterprise can maintain a list of installed software packages on each server or workstation that it monitors. This is not exactly a "network monitoring" feature, but IT departments will appreciate this capability.
Distributed collectors for Zenoss are extremely easy to set up. Once a base OS installation has been completed on the remote collector machine, you can give the primary Zenoss Web console the root log-in information and it will install and configure the Zenoss software on the remote collector for you. These distributed collectors can be used to lighten the load on the primary Zenoss server or to get data from behind a NAT router if a VPN tunnel is not a feasible option for you.
Zenoss is currently working on improved features for its distributed data collection system, including simplified installation on highly secured servers and having remote collectors queue up data for later transmission when a network outage prevents them from immediately sending the data back to the central Zenoss server. A new, streamlined event console is also in the works, as is an encrypted data repository, allowing Zenoss users to protect any sensitive information being collected by the system.