[asterisk-dev] Additional SNMP stats request

[Justin Killen]

> 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).

Yes, this is what I was referring to.

> > 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.

I noticed that these were global, but for this implementation 100% of
the calls will be on the Zap interface, so that will suffice.  I think
in the future we would want this on a per interface basis though (more
on that below).

> > 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.

Right, doing this with a SIP channel, for example, would not make much
sense, as these are 'virtual' ports.  For hardware channels though, I
think it makes sense, as it can help to show utilization of the physical
hardware and aide in resource planning and expansion (as well as provide
justification to management).  So, it would be nice to have this at
least at a channel level (maybe it could even report back the max number
of connections available e.g. 8 for a tdm808 or 32 for a t1, etc).  I
think this would make sense for hardware implementations.  For SIP and
IAX connections, resource planning is more geared toward other metrics
like cpu usage, network I/O, etc that can be readily monitored already.

> > 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.

I couldn't agree more - I think the easier it is to monitor the system
stability and performance, the easier it is to be adopted by bigger
companies.

-Justin