[asterisk-dev] Additional SNMP stats request

Jeff Gehlbach jeffg at jeffg.org
Mon Aug 20 17:16:32 CDT 2007


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  


More information about the asterisk-dev mailing list