System information

Type Description
debug Debugging is only useful if you are troubleshooting a problem with the Asterisk code itself. You would not use
debug to troubleshoot your dialplan, but you would use it if the Asterisk developers asked you to provide logs for
a problem you were reporting. Do not use debug in production, as the amount of detail stored can fill up a hard
drive in a matter of days.
a
verbose This is one of the most useful of the logging types, but it is also one of the more risky to leave unattended, due to
the possibility of the output filling your hard drive.
b
dtmf Logging DTMF can be helpful if you are getting complaints that calls are not routing from the auto attendant
correctly.
fax This type of logging causes fax-related messages from the fax technology backend (res_fax_spandsp or
res_fax_digium) to be logged to the fax logger.
* This will log EVERYTHING (and we mean everything). Do not use this unless you understand the implications of
storing this amount of data. It will not end well.
a
This is not theory. It has happened to us. It was not fun.
b
It’s not as risky as debug, since it’ll take months to fill the hard drive, but the danger is that it will happen, say, a year later when you’re
on summer vacation, and it will not immediately be obvious what the problem is. Not fun.
There is a peculiarity in Asterisk’s logging system that will cause you
some consternation if you are unaware of it. The level of logging for the
verbose and debug logging types is tied to the verbosity as set in
the console. What this means is that if you are logging to a file with the
verbose or debug type, and somebody logs into the CLI and issues the
command core set verbose 0, or core set debug 0, the logging of those
details to your log file will stop.
Reviewing Asterisk Logs
Searching through log files can be a challenge. The trick is to be able to filter what you
are seeing so that you are only presented with information that is relevant to what you
are searching for.
To start with, you are going to need to have an approximate idea of the time when the
trouble you are looking for occurred. Once you are oriented to the approximate time,
you will need to find clues that will help you to identify the call in question. Obviously,
the more information you have about the call, the faster you will be able to pin it down.
If, for example, you are doing verbose logging, you should note that each distinct call
has a thread identifier, which, when used with grep, can often help you to filter out
everything that does not relate to the call you are trying to debug. For example, in the
following verbose log, we have more than one call in the log, and since the calls are
happening at the same time, it can be very confusing to trace one call:
$ tail -1000 verbose
[Mar 11 09:38:35] VERBOSE[31362] logger.c: -- IAX2/shifteight-4 answered Zap/1-1
[Mar 11 09:39:35] VERBOSE[2973] logger.c: -- Starting simple switch on 'Zap/1-1'
[Mar 11 09:39:35] VERBOSE[31362] logger.c: == Spawn extension (shifteight, s, 1)
logger.conf | 525