[rrd-users] Re: retroactively graphing data from logfile (newbie)
Alex van den Bogaerdt
alex at ergens.op.het.net
Wed May 25 11:56:28 MEST 2005
On Wed, May 25, 2005 at 10:47:49AM +0200, Ryan Tracey wrote:
> > > RRA:AVERAGE:0.5:1:24
> >
> > One "step" per row, 24 rows. That's not huge, is it? You have
> > asked for a database storing exactly one day (24 rows, one hour each).
>
> Hmm, I thought I was creating the facility to create daily averages.
> But I should rather do something like "RRA:AVERAGE:0.5:1:x" where x is
> the number of hours in the amount of days I want to store. Say, 144
> for 6 days.
Yes.
> Also, how would you best describe what the 0.5 does. The beginners
> guide seems to have glossed over that one.
Because that's in the documentation and I cannot make it much
clearer for you.
Your RRA has "1" steps per row. In your case, xff isn't used.
You either do have unknown data, or you don't.
> > I guess you mean "1115110805" is variable __AND__ it is a whole
> > multiple of 3600 ?
>
> 1115110805 is variable, the timestamp in the first column, but not (I
> suspect) necessarily a multiple of 3600. Should it be?
How do you go from "2005-05-03-12" to anything not a multiple of 3600?
1115110805 means 2005-05-03T09:00:05 Where did those 5 seconds come
from if you only input whole hours?
If you indeed do only use whole hours, where did your example line
come from? Did you make it up? Why?
> > You want to update every 3600 seconds, or sooner. If one timestamp
> > is exactly on the hour, and the next timestamp is 5 seconds late,
> > you'll loose an update.
>
> I'll change the step size to 1.5 hours (5400).
That's not what I'm suggesting. Especially not when your heartbeat
stays 3600. The heartbeat value monitors your input.
Last hour: 1117011600
Next hour: 1117015200
Difference 3600 <--- this is what heartbeat looks at
Last update: 1117011600
Next update: 1117015205
Difference 3605 <--- heartbeat declares the input dead
If you update at:
09:00 rate (GAUGE) 10
10:00 rate 20
11:00 rate 30
12:00 rate 40
then there's no problem. Now, one of the updates fails:
09:00 rate 10
10:00 rate 20
...............
12:00 rate 40
RRDtool sees nothing else than:
09:00 rate 10
10:00 rate 20
12:00 rate 40
Should RRDtool assume that the interval between 10:00 and 12:00 was
rate 40, or should this be the interval between 11:00 and 12:00 and
is the interval from 10:00 to 11:00 unknown? THAT is what heartbeat
is for.
heartbeat 3600 to 7199:
09:00 rate 10 -> between 08 and 09 rate 10
10:00 rate 20 -> between 09 and 10 rate 20
12:00 rate 40 -> between 11 and 12 rate 40, 10 to 11 unknown
resulting PDPs: 10, 20, Unknown, 40
heartbeat 7200 or more:
09:00 rate 10 -> between 08 and 09 rate 10
10:00 rate 20 -> between 09 and 10 rate 20
12:00 rate 40 -> between 10 and 12 rate 40
resulting PDPs: 10, 20, 40, 40
> I guess I could have just done entered the data into an rrd at that
> stage. In that case, what would a reasonable heartbeat be? There
> were multiple log entries per second while sober was hitting our mail
> server. A 10 Second heartbeat?
You could have (I am not suggesting you should have) a database with
a step size of 1. You could have a heartbeat of 86400. If you update
somewhere on a day, all previous intervals will be filled.
In another application, you could have a step of 3600 and a heartbeat
of 3600. Updates must occur each hour and on the hour. If one update
is missed, this results in unknown data.
In yet another application, you could have a step of 3600 and a heartbeat
of 7200. Updates must occur each hour and on the hour. If one update
is missed, the next one will set the average rate for two hours at a time
but if more than one update is missed, this results in unknown data.
The last example has step==3600 and heartbeat 4000. Updates occur
each hour, but not necessarily on the hour. If an update is more
than 4000 seconds after the previous one, this results in unknown
data. One update at 10:59:55 and the next at 12:05:23 is fine.
All four examples result in PDPs, some of them may be unknown data.
Each PDP represents _exactly_ 3600 second (yes, even in the last
case). Input values have been normalized to rates during a standard
interval.
Next is to transfer these PDPs to the RRAs.
RRA:AVERAGE:0.5:1:24 "I need one PDP per row, I have 24 rows"
RRA:AVERAGE:0.5:24:1 "I need 24 PDPs per row, I have 1 row"
Both RRAs cover the same amount of time. However, the last one
is more suitable for looking at large amounts of time (for instance,
the yearly graph).
Alex
--
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://lists.ee.ethz.ch/rrd-users
WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
More information about the rrd-users
mailing list