"Leslie Clark" <lclark@us.ibm.com> writes:
> These are the ones in the current mibExpr.conf, and are what I have been
> using for years. They are what was outlined some time ago in a Cisco
> document that covered recommended mib monitoring. Both should
> usually be thresholded at 1%, depending on your network. I'm presently
> using the ErrorRate on WAN links and find that repeated thresholds
> exceeded of more than 2% or 3% generally presages a link failure.
I'll hunt for that Cisco document. I'm aware of these existing in
mibExpr.conf, but continue to muse about the counter nature of all of
them and how that can make your alert latency (the time from when you
have a problem to when the threshold gets triggered) be strongly
dependent on how long the device has been up.
For example--if the counter is reset only on device boot, then imagine
the following scenario:
day 1: 0 errors. 10,000 packets of trafic
day 2: 0 errors. 10,000 packets of trafic
...
day 10: 0 errors. 10,000 packets of trafic
We've now got a denominator of 100,000 packets in these counters.
Now, day 11 comes and the world goes haywire:
day 11: 999errors. 999 packets.
Even though the entire day we didn't send a packet successfully, even
a 1% threshold wouldn't be reached because the denominator is holding
so much hysteresis of the "good" days.
2 questions:
Theoretically, is my understanding of these variables correct?
Practically, do you find that this effect dramatically slows your
alerting to a given problem?
Best REgards,
Todd
> ErrorRate \
> " (ifinErrors+ifOutErrors) * 100 \
> \ (ifInUcastPkts + ifInNUcastPkts + \
> ifOutUcastPkts + ifOutNUcastPkts)" \
> .1.3.6.1.2.1.2.2.1.14. \
> .1.3.6.1.2.1.2.2.1.20. + \
> .1.3.6.1.2.1.2.2.1.11. \
> .1.3.6.1.2.1.2.2.1.12. + \
> .1.3.6.1.2.1.2.2.1.17. + \
> .1.3.6.1.2.1.2.2.1.18. + / 100 *
>
Todd wrote:
> Howdy,
>
> I've got a best practices/survey question for the masses. How are
> you monitoring interface error rates?
>
> Given my (possibly incorrect) assumptions:
> o all the MIB2 variables you need are are COUNTER's (absolute from
> when box booted): ifInErrors ifOutErrors ifInUcastPkts
> ifInNUcastPkts ifOutUcastPkts ifOutNUcastPkts
>
> o you need to make a calculation of the current datapoint
> subtracted from the last polled sample for 6 different
> variables
>
> o and NetView can't combine the functionality of mib.coerce
> and mibExpr.conf....
>
> ..I don't see how you can do it with NetView.
>
>
> The equation I think needs to be solved is:
>
> "%errors_over_past_polling_period= delta total error / delta total
> traffic"
>
> or specifically,
>
> ((ifInErrors(t2)+ifOutErrors(t2)) -
> (ifInErrors(t1)+ifOutErrors(t1)))
> / divided by the quantity
> (
> (ifInUcastPkts(t2)+ifInNUcastPkts(t2)+ifOutUcastPkts(t2)
> +ifOutNUcastPkts(t2)) -
> (ifInUcastPkts(t1)+ifInNUcastPkts(t1)+ifOutUcastPkts(t1)
> +ifOutNUcastPkts(t1))
> )
>
>
> Can anyone elighten, debunk, confirm or provide another way to monitor
> a percentage of packet errors in NetView?
>
> --
> Todd H.
> http://www.toddh.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
> For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
> *NOTE*
> This is not an Offical Tivoli Support forum. If you need immediate
> assistance from Tivoli please call the IBM Tivoli Software Group
> help line at 1-800-TIVOLI8(848-6548)
>
--
Todd H.
http://www.toddh.net/
|