First of all, let me state that I really liked most of the time I spent as a Netcool consultant. I started working with Angela Dawes about a month before Micromuse opened their New York office, and I spent my share of time on Townsend Street in San Francisco during those crazy bubble days.
But the price of the tool was crazy expensive, and although it was very flexible, there were a number of times that heroic effort was required to get it to do what you wanted it to.
Like OpenView, Netcool has grown to represent a large suite of products, and at the moment OpenNMS can only replace some of them. While OpenNMS’s service monitoring capabilities have always been a better alternative to the poorly designed ISMs (Internet Service Monitors), it now has the capability to replace much of the functionality of Omnibus and Impact.
One of the major features of Omnibus was what Micromuse called “event deduplication”. You had to define all of the events Omnibus could receive, and part of that definition was a key that would cause any two or more events with the same key to be merged into one. OpenNMS has a feature called “event reduction” which does a similar thing, although with Micromuse you pretty much lost any deduplicated event, whereas with OpenNMS you have the option of keeping the individual events as well as viewing the data as a “reduced” alarm.
OpenNMS also provides the ability to manipulate alarms via database commands to both the OpenNMS database as well as an external database like Impact.
This is pretty much old news, but I saw something yesterday that I thought was wonderful, and I wanted to share.
We have many users who use all of the features of OpenNMS, and others that focus on service monitoring, data collection or events. The last crowd, event centric OpenNMS users, are rather recent additions since they were drawn to OpenNMS for the new alarm features.
I recently did some work for an “event centric” client that wanted to move from a Netcool installation to OpenNMS. We did a Greenlight and they were pretty happy with the results as far as events were concerned.
I thought it was a cool project because our alarms system is meant to work perfectly with the “telecom” version of alarms. In the telco world an “alarm” is an event that comes in with a variety of parameters, and when it is resolved the same event is sent with a particular varbind set that indicates the alarm is now cleared. Thus a device is said to be “in alarm” or “not in alarm”.
By configuring OpenNMS to receive those events as traps (see the Veraz.events.xml file) and then using automations to match the “ups” with the “downs”, the client can now tell at a glance the status of his large telecom infrastructure just by looking at the alarms list.
But that was not what was so wonderful. It’s one thing to have me come in to configure OpenNMS, but we aim to put the power of the tool into the hands of the user. Netcool had a feature where you could display events in a histogram format, like this:
The client asked me if there was a way to use our data collection to graph events over time. We worked out a method where a script would periodically run and grab events from the OpenNMS database and post the results to a text file in the document root of the apache instance on OpenNMS. Then using the HTTP data collector, we were able to go out and periodically grab those event totals and store them. The resulting graph looks something like this:
This is useful to them, and is something that Netcool would have problems producing. However, I pointed out that if they liked the way the histogram stuff looked, they should check out our jfreechart integration. I pretty much left it at that.
So I was pleasantly surprised when I was on their system working on a separate issue and I saw that the main OpenNMS page now looks like this:
Pretty much the same information they were getting from Netcool, and the beauty of it is that they were able to come up with it on their own. Now granted, these are smart people (all OpenNMS users tend to be considerably above average in intelligence, as well as possessing impeccable taste) but they had only been using the product for a short time and yet it exactly met their needs.
That is why I drone on and on about OpenNMS as a network management platform, or a network management tool, versus “application”. An application implies a set way of doing things, whereas a tool is as powerful as the artist who wields it. Companies used to differentiate themselves by the applications they could afford to buy. With open source, everyone has access to the same tools, and the differentiation comes about from how well the company can execute its ideas. I’d rather be choosing my vendors on the size of their brains versus the size of their wallets.
