Since the dawn of the business network, there has been a need to ensure that the network services provided to the enterprise are alive and responsive. Traditionally, in midsized businesses, this role has been filled by complex, closed source, and fantastically expensive solutions from manufacturers such as BMC, CA, HP, and IBM. And while these extravagant expenses make no customer happy, many users of these packages also complain of their complexity. Enough administrators have spent enough time wrangling with their monitoring systems to make a lot of smart people imagine that there must be a better way.

Enter the latest salvo in this war: Zenoss Core 2, an enterprise-class open source monitoring package that has been built from the ground up to replace complex, closed source monitoring solutions. It certainly won't take the place of every function of these high-end solutions, but for the vast majority of IT shops, Zenoss Core will be deployed faster, be managed by fewer people, and cost a fraction as much as its closed source rivals.

Zenoss' key strength is a unified design that collects many types of information from numerous sources and displays them in an intelligent way. While many monitoring products feel like an amalgamation of several different pieces of software that have been stapled together, Zenoss stands apart with a unified, object-based repository and a tightly integrated set of tools and reports, yet doesn't draw itself into a corner as far as extensibility and future growth are concerned.

The latest Zenoss Core releases, Versions 2.0 and 2.1, sport several new features as well as a raft of bug fixes. New features include integration with Google Maps, providing interactive network topology views, plus network status visualizations and a drag-and-drop dashboard that allows users to assemble the dashboard components that they use most often. Although these features may seem somewhat superfluous, they are actually some of the most sought-after features in a management system. In a real-world scenario, it is sometimes far more helpful to have a large diagram with one system or site lit up in red than it is to receive an e-mail or SMS with error code in it.

Inside Zenoss Core

Zenoss is built on the open source Zope application server and the Python programming language, which provide a solid, standards-based development platform that is largely responsible for Zenoss' meteoric growth. The class-based relationships between monitored devices, performance data, event logs, and all of their associated organizational containers are well thought out and easy to navigate. The underlying data structures are equally straightforward, making the software easy for developers to extend and grow. These factors fuel a dynamic open source project that is one of the most active on SourceForge.

Zenoss is distributed either in the form of Linux RPM (Red Hat Package Manager) packages or as a prebuilt VMware appliance. It is readily compatible with a wide range of popular Linux distributions as well as Apple's OS X. Distribution in the form of a VMware appliance makes Zenoss easy to evaluate and helps pave the way for shops with no Linux expertise or available dedicated hardware to implement it. The RPM installation is nicely scripted and works well enough such that an admin with very limited Linux experience will find it relatively painless to get up and running. Upgrades are also relatively easy to accomplish -- usually only requiring the application of a new RPM and the execution of a data migration script.

After Zenoss is installed and running, the Web management GUI becomes available and you can start adding devices. Depending on the type of device being added, generally all that's needed for full discovery is a hostname and a read-only SNMP community string. The included device modeling software is intelligent enough to figure out whether it is parsing a switch, a server, a UPS, or a number of other basic types of devices, and determine which operating system is running. The vast majority of properly configured SNMP-capable devices will be automatically detected without very much direct intervention. If a modeler has been written to recognize the device (in the case of Dell or HP servers, for instance), a great deal of extra hardware-specific information can also be gleaned from the manufacturer's management agents.

As with any auto-discovery process, there are always devices that won't be detected correctly, but these will generally be the exception rather than the rule -- even in fairly diverse environments. Moreover, it's fairly easy to suggest to Zenoss what types of devices they are and how they should be treated if the device modeler doesn't quite get it to begin with. Only the more unusual devices such as a network-attached Fibre Channel switch or tape backup unit will be entirely unrecognized. Even in these cases, some statistics can still be recorded about the Ethernet interfaces and basic SNMP information about the device so long as it implements a standard SNMP MIB (Message Information Block).

Device support is always a challenge for monitoring packages, and this is one area in which commercial software solutions are generally more capable; after all, they typically have had more capital to invest in developing monitoring plug-ins. However, this increased capability is usually at the expense of user and community extensibility -- not a trade-off Zenoss has made, and thankfully so. Zenoss is betting that a combination of internal commercial development and a great deal of community development will bridge this gap and make Zenoss' built-in device support comparable with that of much larger competitors. Although this is admittedly not the case today, Zenoss Core did correctly recognize and model more than 80 percent of a rather complex corporate network that I used for testing.