[asterisk-dev] Notes from SNMP breakout session

[Brandon Kruse]

I personally think all the infrastructure is already in snmp.c

All we need to do now is manage it, and add more content and statistics. 
All you really have to do is look up the CLI command you like and find the
function that returns the numbered or string result of certain commands.

For example, I have been hacking at this for a couple of weeks and I have 
gotten most of the IAX2 statistics that you get when you issue an iax2 show stats
CLI command.


I would love to have more people jump on the bandwagon and start deving on it. Then all
that is left to do is write some docs on the specific SNMP values and map them to what they
are. Write a sample template for cacti (done already) and nagios, and other leading SNMP monitoring
tools. Then we just let the community adapt and take it from there.

What do you think?

-bkruse


----- Original Message -----
From: "Marc Blanchet" <marc.blanchet at viagenie.ca>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Thursday, May 24, 2007 8:37:45 AM (GMT-0600) America/Chicago
Subject: Re: [asterisk-dev] Notes from SNMP breakout session

I was the one to suggest a new API as a shim layer between  
"customers" such as:
+ CLI (may be not all commands, but the first targets would be the  
show ones),
+ SNMP
+ manager
+ others (dial plan applications?)
therefore, the data is consistent between all views of the same data.
I did this in a previous life and this is really the way to go.

Given that the API is not intrusive, but added, the customers such as  
CLI can use whenever needed. no sync is needed.

this API work and its first customer (SNMP) should be included in  
1.6, whatever status of how "customers" of that API are using it or not.

my 2 canadian cents

Marc.

Le 07-05-23 à 17:14, Jeff Gehlbach a écrit :

> 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
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev