> 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?
looks like it.
> 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?
Empirally tested, it appears that it does. Since the polled values
are all COUNTERs, it seems that when snmpCollect grabs each OID, it
immediately computes its "rate of change" over the prior period.
Based on what I'm seeing, any time you specify a COUNTER's OID in
mibExpr.conf what actually gets put in the equation at evaluation time
is rate_of_change_per_second() of that OID computed as the difference
between the current sample and the prior sample divided by the number
of seconds in the polling period.
The descriptions of the default MIB expressions are very misleading
making one think you are computing things based on numbers of packets
and numbers of errors when in fact it appears you are computing things
based on rates. :-\
I'll see if I can work the proper incantations to suggest that this
default treatment of COUNTER variables be documented somewhere logical
like the mibExpr.conf man page.
Best Rgards,
--
Todd H.
http://www.toddh.net/
|