[rrd-users] Fetch the time of the first entry

[Steven Sim]

Simon;

Thanks deeply pal.

So what you and Alex van den Bogaerdt is saying is that FIRST does NOT give
the first actual 'update' but the actual first available slot, which is 30
days prior to the last update.

And  yes, the FIRST value changes in step with each of my actual 'update',
so it really gives credence to your explanation.

One questions;

When I create the RRD, I am forced to give the --start <TIME> as one step
BEHIND my actual update.

So let's say my data starts at midnight 1st July, I am forced to create a
RRD with --start time at 11:45 30th of June.

data starts -> 1st July 00:00:00 <-- first data entry.
Step = 15 minutes (900 seconds)
RRD has to be created with --start 11:45 30th of June (one step behind).

if I do not create it 1 step behind, I get an error with my updates.

Why is the above so?

Secondly, Thanks to Alex can den Bogaerdt, I should use the VDEF function
and use rrdtool graph without graphing and PRINT to parse the value to a
Perl script variable.

Deepest Regards
Steven Sim

On Tue, Jul 1, 2014 at 9:53 PM, Simon Hobson <linux at thehobsons.co.uk> wrote:

> Steven Sim <unixandme at outlook.com> wrote:
>
> > BUT when I use rrdtool first <rrd database> in an attempt to get the
> time of the first entry, I get a Unix time stamp which is one entire month
> EARLIER than the first entry in the file.
> >
> > And each time I do update, rrdtool first <rrd_database> returns a
> DIFFERENT number.
>
> With each update, does the FIRST value update to be one month (or 30 days)
> before the timestamp of the update ?
>
> If so then I think I know what's happening. When you create teh RRD file,
> it is created in it's entirety - in your case with buckets for 2880
> consolidated values. These exist regardless of what updates you do or do
> not do, and the timespan of them is determined by your step and
> consolidation values.
> What I suspect is happening, and what I alluded to earlier, is that even
> though you haven't done any updates for those historical buckets, they are
> still there - and FIRST is merely reporting the timestamp of the oldest
> bucket. Since you are setting the start time of the RRD when you create it,
> then the timestamp of the oldest bucket will be 30 days prior to that. As
> you perform updates, you overwrite the oldest buckets and the value of
> FIRST will advance to be 30 days prior to the last update.
>
> Internally to RRD, there is no storage for whether a bucket actually had
> any updates - only for it's value after applying the consolidation rules
> specified. Thus there is no way to know if the oldest bucket ever had an
> update if it's value is NaN - you don't know if it was created with NaN and
> has never been overwritten, or if it was updated but the calculated value
> was NaN. You would have to search back through the database to find the
> oldest bucket with an actual value and infer that this bucket was
> *probably* the one with the oldest data.
>
> _______________________________________________
> rrd-users mailing list
> rrd-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20140701/163efa39/attachment.htm