You are on the right track with this post, but it will not quite
accomplish what the original poster wants. This will get the appropriate
number of data points into the RRD file. You can now fetch the 5 minute
values for 30 days worth of time. (For what it is worth, unless you are
generating automated reports at the stroke of midnight every 30 days, I
would extend the number of data points stored to be 36 days or longer,
so you can run the reports after a long weekend if need be.)

The next trick is getting the appropriate data to display in a graph.
The default graphs will probably not work for this purpose. The graphs
displayed in the interface display uses a fixed image size. By default
the "rrdgraph" command will choose the time scale that best fits the
width parameters given to it. So if the default graph width is 600
pixels (graphing 600 data points), and you choose to graph a time-period
of 30 days, it will choose the RRA:AVERAGE statement that most closely
provides 600 data points. I've taken the example given and extrapolated
out if 

RRA:AVERAGE:0.5:1:8640 (30 days stored)   ( 30 days * 24 hours * 60
minutes) /  5 minutes cycle time = 8640 data points required
RRA:AVERAGE:0.5:6:600 (12.5 days stored)  ( 30 days * 24 hours * 60
minutes) /  30 minutes cycle time = 1440 data points required
RRA:AVERAGE:0.5:24:600 (50 days of two hours averages stored)  ( 30 days
* 24 hours * 60 minutes) /  120 minutes cycle time = 600 dpr
RRA:AVERAGE:0.5:288:600 (600 days of daily averages stored)  ( 30 days *
24 hours * 60 minutes) /  1440 minutes cycle time = 30 dpr

In a 600 pixel width graph, your graph display will most likely be with
the 120 minute averages because it has enough data points (50 days
worth) and the cycle time matches the pixels required to build the
graphs. In the interface page, you can use the hourly display and scroll
back for 30 days, but this gets difficult, because the graph min and max
will keep adjusting to be appropriate for the hours displayed within the
graph. In short, the interface page is NOT the right place to look for
accurate 5 minute graphs going back for a month.

I've been generating reports like this on a limited basis using
customized scripts that run monthly. My current Zenoss install does not
allow me to create customized reports, but the Zenoss documentation
indicates that it should be possible to create your own Zenoss reports
for this purpose. 

The trick is if you are really tracking monthly maximums (months have
variable numbers of minutes) you will need to perform a bit of
preliminary math before running each report to determine how long each
month is, and adjust the graph width accordingly. If you are using these
for billing purposes (people like to pay on the same day of the month)
you are stuck with the calculating a monthly time period.
If you stick with the 600 pixel width, you can force the rrdgraph
statement to use the 5 minute RRA to display the graph, but it will use
an algorithm to combine multiple data points to reduce the number down
to 600 points (pixels) in the graph. To get a more accurate display, if
you are doing 30 days, you want a graph of 8640 pixels wide (8640 data
points) to get an accurate display of 5 minute averages. In other words,
you want the pixels and data points to match exactly. If this figure is
for executive review, I'd suggest generating the graphs on a weekly
basis, and generating a report with 5 weeks of historical graphs. This
is much easier to implement without a huge amount of mathematical heavy
lifting.

One more note. Your RRD file for the interface stores both and average
(RRA:AVERAGE) and a max figure (RRA:MAX). Since your cycle time is 5
minutes, the MAX value will always be the same as your average. In the
longer cycle times, the MAX figure will normally be different. In order
to get a 30 minute figure, it calculates the average of 6 consecutive 5
minute cycles and records that in the 30 minute average. It then
determines which of the 6 consecutive 5 minute cycles is the greatest
and records that in the 30 minute MAX.


On Fri, 2009-01-30 at 05:43 -0600, netdata wrote:

> As far as I know it has to do with the RRD create parameters.
> 
> I would suggest that you digg in the documentation of RRD especially the 
> create command.
> 
> It is possible but will require to remove your current rrd files.
> And it also will have a bigger filesize ofcourse.
> 
> I'm not good in this stuff, but I thought this is close to reality.  
> 
> There is a RRA called AVERAGE which is defined like:
> 
> RRA:AVERAGE:0.5:1:600
> RRA:AVERAGE:0.5:6:600
> RRA:AVERAGE:0.5:24:600
> RRA:AVERAGE:0.5:288:600
> 
> This means:
> 
> Store the AVERAGE value over a period of 1 cycles 600 times
> if your cycle time is 300sec then you will store every 5min the value and 
> this 600 times so:
> 
> Store every 5 min a value for 50 hours
> Store the average value over 30 minutes for 12,5 Days
> Store the average value over 2 hours for 50 days
> Store the average value over 24 hours for 600 days
> 
> So as you can see to more time elapses the more the values will be averaged.
> 
> Now you could say you want to store  the 5 min value for 30 days by changing 
> the first RRA to:
> 
> ( 30 days * 24 hours * 60 minutes) /  5 minutes cycle time = 8640
> 
> RRA:AVERAGE:0.5:1:8640
> 
> If i'm mistaken please let me know
> 
> 
> 
> 
> -------------------- m2f --------------------
> 
> Read this topic online here:
> http://forums.zenoss.com/viewtopic.php?p=30685#30685
> 
> -------------------- m2f --------------------
> 
> 
> 
> _______________________________________________
> zenoss-users mailing list
> [email protected]
> http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users

Reply via email to