Provided graph definitions are mixing aggregation function leading to wrong min / max totals

Description

The provided graph definitions are mixing aggregation functions between RRAs and VDEFs. This leads to wrong values shown in the legend which changes depending on the selected time frame.

Example mib2.bits (in mib2-graph.properties):

This definition also defines the according variables from RRAs defined as MIN and MAX accordingly but they are unused.

I'm not sure which graph definitions are affected by this or how to find them.

More details and the initial report by Simon Sorensen can be found here: http://comments.gmane.org/gmane.network.opennms.general/51100

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Tarus Balog June 10, 2016 at 3:50 PM

Removed all references to MIN and MAX RRAs in graphs.

To git@github.com:OpenNMS/opennms.git
158d3b0..80a1601 foundation-2016 -> foundation-2016

Tarus Balog June 10, 2016 at 11:56 AM

Okay, here is the history of this problem.

Many many years ago we used to collect hourly MIN/MAX/AVERAGE values for a year, but we would only graph the average values. As noted, the MIN and MAX in the GPRINT statement are the minimum and maximum values of the AVERAGE RRA, not the true MIN/MAX.

Craig Miskell spent a lot of time creating new DEFs so that the graph could extract the MIN and MAX values, and he would display those on the graph.

The problem was that hourly samples resulted in RRD files on the order of 283K. Now the default is to store daily MIN/MAX numbers. Thus the value that was printed wasn't very useful, plus users lost the ability to zoom in to a certain area of the graph and see the local min/max values.

So, I reverted the GPRINT statements back. I was planning on doing something like "Daily MIN/Daily MAX" but I think for now the best solution is just to remove them. This problem is non-existent with Newts, of course.

fooker March 27, 2015 at 4:35 PM

I'm happy to do the work since it is something I actually can do.

You are welcome.

Ken Eshelby March 27, 2015 at 2:17 PM

It would be easy enough to modify HCbits and bits in/out graphs to get in, since that is where historically complaints tend to be sourced. Maybe the errors graph for interfaces too.

As for meridian graphs, they've now got a lot more changes than potentially this, and I thought the goal was to trickle graph changes meridian-->horizon. To me it isn't a deal breaking issue that needs immediacy across all graph definitions.

I'm happy to do the work since it is something I actually can do.