[asterisk-users] Realtime status feature - user feedback needed

[Atis Lezdins]

Hello users,

I had developed several patches that allows to monitor current status
of queues/channels in realtime db. For example specifying realtime
family "channels" will make asterisk to keep current channel list in
realtime database engine. The same would be for queue callers and
queue members (already partially available in 1.4).

However I encountered a resistance from Asterisk developers, as they
don't wish to accept my patches - because they don't wish to support
another interface. As I read in Bug Guidelines, if enough users
request this, it should make into asterisk, so I'm asking You to
express Your opinion on those features.

*** So, realtime status - what's this all about?
Basically you get output of "show channels", "show queues", etc
directly in Realtime table (Realtime = database engine system for
Asterisk). So, Asterisk will automatically update database upon any
changes of channels or queues.

*** Why would You need that?
In beginning I created this in order to deal with large amount of
monitoring software. If there's lot of users monitoring status, some
kind of cache should be put into place. With current Asterisk
interfaces this would mean either inquiring current status or
developing a daemon that follows up all events and collects them to
keep current picture always ready. I just decided to move this layer
to database engine, which deals really good with this stuff.

*** Rapid development of monitoring tools
What it takes to create custom monitoring tool now? AMI event
listener? AJAX page that gets changes from built-in webserver?
All this takes lot of time to learn and start using. Adding just few
config lines in "extconfig.conf" would allow to automatically populate
database with current status - so it's accessible easily from any
programming language. All the info is "just there", no need for
processing or analyzing.

*** Performance / Scalability
Inquerying queue status means that there is lock put on queue list,
all queues are traversed, information gathered and then returned. If
lot of instances of monitoring software need to have this information,
it's obvious that this would mean too much locks. So, as database
update is thrown whenever some change is happening, it means that no
additional locks are created for monitoring purposes. Transaction is
sent to database engine, which keeps relatively small tables of
current status. Then any number of clients can access data directly
without any locking. Even 200 concurrent calls with 10 new calls per
minute would still be a tiny load for MySQL. This can also be scaled
by moving database to another machine, thus allowing more raw CPU
usage for Asterisk.

*** Development maintenance
Those changes doesn't introduce any new functions in asterisk code.
They utilize currently available "Realtime" engine which is meant for
storage of configuration data. This just extends use of this engine
also for status data, so maintenance of this interface should not take
lot of work.

*** Current patches
If You are interested in using those changes right away, here are some
backports for 1.4:

Channels: http://ftp.iq-labs.net/realtime_channels/
Queue callers: http://ftp.iq-labs.net/realtime_queue_callers-1.4/
Queue members: work in progress, needs some refactoring and
optimization to make that effective.
Meetme: planned, no patches yet

To use any of those patches, you will need to add backport of
store/destroy to 1.4:
http://ftp.iq-labs.net/realtime_store_destroy-1.4/

*** Supporting this feature
If You find that those features would be good for merging into
Asterisk, please write a comment in bugtracker:
http://bugs.digium.com/view.php?id=12556

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835