[rrd-users] trying to understand the relationship between source data, what's in rrd and what gets plotted
Mark.Seger at hp.com
Sat Jul 21 20:52:55 CEST 2007
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.
>> 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.
More information about the rrd-users