[asterisk-dev] Notes from SNMP breakout session

[John Todd]

>Hi!
>
>Some good discussion came from the SNMP breakout session this afternoon
>at astridevcon.  The conversation moved quickly from "what to do with
>SNMP / res_snmp" to the realization that a new layer / API is needed
>within Asterisk to provide internal stats.  The reasoning behind this
>thinking is that res_snmp is really the third component that needs to
>get at lots of internal data.  The CLI and the manager are the others.
>
>A new internal stats data API would become the place to go when you need
>information on the system's behavior or performance.  It would be
>somewhat like the event infrastructure that has come up in several
>discussions this week at astridevcon, only it's for take-out whereas the
>event stuff is for delivery.
>
>The CLI, AMI, and res_snmp would all become customers of this API.
>I think that the above comprise the full list of existing components
>that should be customers.  Do any others come to mind?
>
>Once the API customers are identified, the next step is to identify all
>the data that must be exposed to serve these customers and to define a
>generic way to represent the data internally.  Finally, the customer
>components can be moved one piece at a time to the new API.
>
>Concerns that came up in the breakout are the following:
>
>* Making the internal data representation generic enough for any
>   customer component to consume it -- what existing C-language projects
>   exist from which we could draw inspiration (aka steal code) in this
>   realm?
>* Getting the API done and debugged in time for 1.6 will be "fun"
>* Concurrency - the rest of Asterisk will be changing around and under
>   those working on this project.  Doing the work in a branch will help,
>   but awareness of this project in the developer community will be
>   critical.  Hence this post :)
>* Distributedness - same as with the new event stuff, the stats data API
>   needs to be designed with an eye towards working (or at least being
>   easily adapted) in a distributed installation.
>
>Comments earnestly solicited!
>-jeff


I'm a fan of making things instrumented, which is somewhat 
under-deployed in Asterisk.  The SNMP modules were a good start at 
allowing visibility into many aspects of the system - I'm pleased to 
hear there are discussions at making this more extensive.

The middle layer API is also a good thing.  I believe there are many 
consumers of this data, with more that we probably haven't visualized 
yet since that missing step is making it difficult to consider new 
applications.

My primary reason for posting is to comment that many of the channels 
themselves are both producers and consumers of data.  For instance, 
there are RTCP values that are not visible in the channels at this 
point, though they may be useful.  Every time one performs a "core 
show channel X/X" should that talk directly to the channel, or should 
it talk to the storage layer?  Is complete abstraction too clever?

The dialplan is also a consumer of this data.  It would be useful in 
some cases for the dialplan to self-examine statistics in order to 
make decisions (example: examine the packet loss on all 
currently-connected SIP calls to 1.2.3.4 and compare them to packet 
loss on all currently-connected calls to 4.5.6.7 and then send the 
current channel to whichever of those two is less lossy.)  This may 
be something fairly simple, like function that uses SNMP MIB values 
to gather data, or more functionally useful, like being able to 
specify channel names and then the value to obtain (yes, I know this 
is almost-but-not-quite possible with the CHANNEL function (hi, 
olle!) but there are parts missing that would be a pain to continue 
to manually add every time some new data is collected/presented in 
the structure, and it seems like this would be an obvious first 
candidate as a consumer from the middle layer.)

JT