Home | Hardware | Internet News |Web Hosting |IT Management |Network Storage
LinuxPlanet
Search 
  Power Search | Tips 

 Front Door
 Discussion
 LinuxEngine
 Opinions
 Reports
 Reviews
 Tutorials
 News
 Technology Jobs

 Browse by subject.
Free Newsletter

Java/Open Source Daily
Linux Today
More Free Newsletters

Be a Commerce Partner


















internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers

Print this article
Email this article

   LinuxPlanet / Reports







OpenNMS: A Study in Deployment
Why OpenNMS?

Jonathan Sartin
Thursday, June 2, 2005 12:15:45 PM

OpenNMS checked a lot of these boxes. It was (mostly) java, so we could run it on our Sun hardware. OpenNMS was already running in environments an order of magnitude larger than ours. It had a lot of the enterprise level features absent from other Open Source products. There were documents available on the Internet [1],[2] that pointed to its extensibility. It was based on a lot of familiar components (tomcat, postgres, rrdtool). Finally, in Open Source terms, it was a relatively mature product.

We took a cautious approach deploying OpenNMS.

Simplest to replace, and therefore first to go were the existing network monitoring products. Only after a month of parallel running with OpenNMS did we decommission our existing solutions.

Second to go were the diverse collection of emails that were sent by applications or batch jobs. We replaced the destination email addresses with some mailboxes that delivered the notifications directly into OpenNMS. This turned out to be a bigger win than we'd expected. By having a central point where application alerts could be received and processed, we revealed hidden issues with applications that had existed for weeks or months.

This was painful at first. The respective teams were often uncomfortable in having their problems aired to the world. Once we started to address these problems, however, and the frequency of the alerts started to reduce, we started to see real benefits. The operations team had a single console to monitor applications, and we could reduce the number of application support staff on call.

The next target was system performance data collected by our existing tools. That which could be readily moved into OpenNMS went quickly. Platform specific data collectors (such as those which collected from Microsoft hosts using WMI) had any important alerts channeled in to OpenNMS.

Our current focus, now that we believe our OpenNMS installation is mature, is back in application space. We are extending the end-to-end monitoring capabilities of OpenNMS to our web services providers. We are also starting to use it to retrieve instrumentation data directly from applications themselves, as well as their hosts.

Next: Did We Meet Our Requirements? »

Skip Ahead

1 Why Do We Need a Systems Management Tool?
2 What Do We Expect from a Systems Management Application?
3 Why OpenNMS?
4 Did We Meet Our Requirements?
5 Conclusions and Lessons Learned





Linux is a trademark of Linus Torvalds.


internet.com home | search | help! | about us

Jupiter Online Media

internet.comearthweb.comDevx.commediabistro.comGraphics.com

Search:

Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia

Jupitermedia Corporate Info


Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Web Hosting | Newsletters | Tech Jobs | Shopping | E-mail Offers