[mrtg] Re: What stats are people monitoring?

Koelstra, J. (Jan) JKoelstra at MINSZW.NL
Thu Jul 18 14:55:53 MEST 2002


The treshold for Roundtrip time is arbitrary:
In the first place will the type of connection result in a certain
minimum roundtrip time. (A frame-relay link has a lower roundtrip time
than a channeled ISDN link with the same bandwith)
But even using the same type of connection and using the same gear at a
different site can show different roundtrip times. (all with lines that
are not overly used)

Secondly you get the odd packet that takes longer because of whatever
reason. Congestion is the main reason, but high CPU-loads on routers can
also be the cause.

When determining what is an acceptable roundtrip time and what is not
you have to combine both aspects.
Based on our own experiences we think 80 ms as acceptable on our
frame-relay links.

Jan.


-----Original Message-----
From: Bishop, Dean [mailto:dean.bishop at tcdsb.org] 
Sent: Thursday, July 18, 2002 1:48 PM
To: Koelstra, J. (Jan); Jeff Bolden; mrtg at list.ee.ethz.ch
Subject: RE: [mrtg] Re: What stats are people monitoring?


Good morning,

	For those stats that would have acceptable/unacceptable levels
what do you use as thresholds to determine if results are acceptable?
e.g. what roundtrip time is acceptable?

thanks,
dean

-----Original Message-----
From: Koelstra, J. (Jan) [mailto:JKoelstra at MINSZW.NL]
Sent: Thursday, July 18, 2002 5:09 AM
To: Jeff Bolden; mrtg at list.ee.ethz.ch
Subject: [mrtg] Re: What stats are people monitoring?



Jeff,

Basically we use MRTG for trend analyzing for a wide range of items.
Monitoring and error-reporting is done with HP Openview/NNM. In our
organization we monitor the following with MRTG: Routers
- traffic (do the lines have enough bandwith?)
- cpu load (is the router getting overloaded?)
- memory free (isn't any memory leaking?)
- roundtrip time to remote sites with mrtg-ping-probe (Is the delay
still acceptable?)
- number of active dial-in lines (When do we have to order an extra
PRI-line?)
Switches
- traffic on the uplink interface(s) (Is the bandwith sufficient?)
LAN's/VLAN's
- broadcast level (do we have to split the segment?)
Servers
- NIC traffic (just the same)
- cpu load (helps when sizing new machines)
- free diskspace (just the same)
- diskqueue length (just the same)
- memory pagefaults (just the same)
- memory allocated and free (just the same, but also to visualize
memoryleaks)
- # http hits (nice for the presentation to the management ;-) )
- # network connections (nice for the managers too, but also helpfull
for determining the number of required licenses for specific
applications)
- # mail messages sent/received to/from the oustide (mostly used for
detecting mail loops, also nice for the managers)
- temperature (Is the cooling system capable of keeping things under
control)
Printers
- number of printed pages (all users want to have their own printer, but
do they need one?)

I'm sure I missed a few small ones, but I think this is the main picture


Jan.


-----Original Message-----
From: Jeff Bolden [mailto:Jeff.Bolden at sterlingsavings.com] 
Sent: Wednesday, July 17, 2002 10:28 PM
To: mrtg at list.ee.ethz.ch
Subject: [mrtg] What stats are people monitoring?



Well, I am pulling stats down from 100+ routers and have more info than
I could possibly imagine... =) But it got me thinking about what info is
"critical" and what is just "nice to have" stuff. MRTG makes it easy to
get data-overload. Soo....

I was curious as to exactly what stats people are pulling from routers
for monitoring. I'm pulling some of the more obvious ones like Traffic,
Errors, Discards, FECNs/BECNs, Utilization, CPU and Data Buffers used
for my Frame links, and Traffic, Collisions, and Errors on my Ethernet
side. What else are people pulling to get the "big picture" of the
health of the WAN at your location, and why? =)

I feel like I'm missing something, but I've been staring at CFG's and
OID's for too long and can't think of anything... =)

Jeff Bolden

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



More information about the mrtg mailing list