Network management is hard. It's a part of the design that the effort is front-loaded: if you plan ahead and organize what gets monitored and collected according to rules, then the effort involved in adding nodes down the road approaches zero. It's an approach that doesn't make sense for everybody's environment, and you should absolutely use what works for you. All kinds of people find that OpenNMS works for them; a few who have written up their stories are listed here:
http://www.opennms.org/wiki/OBP
As for having somebody "to yell at", The OpenNMS Group sponsors the project and provides support, consulting, training, and custom development for OpenNMS; check opennms.com for details (disclosure: I'm an employee). We make two promises about OpenNMS:
1. It will never suck
2. It will always be Free (as in Freedom)
Tread cautiously where Groundwork is concerned. There is an upsell the moment your boss starts asking for advanced reports or dashboards. Also, since it embeds Nagios, the scale limitations inherent in Nagios' fork()-happy design will bite you down the road.
OpenNMS has world-class SNMP support, and configuring it literally could not be simpler. Tell OpenNMS what IP address ranges to discover and what community strings (or SNMPv3 USM users and passphrases) to use. Once the nodes finish scanning, SNMP data collection automagically begins for MIB objects that the system knows about. After a couple of data collection cycles, you'll have beautiful graphs of all this data.
When SNMP is not an option, there are still many options for both monitoring ("are all the servers answering requests?") and data collection ("what kind of traffic are we seeing on the DSL line?"). The latest release has an HTTP collector that you can configure to pull stats from devices that lack SNMP support but have a web interface, such as many DSL / cable modems and SOHO routers. There is also a page sequence monitor for testing "chained" web pages. For more complex tests or custom applications, you can wrap any existing test scripts you have in a bit of code that implements the interface contract for the General Purpose poller monitor.
As for time invested, OpenNMS is like any other sophisticated tool -- you get out of it what you put into it. If you just want to watch services and collect data, it will do that with almost no configuration. But take the red pill, and you'll find that the rabbit-hole is bottomless and full of things you never thought possible. The people who use and develop OpenNMS come from many backgrounds, bringing a great diversity of experience and needs. If you can think of it, somebody has probably made OpenNMS do it.
Slashdot Mirror
Network management is hard. It's a part of the design that the effort is front-loaded: if you plan ahead and organize what gets monitored and collected according to rules, then the effort involved in adding nodes down the road approaches zero. It's an approach that doesn't make sense for everybody's environment, and you should absolutely use what works for you. All kinds of people find that OpenNMS works for them; a few who have written up their stories are listed here: http://www.opennms.org/wiki/OBP As for having somebody "to yell at", The OpenNMS Group sponsors the project and provides support, consulting, training, and custom development for OpenNMS; check opennms.com for details (disclosure: I'm an employee). We make two promises about OpenNMS: 1. It will never suck 2. It will always be Free (as in Freedom)
Tread cautiously where Groundwork is concerned. There is an upsell the moment your boss starts asking for advanced reports or dashboards. Also, since it embeds Nagios, the scale limitations inherent in Nagios' fork()-happy design will bite you down the road.
OpenNMS has world-class SNMP support, and configuring it literally could not be simpler. Tell OpenNMS what IP address ranges to discover and what community strings (or SNMPv3 USM users and passphrases) to use. Once the nodes finish scanning, SNMP data collection automagically begins for MIB objects that the system knows about. After a couple of data collection cycles, you'll have beautiful graphs of all this data.
When SNMP is not an option, there are still many options for both monitoring ("are all the servers answering requests?") and data collection ("what kind of traffic are we seeing on the DSL line?"). The latest release has an HTTP collector that you can configure to pull stats from devices that lack SNMP support but have a web interface, such as many DSL / cable modems and SOHO routers. There is also a page sequence monitor for testing "chained" web pages. For more complex tests or custom applications, you can wrap any existing test scripts you have in a bit of code that implements the interface contract for the General Purpose poller monitor.
As for time invested, OpenNMS is like any other sophisticated tool -- you get out of it what you put into it. If you just want to watch services and collect data, it will do that with almost no configuration. But take the red pill, and you'll find that the rabbit-hole is bottomless and full of things you never thought possible. The people who use and develop OpenNMS come from many backgrounds, bringing a great diversity of experience and needs. If you can think of it, somebody has probably made OpenNMS do it.