[rrd-users] Question about RRDTool ..

[Jean-Yves Avenard]

Hi

On Thu, Mar 20, 2008 at 6:59 PM, Simon Hobson <linux at thehobsons.co.uk> wrote:

>  1205974800 is not a multiple of your interval period, therefore
>  normalisation WILL be done on the data and you will NOT get out
>  exactly the same values you put in. Go to the rrd website and look up
>  the tutorial on normalisation.

Thank you for this.

Is there a way to retrieve that value for a given interval ?
I do not want to consider the data entered to be entered for a given
time, but for the whole period/interval.

>
>  Your graph will stop at the last completed sample period. According
>  to your mail headers, you are in timezone +11, so 11am is a multiple
>  of 3 hours UTC. As your later email shows, when another 3 hour sample


Ha ! that makes sense ....
I guess you being in the UK you must like that behaviour :) but I don't !
I had selected 3 hours as a period and was running my cron at
midnight, 3am, 6am etc... in the belief that it would make my period
selected fit perfectly.
I'm rather disappointed with the current behaviour.
While doing normalisation makes sense if you want to collect data such
as traffic on an interface , when collecting discrete value it doesn't
make sense.

I would have preferred if it consider the data entered to be the value
for the interval define by the period. And if you try to retrieve the
value within an interval it gives you the exact same data as it was
entered.

Is there a way to prevent normalisation ?

>  Lastly, it's a good idea to explicitly round your graph end time to
>  be exactly on the end of a step boundary, and your start time to be
>  exactly an integer number of steps before the end. Under some
>  circumstances, rrdtool will choose a lower resolution of data for
>  plotting if it fills more of the graph.

Thanks for the recommendation, now I just need to find out how to
round my graph end time to be the value I last entered.

>  Lastly, you are missing the point of rrds consolidation functions
>  here. Normally, the issue is that you don't want the storage overhead
>  of storing high resolution data over a long period - hence you would
>  store high res data for only a few days, medium res data for a few

Ok.. I did misunderstood how the value are stored.

My aim is to store all the data for a full year so I can do further
work on it at a leter stage.
I liked the idea of a database collecting a full bunch of data and
allowing me to do basic statistics functions on it including
generating graph easily.

>  weeks, and low res data for a year or two. In this case, you are
>  storing your highest resolution data for a full year - so there is
>  little point storing the other rras.

Ok, my understanding was at follow (and that's also what the RRD
tutorials were doing: keep the full data for a long time).
1-I keep all the data, because this is precisely what I want. And RRD
is much easier to setup than a mysql database
2-the various RRAs are used to pre-calculate the most common data I'm
going to use. As soon as I enter a new data, the various RRAs are
calculated to speed up the retrieval at a later stage.

>
>  You do NOT have to store the 3 hours data for the full year in order
>  to have the other consolidations available.
I *DO* want to store all the data :)
but not to do the other consolidations performed by RRD... I just want
to keep them because I like keeping the full history.

>
>  The only gain you get here is that by carefully selecting your
>  graphing periods/sizes, you can avoid query-time consolidation of the
>  data and improve graphing speeds. Since you aren't even specifying
>  start and end times, you certainly aren't taking advantage of this
>  optimisation.

I see. So it's only used to save time when retrieving the data or
drawing graph....
Well, my original aim was to keep record of all the data for a full year.
I guess RRD is slightly overkill for what I want to do.



Now, I need to find a way to prevent that consolidation from
happening. I'm collecting discrete value. Doing normalisation doesn't
make any sense for the kind of data I'm collecting.

Thanks again for your help
Jean-Yves