From: "Marcelo A. Ferreira Gomes" <mgomes@trip.com.br>
On Tue, 8 Jun 1999 09:02:05 -0700, Jeff Allen <jra@corp.webtv.net> wrote:
>Rocky - Rakesh Patel wrote:
>> I have a situation where some information was gathered via MRTG and
>> needs to be integrated into the current data files under cricket. In
>> particular, I want to update the "yearly averages" information to fill
>
>It sounds like you need a tool called "rrd-poke" which would let you
>frob arbitrary items in the RRD file, so that oyu could put in your
>old data into a new file. That tool does not exist, that I know of.
Well, I could volunteer to write such a tool, if given some resources.
Namely, I would LOVE to know the exact format of the (binary) RRD files. Is
there any documentation about it? Tobias?
If there's no such documentation, I'd like to know at least what part of
RRDTool's source to look into.
>Alternatively, you could build a new file by replaying the oldest data
>first (from MRTG) then replaying the data from Cricket, then finally
>swapping the current Cricket file for the one you built up by
>replaying the data. It'd be a bit tricky, though.
Too tricky. I tried that way, and it did work to some extent. But only for
too short amounts of time backward (like a day for fast interfaces, no more
than a couple of months for slow ones).
First there's the heartbeat and xff problem (the heartbeat and/or the
X-files factor in RRDTool must be large enough to accept data averaged over
a large amount of time). And RRDTool's tune function won't let me alter the
xff parameter later on, when the conversion is done (at least, I see no
documentation on doing that).
Then, there's the problem that MRTG stores deltas, NOT the original sampled
data, forcing you to start from the last point (which is the ONLY point
that gets stored literally) backwards.
This is the biggest problem. When backtracking, you always get to some time
when there's just too much data averaged and things start not to fit in the
machine's binary numeric representation (32 bits on the Sparc Ultra?). On
fast interfaces, this problem shows up sooner, but if you have more than a
couple of months worth of data, even slow interfaces do show this behavior.
I then tried to work around this problem by "de-averaging" the data
(generating fake data points that amount to the same average) so as to deal
with numbers that could actually fit in (my machine's) 32 bits. But even
then, if the data was averaged over such a big amount of time as to have
more than one numeric overflow between two consecutive averaged points, you
start having no way to backtrack without a VERY complex scheme. I then
abandoned the idea.
That was when I saw your mailing. And that's why I volunteer to write the
"rrd-poke" tool. Any help on doing that would be MUCH appreciated.
Thanks in advance.
-- Marcelo A. Ferreira Gomes <mailto:mgomes@trip.com.br> Analista de sistemas e consultor em Informática (Systems analist and CS consultant) Rio de Janeiro, RJ, Brasil------------------------------------------------------------------------ Looking to expand your world? http://www.onelist.com ONElist has 170,000 e-mail communities from which to choose!
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 19:00:53 PST