OpenNMS: A Study in Deployment - page 4
Why Do We Need a Systems Management Tool?
Here's how things shook out:
- Platform independence: Yes. OpenNMS can run on spare hardware. But it's not a good idea. A year after our first rollout of OpenNMS, we moved from a shared SUN Ultrasparc 2 machine to a dedicated dual Xeon machine running RedHat Advanced Server.
- Performance: Yes. We are comfortable in that there will always be users pushing the scalability of OpenNMS much harder than we are.
- Enterprise Level Features: A cautious yes. OpenNMS met our initial requirements, but also quickly highlighted new ones. Some customers are never satisfied.
- Rationalize Support Roles: Yes. OpenNMS is now the single point for the distribution of all actionable network, server and application events. This does need to be constantly policed, to ensure that non-standard notification paths do not creep in again.
- Reduce Tasks: A cautious yes. In general, the operator's load has lessened, if only because it has reduced the numbers of open windows on their desktops.
- Extensibility: Yes. OpenNMS has proved to be highly extensible.
- Low cost of entry: We deployed OpenNMS with minimal capital outlay. We believe that the subsequent people based operational costs have been roughly equivalent to those of a commercial solution.
- Longevity: We seem to have backed a product with "legs." The mailing lists  are as busy as ever and new features are being added to OpenNMS faster than we can make use of them.
The "sweet spot" for OpenNMS seems to be about as wide as any Open Source solution and getting bigger by the month. We look forward to enhancements in the web user interface, a new JMX based data collector and support for event correlation in the near future.