[rrd-users] Re: NNTP Statistics -wierd numbers appearing ?

[Alex van den Bogaerdt]

Brian Ipsen wrote:

> The database hase been created like:
> 
> rrdtool create NntpDb.rrd DS:dk-binaer-musik:COUNTER:36000:0:U

No maximum set --> *any* counter value lesser than the previous
one will be a real counter overflow and not a reset or error.

> RRA:MAX:0.5:1:600 RRA:MAX:0.5:6:700 RRA:MAX:0.5:24:775
> RRA:MAX:0.5:288:797
> 
> (the RRA values has been taken from MRTG, I hope they fit the data for
> daily, weekly, monthly and yearly statistics :-))

Yup, do the math and see:
600*5 mins (3000 mins)
600*30 mins (18000 mins) + previous consolidated (3000 mins, 100 * 30mins)
600*2 hours (72000 mins) + previous consolidated (21000 mins, 175 *2 hours)
732*1 day (1054080 mins) + previous consolidated (93000 mins, 64.583 *1 day)

[snip]
> ($first, $last) = ($c1->group("$group"));
[snip]
> if(defined($first))
> {
[snip]
> }
> else
> {
>    print "No reply from $group ! \n";
>    my $dkbinmusik = 0;
> }
> 
> my $rrd = "NntpDb.rrd";
> my $time = time;
> 
> RRDs::update("$rrd", "$time:$dkbinmusik");

"my $time = time;" followed by "rrdtool update $rrd $time:$value"
can be done as  "rrdtool update $rrd N:$value".  This is no worse
and saves a call to time().

Updating with zero if failed --> Counter is assumed to have wrapped
--> a *very* large value was encountered.

Suggestion:  set $dkbinmusik to -1 if a failure is encountered ...

>  996433500: 9.0733333333e-002
>  996433800: 9.0000000000e-002
>  996434100: 1.3836838984e+007

Assuming the zero was the cause of this:
  zero is equivalent to 2^32, this is the current number.
  rate = (current - previous) / (current_time - previous_time)
Substitute known numbers (assume 300 seconds for delta time):
  1.3836838984e7 = (2^32-previous)/300
  1.3836838984e7 *300 = 2^32-previous
  previous = 2^32 - 1.3836838984e7 *300 = 143915600.8000000000

So the previous counter value must have been approximately 143915600.
I don't know if that's a number that sounds right?

> What could be the cause of this problem ?? If the data from the NNTP server
> somehow is unavailable, should I then add the last stored value (requires
> fetch from the rrd), or should I simply not update the database (what's
> recommended) ?

If the value is unknown, you could enter an unknown.  You could also
choose to skip the update.  You have a large number as heartbeat so
the next update will fill two intervals if you just skip the faulty one.

... resume suggestion: and do:
"
if ($dkbinmusik < 0) {
   rrdtool update $rrd N:U"
} else {
   rrdtool update $rrd N:$dkbinmusik
}
"
to signal the unknown entry, or do 
"
if ($dkbinmusik > -1) {
   rrdtool update $rrd N:$dkbinmusik
}
"
to just skip the update.

In any case make sure to set an appropriate number as maximum.  I'm
sure you can come up with a number that the newsserver has as maximum.

HTH
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. | 
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
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://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi