This means that when you have a measurement that changes suddenly, then<br>the data stored in the RRD file tends to lag behind slightly (for 10<br>thanks, Henrik.  To get some dynamic data quickly, I used $((RANDOM%100)) which jumps up and down like crazy.  If RRDTOOL store averages only, that makes perfect sense.
<br><br><div><span class="gmail_quote">On 1/16/07, <b class="gmail_sendername">Henrik Stoerner</b> <<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The way RRD files work means that they will practically NEVER store the<br>exact value you push into them. Whenever you update an RRD file with a<br>new measurement, it looks at how long time has passed since the previous
<br>update, and then computes what the new value "should" be, if the update<br>had occurred at exactly 300 seconds interval.<br><br>This means that when you have a measurement that changes suddenly, then<br>the data stored in the RRD file tends to lag behind slightly (for 10
<br>minutes or so).<br><br>Hobbit feeds the percent-used measurement into the RRD files, and<br>rrdtool takes care of all the data manipulation needed to create graphs<br>from the data. BUT - Hobbit looks at the measurements BEFORE sending
<br>them through rrdtool. So Hobbit will trigger an alert as soon as the<br>measurement says "97% used", regardless of what data the RRD-file has as<br>the CUR value.<br><br><br>Regards,<br>Henrik<br><br><br>To unsubscribe from the hobbit list, send an e-mail to
<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br><br><br></blockquote></div><br>