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

[Mark Seger]

Alex van den Bogaerdt wrote:
> On Sat, Jul 21, 2007 at 09:42:47AM -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.  
>>     
>
> So: a line from minimum to maximum, together with a normal, would be
> good enough for this purpose.
>
>   
>> If nothing shows up, I'm done and that's why it's so critical that 
>> everything be displayed.  If there is a problem THEN I want to zoom in 
>> and the resolution becomes more significant and those dots/lines then 
>> begin to spread out as the resolution increases.
>>     
>
> Assuming a 400 pixel wide graph:
>
> At first you are looking at 400 days.  One of them is showing a high
> average.  Then do as you say right now: zoom in on the data. If you
> make sure you have the data available in your RRA, RRDtool is able to
> display it. E.g. the next graph you display shows 4000 seconds (10
> per pixel column). Select the problem area and display 400 seconds
> (1 per pixel column).
>   
I think you're missing my point, and that's ok too as I think I may be 
trying to do something rrd is not intended to and that is to 
record/display fine-grained data - in my case it's typically 10 sec 
samples over the course of a day or even 1 second samples over a 
benchmark that may have been run for several hours, max.  I rarely look 
at a samples of data that spans more than a day and certainly never 
something as old as a year.  When someone has reported a problem on a 
system where collectl is running (that's my tool) all they do is look at 
the data for that day and want to see if something unusual happened. If 
a critical spike in the data can't be seen, you lose the whole point of 
collecting the data in the first place.

> (N.B. _how_ to select the appropriate area, and how to zoom in, is
> a function of a front-end application, not RRDtool).
>   
isn't that what the graph tool is for?  or are you talking about a front 
end that calls the graph tool?
> Either I don't get what you're after, or you don't get that rrdtool
> will do as you say (right now).
>   
I think what rrd shines at is being able to archive data at very coarse 
time intervals, ultimately being able to show you things like average 
loads, etc where you're really only interested in trends and I want to 
look at diagnostic data and never lose a data point.  In fact, my data 
collection tool runs on our systems 24 hours a day and saves a rolling 
week's worth of data.  Most people only look at the data when something 
goes wrong and so having a year's worth isn't going to be of any value 
for trouble shooting purposes.  On the other hand if I take the data I 
collect and roll it into rrd when it's over a week old and about to be 
discarded, it could prove to be a very useful mechanism for that and I 
will continue to consider that as an option.

-mark

>> begin to spread out as the resolution increases.  Quite frankly I don't 
>> look at consolidated data because it's those exceptions that are the 
>> most significant when trouble shooting.
>>     
>
> Those exceptions will be higher than normal or lower than normal.
> These are propagated if you select "MIN" or "MAX" instead of "AVERAGE".
>
> You want it and RRDtool is able to deliver it if you ask it to.
>
>
>