[rrd-users] Re: VISIONARY: New tool to consider to create: a "Dyn amic Data Set" tool...

[BAARDA, Don]

G'day,

> -----Original Message-----
> From:	Jakob Ilves [SMTP:jakob.ilves at oracle.com]
> Sent:	Wednesday, November 22, 2000 6:09 AM
> To:	rrd-users at list.ee.ethz.ch; mrtg at list.ee.ethz.ch
> Subject:	[rrd-users] VISIONARY: New tool to consider to create: a
> "Dynamic Data Set" tool...
> 
> Hello!
	[...]
> So what am I suggesting?  It's very short to express but probably not
> trivial to achieve: write a tool which efficiently and accurately enough
> might store, process and graph this kind of dynamicly changing data sets
> and which supports the data consolidation over time MRTG/RRDtool uses
> (store 5 min samples for 48 hours, store 30 min samples for 2 weeks
> etc)..
	[...]

	I would first say that I don't think RRD itself needs changing in
any way to support this. RRD is a tool that does a single job and does it
well, and I'd hate to see it suffer from "featurism". However, RRD can be
used as a back end to implement something like this.

	What is needed is a front end that accepts the dynamically changing
data sets and feeds it to one or more RRD databases. Every time a previously
un-seen input is identified, a new DS is added to the RRD database(s),
either by re-sizing a single RRD, or by adding another one. Using one big
RRD will probably be more space efficient than multiple RRDs, but re-sizing
overheads will hurt. You could add blocks of yet-to-be-allocated DS's at a
time, either by extending a single RRD, or adding another RRD.

	Disappearing inputs can be handled by either feeding in a suitable
value (zero or last), or using unknowns. It depends on why the input
disappeared... is it still there you just don't know what it is, or is it
"down" and hence not counting? One advantage of multiple RRD's is when you
have sparse inputs from a large selection, not all RRDs will need to be
updated (this alone might justify a single RRD for each DS). If a DS has
disappeared for so long that all the data has expired from the RRD, the DS
could be 'reaped' or reused for another input, but I suspect that the effort
of identifying which DS's can be reaped will outweigh any benefits unless
the RRDs are only keeping data for a short time relative to the rate of
vanishing DS's.

	In short, you want a front end to RRD.

	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