[collectd] Strange SNMP collection glitches
octo at verplant.org
Wed Jan 13 12:07:01 CET 2010
On Wed, Jan 13, 2010 at 11:57:05AM +0100, Mirko Buffoni wrote:
> If that is the case, how could I solve this behavior which is going to
> cause the graphs to be unusable due to the oversized scale factor?
One way is to replace the COUNTER data source with a DERIVE data source
and set the minimum value to zero. DERIVE data sources are documented
at . Then, when the counter is reset to zero, the rate conversion
((new value - old value) / interval) will result in a negative value
(because "new value" is zero). This negative value is then ignored due
to the minimum value being zero. The downside is that this will happen
also when the counter overflows, so you will occasionally lose a
You can change the DS type of existing RRD files using
rrdtool tune --data-source-type …
Another possibility is to set a correct maximum value. For example, if
you have a 10 Mbps line you could set maximum to 1250000 (Byte/s).
You can change the maximum value of a DS using
rrdtool tune --maximum …
> In the meantime, I'll try to increase traffic to speed up the counter
> to reach the overflow point.
I don't think that will cause the problem. COUNTER data sources handle
*overflows* correctly, only counter *resets* are a problem. Resets are
often caused when an interface is taken down and up again. Especially
WAN interfaces are prone to this.
P.S.: I've CC'd the mailing list because your first question is probably
interesting for other people, too.
Florian octo Forster
Hacker in training
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20100113/4386f419/attachment.pgp
More information about the collectd