[mrtg] Re: RouterUptime

Christopher E. Brown cbrown at denalics.net
Wed Nov 24 11:49:07 MET 1999

On Wed, 24 Nov 1999 alex at ergens.op.Het.Net wrote:

> > 	Having some fun here.  There is a RouterUptime setting, so one
> > can spec the host that the uptime setting comes from.  However, the
> > snmp var it polls seems to be hardwired.
> > 
> > 	This would normally not be an issue, but when monitoring a
> > host, it can be very wrong.  For example, if I have a host that has
> > been up for 60 days, but the SNMP daemon was restarted 32 days ago for
> > a config change, 
> > 
> > system.sysUpTime.0 = Timeticks: (275617995) 31 days, 21:36:19
> > 
> > and 
> > 
> > host.hrSystem.hrSystemUptime.0 = Timeticks: (519492554) 60 days, 3:02:05
> > 
> > 
> > 	RouterUptime takes host and community, but seems to be
> > hardwired to system.sysUpTime.0
> > 
> > 	Am I missing somthing here?  It would be nice to be able to
> > report actual system uptime rather than SNMP daemon uptime.
> > 
> MRTG uses SNMP for its statistics.  It would be wrong to take the
> hrSystem value.  If you get your statistics from somewhere else (ie.
> not SNMP) you make a choise to do so and you have to write a script
> to do so.  When doing this you should also provide the uptime by other
> means, inside your script.
> This is an interpretation problem and I'm sure somebody will disagree
> with what I say here.

	Yes, it does.  However, the label is RouterUptime, *not*

	If one is measuring the SNMP system, or using a SNMP
monitoring agent reporting SNMP subsystem uptime is a good thing.
However, reporting SNMP uptime as RouterUptime is not.

	Reporting one as the other simply because on many systems they
are always the same is silly.

	The *correct* thing (IMHO) to do is make it a settable option.
The default is fine the way it is, but the option to change the exact
SNMP var to poll would let the rest of us report accurate uptimes
without resorting to scripts.

	Scripting is a nice feature, but extremely silly to write
translation scripts for every service on every host you wan a correct
uptime for.

As folks might have suspected, not much survives except roaches, 
and they don't carry large enough packets fast enough...
        --About the Internet and nuclear war.

* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg

More information about the mrtg mailing list