The Two Sides of OpenNMS

I have been giving a lot of thought to who uses OpenNMS. On the one hand there are those who want a better solution than Network Node Manager, and on the other are those who want more of a remote management “tool” or appendage that they can control from some central location. The former are more interested in features and the WebUI, while the latter are more concerned with the ability to remotely configure and update OpenNMS. Both are concerned with things such as the need to restart OpenNMS when changing things.

In the next few months, I hope to focus more on some of the remote management aspects of OpenNMS. This will result in features such as:

o The ability to add, remove and update individual nodes via events without restarting OpenNMS.

o Outage improvements so that outages can be dynamically scheduled without restarting OpenNMS, and the ability to “snooze” a device that is down for a known reason, such as a hardware failure. A device that gets “snoozed” would disappear from the Outages list for a particular amount of time.

o A “graph server” so that requests can be made to the system for a particular graph or graphs. This will allow third party programs to present data to end users without having to give them direct access to the system.

o IP to port mapping. This feature will collect SNMP data, such as utilization, under an IP address in addition to a port number. If you are an xSP, you could associate Switch 7, Port 12, to IP Address 10.1.1.1. Then you could generate reports based upon traffic to that address, which could be used in billing, etc. If the 10.1.1.1 device is moved to another port, say Switch 9, Port 3, the system could receive an event which would automatically move the data collection for 10.1.1.1.

This is in addition to the other nifty features we have planned, and I would be interested in input to how useful this would be.