Reply

Employee
Employee
AJ
Posts: 18
Registered: ‎05-21-2012

Enabling and disabling debug logging

SIP Logs


##########################################################
Note: Debug logging settings require significant CPU usage, please only use debug logging settings during maintenance windows or low call traffic periods for troubleshooting purposes.
#########################################################

The sipmsg.log is most often used to troubleshoot SIP call flow issues. Logs all SIP messages that pass through the SBC, so this requires significant CPU resources (typically adds about 10-20% CPU):
To enable: notify sipd siplog
To disable: notify sipd nosiplog

SIP debug logs are also required when troubleshooting SIP call flow problems. The following command enables a subset of the full logging behavior of sipd on the Session Director:
To enable: notify sipd debug
To disable: notify sipd nodebug
Full debug logs are generated using the following:
To enable: log-level sipd debug
To disable: log-level sipd notice
The log file generated in both these cases is log.sipd.

H.323 Logs
The log.h323d is most often used to troubleshoot H.323 call flow issues:
To enable: log-level h323d debug
To disable: log-level h323d notice
The log file generated is log.h323d.
If there is not a lot of traffic on the SD and CPU utilization is low you can enable more verbose logging.
To enable: notify h323d debug
To disable: notify h323d nodebug
The log file generated is log.h323d.

MGCP Logs
The alg.log and log.algd are used for troubleshooting MGCP problems:
To enable: notify algd log
To disable: notify algd nolog
The log file generated is alg.log.
To enable: log-level algd debug
To disable: log-level algd notice
The log file generated is log.algd.

MBCD Logs
The mcbd.log and log.mbcd are used for troubleshooting MBCD problems:
To enable: notify mbcd log
To disable: notify mbcd nolog
The log file generated is mbcd.log.
To enable: log-level mbcd debug
To disable: log-level mbcd notice
The log file generated is log.mbcd. 


Signalman
mshadbolt
Posts: 25
Registered: ‎09-06-2012

Re: Enabling and disabling debug logging

I find that I have to scroll/move all the way to the end of sipmsg.log to look at the most recent test call info.

Is there a way to clear/delete/reset sipmsg.log?

Ideally I would reset the file, run my test, and then know that the contents of that log are only related to my test call?

(I'm in a lab environment where I know that I'm the only one making calls).

 

Thanks,

 


Employee
tallen
Posts: 124
Registered: ‎05-28-2012

Re: Enabling and disabling debug logging

[ Edited ]

You can use the command "notify <task_name> rotate-logs"  to rotate the log files so that you have a clean capture of the data you require. For sip the task_name is sipd so the command becomes "notify sipd rotate-logs".

 

This commands renames sipmg.log to sipmsg.log.1 and creates a new empty sipmsg.log. Any existing sipmsg.log.1 is moved to sipmsg.log.2 and so on.


Packetologist III
peetee
Posts: 375
Registered: ‎04-24-2012

Re: Enabling and disabling debug logging

A small typo in the above advice, it should read "notify sipd rotate-logs". Also note that you can use "all" instead of a task name to have the NOTIFY sent to all listening tasks. (E.g., "notify all rotate-logs")


Employee
tallen
Posts: 124
Registered: ‎05-28-2012

Re: Enabling and disabling debug logging

Whoops, thanks Peetee. I've corrected my orginal post now.


Employee
crushton
Posts: 9
Registered: ‎06-03-2012

Re: Enabling and disabling debug logging

On the D series there are the commands

 

clear log <task> [logfile|all] - which purges all rotated logs except the current one being written to

 

reset log <task> [logfile|all] - which rolls over the current log file and starts a new one

 

I usually do a reset log *@*, followed by clear log *@*, then make my call and collect the log files in order to make everything fresh.


Sparker III
natalie77
Posts: 5
Registered: ‎07-15-2012

Re: Enabling and disabling debug logging

How could I enable TCP debug?

 

Thanks


Employee
dschieszer
Posts: 214
Registered: ‎05-16-2012

Re: Enabling and disabling debug logging

I think the process for TCP is "atcpd" so you should be able to do "log-level atcpd debug" and the files should be log.atcpd.X

 

Also, I think I have used another log, atcpd.log that can be started by doing a "notify atcpd atcpdlog" and stopped by doing a "notify atcpd noatcpdlog" but I don't recall what the difference is in data between log.atcpd and atcpd.log.

 

Give it a try and see if you capture what you are looking for.  If you need some serious help with troubleshooting a TCP issue or interpreting the logs opening a ticket in the Support Portal may be your fastest path to resolution.


Signalman
mshadbolt
Posts: 25
Registered: ‎09-06-2012

Re: Enabling and disabling debug logging

Is there a quick way to search a log file (like sipmsg.log) without pulling it from the box and reviewing in a text editor? I'm thinking of something like a 'grep', 'pipe' or equivalent.

 

I'm porting lots of DIDs from other carriers onto a new SIP trunking service, and we want to easily just read a log file, preferably on the box through CLI, to verify that we're receiving the Invites for that particular DID from the carrier.

An example might be "show logfile sipmsg.log | inc 6505551234" or similar.

 

Until now we've been pumping the traffic out via packet-capture to a remote Wireshark destination, which allows us to see the live incoming messages, but this is limited to just one person (one packet capture destination). I'd like multiple engineers on a box to be able to see the same info, preferably by querying the same log file.

 

Thanks.

 


Employee
dschieszer
Posts: 214
Registered: ‎05-16-2012

Re: Enabling and disabling debug logging

[ Edited ]

Some of our latest Enterprise Edition software contains some onboard browser-based troubleshooting that might be similar to what you are asking for, but we don't have grep or similar commands available in the CLI.  On the new 6300 I think you can actually do an onboard packet trace and use standard capture filters (I can't wait to try that out myself!).  The best bet for the majority of existing systems might be to simply set up off-box logging and then you can send the logs to a LINUX/UNIX system and grep away at the files.  I have at least one customer who is using off-box logging then importing the files into a database so they can retrieve information via database searches.  Does that help?

 

You can check this thread about off-box logging:

 

How-to-get-sip-logs-continuously-from-acme-sbc