[asterisk-dev] Asterisk Beacon Module Proposal

[Matthew Jordan]

On Fri, May 8, 2015 at 4:54 PM, Rodrigo Ramírez Norambuena
<decipher.hk at gmail.com> wrote:
> On Fri, May 08, 2015 at 11:49:39AM -0400, Moises Silva wrote:
>> On Thu, May 7, 2015 at 10:35 PM, Matthew Jordan <mjordan at digium.com> wrote:
>>
>> > Hey everyone -
>> >
>> > At the past several AstriDevCon events, we've had an open discussion
>> > about adding a module to Asterisk that would gather anonymous usage
>> > statistics. Said module would be used to help the Asterisk Developer
>> > community better support the users of Asterisk, as we would have some
>> > indication of the modules being used by the reporting segment of the
>> > Asterisk community.
>>
>>
>> Is there a need for this to be an Asterisk module itself and not an
>> external monitoring service/agent collecting (e.g via AMI) and pushing the
>> stats? I'm just thinking this is not the kind of thing that *needs* to be
>> in a C module. It'd be sad to have your Asterisk system crashing or
>> misbehaving because of a bug in the beacon module.

There's a few issues with doing it outside of Asterisk:

1) Not all of the data you may want to retrieve may be readily
available. Granted, right now, I don't think that's the case, but
there's certainly more flexibility if you have access to Asterisk's C
APIs.

2) There's no real way to guarantee that someone will run a daemon
next to Asterisk, or that said daemon won't have some other
interaction that we won't expect. The only way I can think of to
reasonably introduce such a daemon is to make it part of the Asterisk
'install' target, and/or add it to packages. I'm not sure if having a
separate daemon spin up suddenly on someone's system, with no
warnings, would be much better.

That being said, I do think there's a few small benefits to making
this part of Asterisk:
1) We can give a visual warning that it is enabled. That's not as easy
to do via an external process.
2) Disabling it is done in a manner that is similar to other Asterisk
modules - don't build it in menuselect, or disable it in a .conf file.
3) Less important, it would have access to the C APIs in Asterisk.
With the advent of the Stasis message bus, we have mechanisms that can
prevent said module from impacting the critical run-time parts of
Asterisk. That gives us a lot of the power/flexibility of the Asterisk
APIs, while minimizing risk.

Your point is a good one though. No one wants the statistics module to
have a negative impact on their system. To that affect, there's a few
ways the proposal on the wiki minimizes risk:
1) It's relatively simple, and doesn't try to get a bunch of
information out of a lot of modules that may or may not be there. To
whit, all of the APIs needed for the information are in the core, and
have a reasonably minimal impact on the run-time aspects of Asterisk:
  - ast_get_version/ast_get_version_num: version.h
  - ast_active_calls/ast_processed_calls: pbx.h
  - ast_startuptime/ast_lastreloadtime: global constants in options.h
  - ast_update_module_list: module.h
2) The project plans outlines tests that should be created for the
module. That includes standing up a version of the REST API in the
testsuite, and providing both nominial and off-nominal tests.

>
> Other idea is a create a service/agent using ARI, is really needed add this
> module on 11 version?.

There are more Asterisk 11 systems out there than Asterisk 13 systems
(which is not surprising in the least). If the goal is to get a good
picture of what Asterisk systems are out there, having a module that
applies to all of the currently supported Asterisk versions makes
sense.

ARI has no relationship to the server, either one stood up by someone
running Asterisk or the proposed community service. For the Asterisk
13+ variant of the module, an ARI resource is proposed for a local
Asterisk instance as a way to see what data was last transmitted.

> A point i dont saw in the doc is what happens when dont have internet for
> notified the stats or have a problem for send the request. There should be a
> queue of stats to notify but this could has a conflict with rate limit inbound
> request of api server.

I disagree. I don't think queueing statistics is a good idea. A lot of
things can go wrong; e.g., what happens if the Asterisk server is
behind a firewall that blocks HTTPS? We'd never send the data; the
data would pile up; Asterisk would consume all of the systems memory,
etc.

The proposal on the wiki aims for some element of simplicity.
Simplicity minimizes errors and risk. To Moises's point, no one wants
the anonymous statistics module to impact their service.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org