Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Adventures in OpenNMS

DZone's Guide to

Adventures in OpenNMS

Check out this amazing graph and dashboard a user of OpenNMS made.

· DevOps Zone
Free Resource

Best practices for getting to continuous deployment faster and with dramatic results in reduced outage minutes, development costs, and QA testing cycles. Brought to you by Rainforest QA.

One of the things I love about open source and OpenNMS in particular is watching what people do with it. We knew that we had a great data collector in OpenNMS but sometimes it was hard to display that data in a useful fashion.

OpenNMS is a platform and it is very broad. For example, we do log management, but that is only a small portion of what the application can do, yet there are companies who do nothing but that. So yes, we can display graphs but we don’t necessarily have the resources to focus on making a great data visualization tool.

Enter open source. Torkel Ödegaard has written a great visualization tool in Grafana, so it would be silly for us not to leverage it.

I was at a customer site I and I saw this cool graph:

Grafana Graph

I asked Patrick about it, and he said that he wanted to play with the OpenNMS/Grafana integration so he installed it and within a half hour he had it up and running. He created the graph as a version of the “stacky graphs” you can make in OpenNMS, but it was much easier to do and to maintain.

The name “stacky graphs” came from another customer of ours. They asked me if there was a way to put the bandwidth from all of their peer points on one graph. Now, in OpenNMS, it is easy to make a graph of data from a single device, and it is easy to group multiple graphs together, but it was not easy to put disparate data points on a single graph.

However, OpenNMS is a platform so I was able to find a way. When you create a graph definition in OpenNMS, there are two important fields, called “columns” and “type”. The “columns” value defines the file to look for, say ifInOctets.rrd and ifOutOctets.rrd, and the “type” value tells OpenNMS where to look for those files. So what I did was create symbolic links under the OpenNMS node directory named things like LAX-in.rrd, LAX-out.rrd and NYC-in.rrd, NYC-out.rrd that were linked to the interface RRDs of interest. Then I created a report of type “nodeSnmp” with column names like “LAX-in, LAX-out, NYC-in, NYC-out” etc. Then I could use AREA graphs to print out the data.

This was a pain for a number of reasons. First, you had to do a lot of configuration on the command line. Second, sometimes it is useful to delete .rrd files that haven’t been updated in awhile, but if you aren’t careful you’ll delete the symlinks. Finally, it is a lot of work to add new data sources.

Grafana Graph vs. RRDtool

In this picture you can see the Grafana dashboard in the lower left corner and the OpenNMS “stacky graph” in the upper right. Not only does the Grafana version look better, it will be easier to maintain moving forward.

I am eager to see what others are doing with this, so feel free to check out the integration on the wiki and let me know if you come up with anything cool.

Discover how to optimize your DevOps workflows with our on-demand QA solution, brought to you in partnership with Rainforest QA.

Topics:
visualization ,opennms

Published at DZone with permission of Tarus Balog, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}