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

[Steven Sim]

Simon;

Thanks for your very swift reply.

I'm still digesting your reply but I do have a small query.

my rrdtool first <rrdfile> command keeps returning different timing after
each rrdtool update.

Why is that so?

Shouldn't it ALWAYS return the Unix time stamp for the first entry?

Deepest Regards
Steven Sim

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

> Steven Sim <unixandme at outlook.com> wrote:
>
> > I intend to process a data file each day but create the rrd database on
> the FIRST day of the month.
> >
> > The creation shall ensure sufficient data points in the first day to
> contain the entire month but plot daily graphs until the end of the month,
> whereby it will plot the entire month.
> >
> > Say for example,
> >
> > If i had a step interval of 15 minutes (900 seconds),
> >
> > rrdtool create $RRDB --step 900 --start $STARTIME \
> > DS:......
> > DS:......
> > .
> > .
> > .
> > DS:......
> > DS:......
> > RRA:AVERAGE:0.5:1:2880
> >
> > 2880 = 24 hours x 4 data points per hour x 30 (thirty days in a month)
> >
> > 4 data points since one hour has 4 data points (15 minutes step).
> >
> > Would the above be correct?
>
> Yes, your numbers are correct, but I wonder about your methodology. It
> might help if you said what you are trying to achieve, because it's a
> rather unusual way of using RRD. Normally, you simply create one RRD that
> collects, stores, and consolidates the data you want. Typically this means
> keeping high resolution data for a shortish time, and keeping progressively
> lower resolution for progressively longer times - eg most applications
> don't need to keep (say) 5 minute resolution traffic data for 2 years ago.
> That's not to say you can't keep several years worth of high-resolution
> data if you want to.
>
> By keeping separate RRD files for each 'month', you'll find that it's hard
> work if you later want to do a graph for a year ! You'd also need to lock
> your "filled" data files otherwise one update to the wrong file could wipe
> out all the 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/bbbc1f2b/attachment.htm