[asterisk-dev] CLI filtering

[John Todd]

At 2:20 PM -0800 2007/1/18, Steve Edwards wrote:
>On Thu, 18 Jan 2007, Steven Critchfield wrote:
>
>>On Thu, 2007-01-18 at 13:33 -0800, Steve Edwards wrote:
>>>On Thu, 18 Jan 2007, Steven Critchfield wrote:
>>>
>>>>Maybe go a different route, maybe try "tagging" log events. Say each
>>>>call to ast_log would have an extra arg which is an array of tags for
>>>>which we can filter on. In those tags, we can place any number of
>>>>interesting information such as channel, callerid, IP address, system
>>>>name, or subsystem generated from. Then you could just do a quick check
>>>>against the tags to see if it is one you want to exclude or include for
>>>>the filtered list.
>>>>
>>>>I don't know what the performance hit would be like for this way of
>>>>doing it. But the programming effort wouldn't be too much. A few lines
>>>>in ast_log to accept extra arg for tags, code to look for and deal with
>>>>tags. Of course then the going through all the ast_log calls and adding
>>>>the tags will be a bit of a chore though.
>>>
>>>The "tags" concept seems to be very workable to me. It can be added to
>>>the body of ast_log() first, and then added to each invocation of ast_log
>>>piecemeal and containing the information relevant to that section of code
>>>be it a literal, a channel number, or a caller id number.
>>>
>>>It's been a while since I've played with the va_start/va_end stuff. Can
>>>you tell how many arguments were consumed by vfprintf (for example) and
>>>then handle the remaining arguments as tag pointers?
>>
>>I was reffering to taggin as in the same ideas behind some web2.0 apps.
>>Tags are meta data that you can add that don't change the current
>>information. Tagging is used on web apps to filter or classify
>>information.
>>
>>I don't know if I would want to have the tags be displayed to console as
>>your question about vfprintf makes me think you where interested in. I
>>think maybe it might be interesting in the saved logs for later
>>dissection. But for the CLI, it would be more information added to the
>>hydrant that doesn't help one get their job done.
>
>We're on the same page. The tags would not be included in the 
>console output. My reference to vfprint was because that is what is 
>used in ast_log to build the output string. Additionally, passing 
>the tags as additional optional arguments means that you don't need 
>to build a tag list nor free a tag list with each ast_log invocation 
>-- the call frame will do it for you when ast_log returns :)
>
>Thanks in advance,
>------------------------------------------------------------------------
>Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
>Newline                                             Fax: +1-760-731-3000


I would be very much in favor of "tagging" from a dialplan-accessible 
(and AMI-accessible) trigger, which could either tag things in the 
debug log or raise a call to the console output.  I have very busy 
systems with only particular calls that create problems, and it would 
be nice to only see the output from the calls that I tag in a certain 
way, or redirect the output from those specific calls to a custom 
debug log.

exten => 1234,1,Debug(track-me,debug,tricky-problem)
exten => 1234,n,Dial(SIP/blah)
exten => 1234,n,Debug(track-me,none)

then, in logger.conf, a line like this:

track-me => adhoc

where "adhoc" is a special logging level that takes it's level 
dynamically from the dialplan/AMI.

The /var/log/asterisk/track-me file would contain something like this 
appended on it's end, where the tag would be inserted into the output 
file or stream, and then would stop as soon as the Debug command was 
called with a "none" option.  Any output, debugs, warnings, or 
verbose messages associated with that leg (or any spawned legs) would 
be tagged with whatever was in the "Debug" application call.  This 
could also be used to modify the output to the console, if the word 
"console" was used as the specified channel for debug output.

[Jan 18 06:53:45] [tricky-problem] Executing [1234 at stuff:1] 
Debug(track-me,debug,tricky-problem)
[Jan 18 06:53:45] [tricky-problem] Executing [1234 at stuff:2] 
Dial("SIP/2208-01289c2a3", "SIP/blah") in new stack
[Jan 18 06:53:46] [tricky-problem] Called blah/blah
[Jan 18 06:53:46] [tricky-problem] Call accepted by 10.1.3.2 (format gsm)
[Jan 18 06:53:46] [tricky-problem] Format for call is gsm
[Jan 18 06:53:46] [tricky-problem] SIP/blah is ringing
[Jan 18 06:53:48] [tricky-problem] SIP/blah is making progress 
passing it to SIP/2208-01289c2a3
[Jan 18 06:53:48] [tricky-problem] SIP/blah stopped sounds
[Jan 18 06:53:48] [tricky-problem] SIP/blah answered SIP/2208-01289c2a3
[Jan 18 06:53:55] [tricky-problem] Hungup 'SIP/blah'
[Jan 18 06:53:55] [tricky-problem] Executing [1234 at stuff:1] 
Debug(track-me,none)'

JT