[rrd-users] gmetad COUNTER type RRD files contains all zero values!

Alex van den Bogaerdt alex at vandenbogaerdt.nl
Thu Dec 11 23:28:26 CET 2008


----- Original Message ----- 
From: "Guolin Cheng" <guolin at alexa.com>
To: <rrd-users at lists.oetiker.ch>
Sent: Thursday, December 11, 2008 10:32 PM
Subject: [rrd-users] gmetad COUNTER type RRD files contains all zero values!


> But for COUNTER type metric, all the valid CDP inside RRD file becomes
> zero with only a few exceptions. I suspect that it could be related to
> the time issues (step is 15 seconds) of the RRD file, while the gmond
> client collecting data every 20 seconds, and thresh-hold is set to 60
> seconds.

Unlikely.

I don't know the program feeding data to rrdtool, so I can only answer in a 
generic way.

Perhaps you can find debugging/data logging in the program, so that you can 
see what it is giving to rrdtool.  With that logging, in combination with 
the settings from the RRD, we can figure out what happens.

Alternatively you could create a test entry and change the data source type 
from counter to gauge. That should give a rough indication of what is sent 
to rrdtool. Use rrdtool tune for this.

> If the step is a big issues -- since COUNTER type metrics calculate
> valid value by subtract previous sample value from current sample value
> but the two sample value mostly are the same -- How can I set the 'step'
> from metric module?

It is:  (current_countervalue - previous_countervalue) / (current_time - 
previous_time).

This results in a rate, something per second.  E.g. 
(100,000,001-100,000,000)/(1229034000-1229033980) = 1/20 which is 0.05, a 
number easily handled by rrdtool.


> Another interesting point is that the network bytes in/out, which
> normally looks like a 'COUNTER' type metric, is in fact created by
> gmetad into a GAUGE type file(s) bytes_in.rrd and bytes_out.rrd, Any one
> can explain how these data sequences are collected?

GAUGE, and COUNTER, is about the input.  It determines *how* a rate is 
computed by rrdtool. For GAUGE, the input already *is* a rate and rrdtool 
needs not compute one.  For COUNTER, the process is as I showed above. After 
the input is transformed into a rate, RRDtool doesn't know nor care what the 
input used to be.

The database you showed got zeros as input. E.g. 
(100,000,000-100,000,000)/(1229034000-1229033980) = 0.

(notice that I changed current_countervalue in the example I used earlier).



More information about the rrd-users mailing list