"Leslie Clark" <lclark@us.ibm.com> writes:
> I never do the math anywhere. I let Netview do it for me.
>
> There is no coercion involved. These variables (the ones you need
> for monitoring the error and discard rates) are all properly defined
> as counters in the mib files, so Netview, seeing that they are
> counters, does the math for you.
Hi Leslie, thanks for helping me down this path further.
So is this to say that any time I refernce the OID of a given COUNTER
instance in mibExpr.conf what I am really getting is a computed rate
of change?
For instance,
If%inErrors \
"input errors/total packets received" \
.1.3.6.1.2.1.2.2.1.14. \
.1.3.6.1.2.1.2.2.1.11. \
.1.3.6.1.2.1.2.2.1.12. \
+ / 100 *
Does the calculation actually become:
(ifInerrors_per_second/(ifInUcastPkts_per_sec+ifInNUcastPkts_per_sec))*100
where any value v_per_second is computed as (v(t2) - v(t1)) / t2-t1 ??
Is that how it works?
> even though they are defined in the mib as integers. And you are
> right, you could not properly use one of those loc* mib variables,
> coerced, in a mib expression. But real counters are no problem.
Ah. Okay--that's a useful concept I was missing. I hadn't considered
that NetView might automatically hit all COUNTER's with the
(v(t2) - v(t1)) /(t2-t1) formula as they come in. I guess I'm still
trying to verify when/where the treatment is done insofar as
thresholds are concerned.
> Try it. And compare the results to what you get when you do the math
> manually. Graph what is collected. You will see that it goes up and
> down, not just up and up.
I've been playing with the graphing. The problem with the graphing is
that the graphing application seems to do some math of its own so it's
difficult to know what exactly is going on when/where in the process.
--
Todd H.
http://www.toddh.net/
|