[rrd-users] Re: GAUGE problem, averaging two points
BAARDA, Don
don.baarda at baesystems.com
Tue Oct 10 01:36:12 MEST 2000
G'day,
> -----Original Message-----
> From: Alex van den Bogaerdt [SMTP:alex at slot.hollandcasino.nl]
> Sent: Saturday, October 07, 2000 12:46 PM
> To: peat at canada.com
> Cc: rrd-users at list.ee.ethz.ch
> Subject: [rrd-users] Re: GAUGE problem, averaging two points
>
>
> pet wrote:
>
> > I have a bizarre problem when using GAUGE.
> > My boss was stumped and now so am I.
> >
> > The following behaves as expected:
> [snip]
> > but strangely this does not:
> [snip]
>
> I don't see a difference there. Perhaps you should explain more
> clear what that difference is or perhaps I shouldn't be here on this
> list at 03:45 am.
>
I haven't looked closely at the data, but I suspect the difference
was the start times... the first probably had;
(start % step) == 0
and the other didn't... ie
(start % step) != 0
the first thing RRD does is "re-sample" the input data to distinct
"Primary Data Points" (PDPs) at "step" intervals. These steps are aligned to
times when (time % step) == 0. Note that the "start" time is only used as a
sanity check and to initialise the data. It is not used as a starting point
for aligning the data.
You could argue that it would be nice if "start" _was_ used as the
starting point for aligning the data, but the reality is that you only
notice if you have a large "step". I don't think that the changes required
would justify the small change in how it works. It seems to me that most
people don't notice this behaviour, and those that do can work with it once
they understand why.
BTW, the change required would be to change all the (time % step)
calculations to ((time-start) % step) calculations, and possibly add storage
for the "start" into the RRD database. Those that really want this feature
can implement it themselves and send the patch to Tobi for consideration :-)
> Anyway,
>
> > It appears the average between the current and previous data point are
> being calculated. I would like
> > to have the actual data point stored. I would appreciate any help.
>
> if you want actual data, use another database. If you want rrdtool,
> use rrdtool. RRDtool does these kind of things by design.
>
I suspect that once people fully understand the what/why/how of what
RRD does, they realise that it actually does what they want better than what
they thought/hoped it did :-)
> If you use update times on exact inter...
> wait...
> (somehow I sense a strong feeling of deja vu)
> (browsing old messages)
>
:-)
> See:
> > From: Alex van den Bogaerdt <alex at slot.hollandcasino.nl>
> > Message-Id: <200008120045.CAA22021 at slot.hollandcasino.nl>
> > Subject: [rrd-users] Re: GAUGE not functioning correctly?
> > Date: Sat, 12 Aug 2000 02:45:02 +0200 (CEST)
> in the archives.
>
In summary, if you don't want RRD to interpolate, first make sure
that you really don't want it to interpolate, then make sure you align your
samples to (time % step) == 0 times. One easy way to achieve this is to set
"step=1" and "heartbeat" to your desired maximum sample interval (as usual),
but be aware of the implications of doing this. Note you are not required to
have an RRA with "steps=1" if you don't want to store data at 1sec
resolution, so this will not increase your database size. This "trick" makes
all samples, irrespective of time, align with "PDPs" so no interpolation is
required.
This is a neat way to get exactly what you want for something like a
GAUGE DS that generates samples every time the DS changes... ie something
like snmp-trap events. If you are doing this, make sure that your
"heartbeat" is set to the longest acceptable interval between events, or
also get additional periodic samples by polling (which is a good idea anyway
to ensure you don't miss too much if you miss an event).
ABO
--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
More information about the rrd-users
mailing list