Over a million developers have joined DZone.

Adventures in OpenNMS

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

· DevOps Zone

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

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.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}