[CentOS] One for the Cisco experts...

[Les Mikesell]

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.).

-- 
   Les Mikesell
    lesmikesell at gmail.com