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:

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.

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.