[rrd-users] Re: Fup: About logging the REAL value

[Jakob Ilves]

Hello folks!

Alex van den Bogaerdt wrote:
> 
> Hi,
> 
> At least there is some discussion now.  This is good, no matter if a
> change is implemented or not.

And the mails on the subject keep popping in... :-)

> Now for the original problem:
> 
> Some room, some entry, somehow you *know* in and out going traffic can
> only happen once every minute.  However, you do not know when this can
> happen, it can be anywhere in this minute.
> 
> A database is created.  As soon as a change is detected, the RRD is
> updated.  The current time is used, not the available workaround.
> 12:01:20 a person enters the room.  I know, for sure, that the amount
> of people in the room alters from 4 to 5.  What happens in the RRD?
> The previous interval (presumably going from 12:00 to 12:01) is updated
> and the current value is remembered for the next update.  This update
> happens at, for instance 12:02:20.  Another person enters the room and
> the number of people in the room is 6.  I *know* the minimum and maximum
> without doing any guessing, without being inaccurate.  Averaging *does*
> introduce an error here.

[...]

(Note that my discussion below is aware of the fact the data is OBSERVED
data collected at specific points in time and that the value being
observed might change freely between data collections.  The entire
discussion below is about how to treat that specific data in some better
ways).

I don't have much problem with interpolation of values to get AVERAGE
values to write at a specific time.  In the "number of used modems"
case, you can tell the "customer" of the MRTG pages that the "current"
value of 15.253 modems being shows up because the time being "current"
(say 12:05) isn't exactly the same time when the server was queried for
modem data (which happened at perhaps 12:04 or 12:06).  (Actually, if
MRTG/RRDtool doesn't use the word "current" but "Latest" the users
perhaps get's less confused.)

So doing interpolation of data to get 5 min samples is fine for me as
long as it is intended only for AVERAGE calculations and not MAX
calculations.

What I actually do have a problem with is the fact that there the
"maximum observed" values for the modems results in values like 24.45,
which is wrong!  All the SNMP queries for the number of used modems
return integer values.  Thus the maximum value among these values is an
integer value too.  And that value is the most accurate "Maximum
observed" value IMHO.

So, if MAX and MIN values need to be interpolated, change the
interpolation scheme or rather, leave MAX and MIN alone for backward
compatability but introduce two new DS, let's call them OMAX and OMIN
(Observed MAX/MIN).  When RRDtool write in the rrd file for these DSs,
it do not use the standard value interpolation as used by MAX and MIN. 
Instead, in the case of a OMAX, it uses the maximum observed value
sample during the last step.  In the case of a OMIN, it uses the minimal
value instead.

I think this OMAX/OMIN feature should be implemented and put into the
RRDtool distribution because:

1.) I believe (or rather guess) it is not hard to implement nor messes
up the code badly nor breaks all the fundamentals of the Round Robin
Database (But I doubt I know what I talk about here as I've not READ the
code :-).
2.) I don't consider adding these two DSs to complicate the user
interface to rrdtool very much.
3.) It does not require any post processing of the data once these OMAX,
OMIN DS are written into the file.
4.) It does not mess with the data.  It just picks another interpolation
strategy which in some circumstances provide more accurate data to the
end users.

End result will be that RRD files still have all data sampled to the
fixed time intervals but some of them really have the min and max
observed values.

Tobi, if I write the code for what I suggest above (and do that with
cleaner code than I provided in my earlier attempts to contribute ;-)
would you mind including it?

> I have no objection against this averaging when counters are involved.
> gauges are not counters.
> 
> Perhaps I don't see the obvious solution to the problem and presented
> a less obvious solution.  If so, enlighten me :)

[...]

Best regards

/IlvJa

-- 
                (Jakob Ilves) <jakob.ilves at oracle.com> 
             {Oracle Global IT, Network Management Group}
[Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572]

-- Attached file removed by Listar and put at URL below --
-- Type: text/x-vcard
-- Desc: Card for Jakob Ilves
-- Size: 424 bytes
-- URL : http://www.ee.ethz.ch/~slist/pantomime/14-jakob.ilves.vcf


--
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