[rrd-users] trying to understand the relationship between source data, what's in rrd and what gets plotted

[Mark Seger]

I think this makes a lot of sense and I'm certainly willing to give it a 
shot and see what the results look like as you can never be completely 
sure until you try it.  So the next obvious question becomes how much 
work is it to do something like this in and more important how much 
overhead will this add?  From what I've already seen with preliminary 
testing is that rrdgraph is already very fast and so I'm hoping it 
should be so too.

Does this involve storing both min and max values?  I just did a quick 
test and found to store about 80 10 sec samples requires about 20MB for 
a day's worth of data on 1 system and I normally retain a week since as 
we all know sometimes system problems go undetected for several days and 
you need to retain that level of detail.

In any event, what's the next step if I want to try this out?  As I said 
in my original post I'm new to rrdtool (as if you couldn't tell from my 
questions 8-)) and so am not entirely sure how best to approach this.  I 
also do want to thank you for being so patient with me...

-mark

Alex van den Bogaerdt wrote:
> On Sat, Jul 21, 2007 at 02:52:55PM -0400, Mark Seger wrote:
>
>   
>>>> Just put the dots (or lines) where they belong and if some fall on top 
>>>> of each other and you only see 6, that's just fine.  Where I'm coming 
>>>> from, and what I always do with performance related data, is look at a 
>>>> broad range of time, perhaps a day wide.  I want to look at everything 
>>>> from cpu load, network, disk, memory usage, infiniband loading and a 
>>>> whole lot more.  I want to be able to see at a glance if there are any 
>>>> spikes where there shouldn't be or drops that also shouldn't be there.  
>>>>         
>
> Perhaps a day wide: 86400 seconds.
>
> See at a glance if there are any spikes or drops -> you want to
> see extremes.
>
> Now create a graph of 432 pixels wide. In each column, display
> the minimum and maximum of 200 rates, as a VERTICAL line.  If
> this line starts high enough (lowest rate high enough) and stops
> low enough (highest rate low enough), you can see, at a glance,
> you do not have to examine these 200 rates.
>
> If the line starts too low or ends too high, you need to zoom in.
>
> You will have 432 of such vertical lines, representing 86400 rates.
>
> The vertical line is in reality a stack of areas: First an invisible
> area to get an offset from the X-axis to the minimum rate, then a
> visible area representing (maximum-minimum) thus displaying both of
> these values.
>
>
> Next picture: again 432 pixels wide, now showing 432 rates. No need
> to look at minimum and maximum, as min(one rate) equals max(one rate)
> equals average(one rate).
>
> The resulting line will go lower than usual (a rate was too low) or
> higher than usual (a rate was too high).  This is what you were looking
> for.
>
>
> Now, please tell me what this example is missing.
>
>