[collectd] Strange SNMP collection glitches

[Florian Forster]

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 [0]. 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
legitimate value.

You can change the DS type of existing RRD files using
  rrdtool tune --data-source-type …
  (see rrdtune(1))

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 …
  (see rrdtune(1))

> 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.

Regards,
—octo

P.S.: I've CC'd the mailing list because your first question is probably
      interesting for other people, too.

[0] <http://collectd.org/wiki/index.php/Data_source>
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20100113/4386f419/attachment.pgp