I am certainly not an RRD expert, but I think some clarification is in order here to make sure your understanding of how it works is more accurate. May be more info than you need, but perhaps this will help others reading this thread..
-----
Consolidation Function
Consolidation defines the aggregation method used to turn compress a given series of data into a smaller dataset.
It's important to understand, though, that when you're looking at your typical default "hourly" RRD graph, you are NOT looking at data that has been consolidated in the RRD file. When you use the GAUGE data source type, the values you see on that hourly graph should be 100% accurate. No averaging has been done. The default RRA parameters in Zenoss include 600 intervals of "high-resolution" (unconsolidated) data. Assuming you are polling every 5 minutes (default), this means you should have 50 hours of unconsolidated data. Since the default hourly graph shows 36 hours, that graph should not show any consolidated data.
Now, when you use the COUNTER or DERIVE data source type, the value is calculated as the delta (or change) between the value returned from the current poll and the value returned from the previous poll. That number (delta) is then averaged out to a per-second value based on your polling interval. Network interface counters are a perfect example of this:
First poll --> device returns "11209874" as the current, at-the-moment, perpetually-increasing value for octets that have passed through the interface
Second poll --> device returns "89762984351" as the new (current) counter value for octets that have pass through the interface
The resulting value stored in the RRD file will be the delta of these two polls divided by the number of seconds that have passed.
Thus, value stored will be:
89,762,984,351 - 11,209,874 = 89,751,774,477 / 300 = 299,172,581.59 [octets-per-second]
(Okay, if you multiply that number by 8 to get the number of BYTES per second, you get 2,393,380,652.72 bytes/sec.. an almost impossibly high number in reality, but you get the point... 
)
Back to consolidation..
The default RRA paramters for RRD files created by Zenoss are as follows, with explanation:
RRA:AVERAGE:0.5:1:600
- consolidates every 1 poll (so no consolidation)
- keeps 600 intervals of the polls
12 polls per hour means 50 hours of hi-res data (12/hr * 50hrs = 600)
RRA:AVERAGE:0.5:6:600
- consolidates 6 values at a time (averages last 6 polls)
- thus, 1 value every 30 minutes (5min * 6 polls)
- keeps 600 values
- thus, 12.5 days worth of values (48/day * 12.5days = 600)
RRA:AVERAGE:0.5:24:600
- consolidates last 24 polls at a time
- thus, 1 value every 2 hours (5min * 24 polls)
- keeps 600 values
- thus, 50 days worth of values (12/day * 50days = 600)
RRA:AVERAGE:0.5:288:600
- consolidates last 288 polls at a time
- thus, 1 value every 24 hours (5min * 288polls / 60min/hr)
- keeps 600 values
- thus, 600 days worth of values
So in reality each RRD file is storing 4 different "lines" of data for each data source (forgetting the MAXIMUM RRAs it is also recording..). Each "line" of data is less precise (more consolidated) than the previous.
When you request a time-period of data from the RRD file, RRDtool determines the MOST ACCURATE representation of that time-period it has stored. Thus, when you ask for the time-period between 300 days ago and 200 days ago, all of the resulting values returned from RRDtool will be from the "fourth line" of data -- that from the RRA:AVERAGE:0.5:288:600 line. Likewise when you ask for the last 36 hours of data, you will get values from the "first line" of stored values -- that from the RRA:AVERAGE:0.5:1:600 line, which is by previous definition not consolidated.
I don't recall how it determines what data to send when the time-period crosses "line" boundaries, but I know it is explained somewhere on the RRDtool website..
-----
Hope this makes sense. If anyone can speak to this explanation being incorrect, PLEASE DO SO!
Thanks!
pri.png (13.8 K)
