Craig White wrote:
I am interested in a comparison with Zenoss - but wait until you know your way around opennms. Just ask on the opennms list if it doesn't do something you expect.
admittedly, this analysis is less than 24 hours after installation but...
Zenoss and OpenNMS seem to be scratching similar but different itches.
In spite of the S in SNMP there is nothing simple about network management, so the overall goal of the frameworks will be to make sense out of your network and monitor for problems, keeping a history of some of the values and presenting a nice user interface. It is a complex problem so different approaches will probably have different good and bad points.
OpenNMS seems to be most useful to large businesses with many remote sites and configuration management (i.e. puppet) of things like managed switches and sophisticated assignment to users/groups for alarms, etc. At this stage, I am only employing snmp for data collection and not for 'write' purposes.
The only write capability opennms offers is a push button to shut down interfaces - if you have snmp write access. It does have some integration with other tools to 'provision' or add nodes/services explicitly instead of autodiscovery if you already have this information in some other form.
Zenoss seems much more adept at gathering specific information on each device (at least out of the box adept), and it makes it easy for me for an example, to see who has which version of Microsoft Office installed on their computers. It does have alarm/event assignment and multiple method of notification assignment options, probably not quite as comprehensive as OpenNMS but still more than adequate for my uses. One thing that I have come to appreciate about Zenoss is that in addition to having SNMP and WMI data collectors, it also supports SSH collection which as I said, the Macintosh systems (workstations, i.e. iMacs, PowerMac G5, PowerMac Pro) don't seem to provide much useful info via SNMP.
WMI is a new addition to opennms - and it has an assortment of ways to use external programs to send data/events to it (see send-event.pl for one of them). I use ocsinventory-ng to collect/maintain the hardware/software details separately - it would be nice if that were more closely integrated.
My usage is typically a small business (< 50 users/computers) and I am pretty certain that Zenoss is more useful to me but I am still playing with OpenNMS anyway just to satisfy my curiosity and it has been educational for sure.
OpenNMS does start with the premise that you have too many nodes to usefully ever display at once, so it is all about automation, notifications, and collapsing views to summarize the status. Nobody ever wants to scroll through thousands of 'green' indicators to find the thing that's broken. However, the default summary screens probably aren't all that useful to you except for the list of current outages on the left of the home page. You'll need to arrange your own categories and dashboards for the specific layout you want to see, and some KSC report pages that group the graphs you want to see together (I'm not thrilled by the process to create these pages but they work nicely when done and can make it easy to spot problems like memory/cpu issues on one server of a similar group or bandwidth not balanced on your border routers). After you create ksc pages, you'll get a drop down selection on the home page for easy access and the screens auto-refresh (at least in current versions) so you can leave them up.
It would be hard for me to compare the process of setting both of them up because I already had Sun JDK working, snmp working on all possible devices and my understanding was relatively poor the first time I installed Zenoss. Subsequent installation has been relatively easy and OpenNMS was very easy too but by then, I had pretty a pretty good knowledge of things. Zenoss has a 'stack-installer' which will bundle mysql, python and zenoss, not really necessary on CentOS-5 which you can use CentOS supplied python and mysql-server. Their 'stack-installer' runs mysql-server on port 3307. I installed it by accident on one network and it's running fine so I left it alone. Zenoss has cool feature of automatically upgrading database when you upgrade versions unless you (speaking from experience) jump major versions (i.e. 2.0 => 2.2). You must upgrade to 2.1, start it up, allow it to convert the database, shut it down, upgrade it to 2.2 and repeat. Zenoss is now on version 2.3 which is substantially faster than earlier versions (I don't know why but I like).
Openmnms has an 'install' program you have to run even with the RPM installation, and it will take care of upgrading the database to any newer version. The 'Search' feature is nice if you have a lot of nodes and especially if you have naming conventions because you can give it a wildcard for either the name or address and get a list of choices. Things like that may not matter if your whole node list fits on the screen, though.
I prefer the selection/assignment methods of 'discovered' nodes (zenoss calls them devices, opennms calls them nodes) in Zenoss but that is sort of quibbling and not entirely important. Zenoss also has more 'built-in' categorizations (Location, Group, Network and even the 'Device' category seems to have unlimited subgroup options which I find entirely useful). It is a lot simpler to look at a Device list in Zenoss, select the Devices you want and assign them to a category than the selection/assignment method in OpenNMS=>Admin.
Opennms is versatile but somewhat confusing in this respect. There are different types of categories for notifications, polling and views. But for the surveillance view categories at least you should be able to either pick a category for a node or a list of nodes to add the category to. This may depend on the version you are running. I'm using the 'unstable' 1.7.x package. It is also surprisingly easy to build the subversion trunk version considering that it uses a bazillion other java components (hibernate/spring/etc.).