[asterisk-dev] Additional SNMP stats request
Jeff Gehlbach
jeffg at jeffg.org
Mon Aug 20 17:16:32 CDT 2007
Hi!
On 20Aug , 2007, at 2:43 PM, Justin Killen wrote:
> The metric of calls over the last 5 minutes is more geared toward
> current mrtg implementations with network cards - there is a value for
> the number of transmitted bytes. E.g. you could check now and see
> that
> there are 100 bytes transmitted, then check again in 5 minutes and see
> that there are 200 bytes transmitted, then you could know that
> there was
> 100 bytes transmitted over that 5 minute span.
You're referring to the ifInOctets / ifOutOctets Counters in the IF-
MIB ifTable, I think. Curt's "calls processed" object from Bug 10057
also behaves like a Counter (monotonically increases until it rolls
over MAXINT).
> Taking this concept into
> initiated calls, there could be a 'number of initiated calls' node
> that
> could simply count incoming calls on a particular interface. So it's
> not the numbers themselves that are interesting, but rather the
> deltas.
Do note that the ifIn/OutOctets objects from IF-MIB are indexed with
the ifIndex of the interface to which they apply, whereas both the
objects that 10057 adds are system-wide scalars. I'll touch on this
again in a second.
> As for the average time aspect, what' I'm really looking for is line
> usage. Similar to the above, if I know that the delta of my Zap
> interface's UP status over the last 5 minutes is 2 minutes and 30
> seconds, and I know I have had 5 calls since then, I can assume an
> average call length of 30 seconds.
Here you'd be looking for an indexed resource. Things get a bit
dicey in * when you start trying to model those -- it works fine for
Zap channels, since those are concrete entities that continue to
exist until they are manually removed from the system. The model
breaks down when you start talking about other channel types, though,
because most channels spring into existence when a call is initiated
and then vanish into oblivion when that call is destroyed, leaving
behind only a CDR. The only exception to that rule that strikes me
off hand is trunks, which have their own distinct set of modeling needs.
> there are a
> LOT of different tools out there (mrtg, munin, cacti, openNMS, etc)
> that
> already know how to interact with SNMP, so that seems like a logical
> place (IMHO) to expose such data natively.
I think you're right about SNMP being a logical interface for this
kind of data. I also think it's critical that we target the objects
in the * MIB not just at MRTG and the great legacy of point tools
that it has spawned, but at enterprise-grade management systems like
OpenNMS, InfoVista, eHealth, and the like. If those higher-end tools
are satisfied, then * will be considered to have world-class SNMP
support.
-jeff
More information about the asterisk-dev
mailing list