--a2FkP9tdjPU2nyhF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 31, 2006 at 02:13:53PM -0500, matthew sporleder wrote:
> On 3/31/06, jonathan@dsg.stanford.edu <jonathan@dsg.stanford.edu> wrote:
> >
> > In message <20060331190158.GB5840@netbsd.org>Bill Studenmund writes
> >
> > >One thing I could see adding (which I don't really have time to do) is=
 add
> > >a sysctl to disable resetting the counters. If you're running SNMP or =
some
> > >such monitoring system, set it as part of /etc/sysctl.conf.
> >
> > A sysctl doesn't really help: anyone with superuser privileges can
> > turn off the sysctl, then zero the counters.
> >
> > I think we'd be better off to rework both the in-kernel support for
> > "ifconfig -z", and the current proposal to allow resetting
> > per-rpotocol statistics, to become compile-time options. Per the
> > discussion that such zeroisation makes sense for "experimental" or
> > single-user systems, the default should be
> >
> >      "zeroization not allowed".
>=20
> This is a very convenient feature even in production.  These counters
> are reset when the system is rebooted anyway, so it's just as well to
> allow them to be reset without that power cycle.  I don't see how this
> adversely affect SNMP monitoring at all.  It simply eases
> troubleshooting.

As David noted, the issue with monitoring (SNMP in particular, but
probably other monitoring systems as well) is that the counters are
treated as monotonic. Thus if you ever see the counter appear to go
backwards, what really happened is that it counted a lot, wrapped, and you
are seeing its wrapped build from zero.

If the counter is zeroed, the monitoring systems will treat it as having=20
wrapped, and will add a full-counter-amount - the previous reading to the=
=20
count. So depending on what the value was, your monitoring system will=20
most likely add an inordinate number of whatevers. If the counter is=20
64-bit, you could end up adding more (say bits) in one second than there=20
are atoms in the universe.

That's why zeroing can mess up monitoring. You really didn't transmit 2^63=
=20
bits in one minute, but your monitoring system thought you did. :-)

Now as to whether or not this should be possible, that's really a=20
site-specific thing. I can see some admins will NOT NOT NOT want it, and=20
some will really adore it.

Also, while zeroing will mess up the statistics, it's not like it will go=
=20
un-noticed. :-)

Take care,

Bill

--a2FkP9tdjPU2nyhF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFELdviWz+3JHUci9cRAoQtAKCJgxKNMzWvcMXwdEtGon71yt+eeQCeNlo+
zomAJ4haKxA20E9oWWJaGbY=
=+ICG
-----END PGP SIGNATURE-----

--a2FkP9tdjPU2nyhF--