ARI method of posting log messages to Asterisk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 16, 2013 at 2:49 PM, Mark Michelson <mmichelson at digium.com> wrote:
> Hey folks,
>
> Have a look at ASTERISK-22699 [1]
>
> The issue pertains to allowing for ARI to write content to Asterisk's logs.
> I'd like to propose my ideas for how logging from ARI could be done. First,
> let's consider what an Asterisk log message looks like:
>
> [Oct 16 17:20:23] ERROR[20023] foo.c:666 I AM ERROR.
>
> The message consists of 6 parts: the timestamp, the level, the thread ID,
> the file name, the line number, and the message. Of these, the timestamp and
> thread ID should be filled in by Asterisk. The other four parts could
> potentially be fed into Asterisk by an ARI application.
>
> Moving on to the ARI method for logging to the Asterisk log, I think it
> should be something like:
>
> POST /asterisk/logMessage
>
> At a minimum, the parameters for this would be
>
> level: One of the Asterisk log levels (such as "error", "warning", "debug",
> etc.)
> message: The string to print to the log
>
> The minimum is nice in that it keeps the API call simple, but it has the
> downside of making your messages look like this:
>
> [Oct 16 17:20:23] WARNING[20023] ?:0 You're tearing me apart, Lisa!
>
> We could expand the method a bit by adding in a couple more parameters:
>
> fileName: The file name to place in the log message.
> lineNumber: The line number to place in the log message.
>
> This way, the previous log message would look like this instead:
>
> [Oct 16 17:20:23] WARNING[20023] cool_app.py:143 You're tearing me apart,
> Lisa!
>
> Expanding further, consider that log levels such as debug and verbose also
> have an additional integer value associated with them so that they are only
> printed depending on what you've set core debug or core verbose to. We could
> just make the assumption that all verbose and debug messages logged through
> ARI have a 0 for this value, or this integer value could be exposed as part
> of the ARI method as well.
>
> So what do you thing of this proposal? What degree of control would you
> prefer to have for writing log messages to Asterisk's logger?
>
>
> As a second discussion, consider that Asterisk, since 1.8 I believe, has had
> the concept of dynamic log levels. What this means is that a module can
> register a log level called "FOO" for instance, and log messages directed at
> that level would look like:
>
> [Oct 16 17:20:23] FOO[20023] bar.c:717 They're eating her! And then they're
> going to eat me! OH MY GOOOOOOOOOOOOOOOOOOD!
>
> This could be a useful concept for ARI in one of two possible ways.
>
> 1) The ARI implementation in Asterisk could register a log level at startup
> (called "ARI" possibly) that ARI app developers could write to in order to
> keep their messages at a different level from any of the other messages in
> the system.
>
> 2) We could expose an ARI call that would allow app developers to create
> their own dynamic log levels on the fly. For instance, you could have
>
> POST /asterisk/logLevel
>
> with the parameter
>
> level: The name of the level to register to Asterisk
>
> This way you could record different log messages at different dynamic log
> levels if you desired.
>
> Would dynamic log levels be useful for you in your applications? If so,
> would you prefer to have a dedicated "ARI" level to write to or would you
> prefer the ability to create your own levels to write to?
>
At first glance, why would we want ARI developers to use the ARI for
logging? For me in python it is as simple as:

import logging

LOG = logging.getLogger(__name__)
LOG.debug('You're tearing me apart, Lisa!')

Plus I get all the functionality of the logging library to control how
I want to format the message or where I want to store them.  It seem
to the logging functionality within ARI is unnecessary.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger



[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux