[Asterisk-Dev] Debugging: selectable feature?

[Tilghman Lesher]

On Thursday 27 January 2005 16:47, John Todd wrote:
> At 2:28 PM -0600 on 1/27/05, Tilghman Lesher wrote:
> >On Thursday 27 January 2005 02:07, John Todd wrote:
> >>  I find myself wading through very long trails of debugging logs
> >> for Asterisk calls, which is terribly difficult (impossible?)
> >> when there are high volumes of calls on a system.
> >>
> >>  I am not familiar with the innards of how debugging is
> >> activated or deactivated, so perhaps this question reflects that
> >> poor understanding:  Would it be possible to create an
> >> application that,
> >
> >Log levels, like verbose levels, are currently enabled globally. 
> > There is no facility currently to enable certain modules to log
> > more or be more verbose than others.  It's all or nothing.
>
> That's too bad.  My experiences with debugging individual calls
> which create error conditions (crashes, PRI problems, SIP problems,
> whatever) have been difficult, to say the least.  The lack of
> timestamps or channel indications on the output is discouraging in
> high-churn call environments.   I can't even "grep" through a
> logfile of applications that were launched, based on what channel
> ID called them.  Oh well.

You're not alone when you see this as a problem.  I'd also like to
selectively enable debugging for small bits of code.  The problem is
the changes are going to be extremely involved and will generate a
very large patch, when you consider every module.  The other question
to be answered is how granular we want this:  for example, should the
log level be determined only by module or should there be multiple
granularities within a module (i.e. debugging PRI channels without
debugging FXS channels)?  And furthermore, should it be determined
not only by module or resource, but also by individual channel?  Each
of these options is going to incur an extra amount of work, though it
makes the ability to control logging much nicer (more specific).

> >  > when called, activates debugging output (very verbose) to the
> >  > ast_cli
> >>
> >>  window, or changes the status of that channel for it's duration
> >> to be "very verbose"?   This would help me a great deal in
> >> debugging problems with specific channels; I can always create a
> >> GotoIf or extension mapping that activates the debugging on
> >> certain circumstances.
> >
> ><snip>
> >
> >>  Even if I could just turn debugging on and off on some type of
> >>  event-based triggers that do not isolate the debugging to a
> >> specific channel, that would work - temporal isolation is better
> >> than no isolation, but not as good as event-chain isolation.  I
> >> might be interested in creating some sort of dialplan that lets
> >> me remote-control my Asterisk system into dumping a bunch of
> >> logging data to the logfiles by DTMF sequence (without running
> >> an ugly script to move things around in logger.conf and issue a
> >> "reload".)
> >
> >There's nothing preventing someone from writing a CLI command to
> > do: CLI> logger set {console|logfile}
> > {debug,notice,warning,error}
> >
> >We could probably create the corresponding application and manager
> >interface commands at the same time, as well.
>
> OK, that's certainly a step in the right direction, though it's a
> short hop from that to writing an app that does the same thing,
> right?  (heck, using a "System" call might do the same thing,
> though ugly.)
>
> Now... to find... "someone"... :-)

I have no qualms about writing the second option, but the first is too
involved without getting Mark involved in the discussion first.  It
simply involves too much work to get an implementation only to be
told, "we can't do it that way; do it this other way."

-- 
Tilghman