Often customers will e-mail a support issue to me, and we’ll ask them to send us all of their logs for us to take a closer look. I’m often surprised when customers don’t use the built in logging class that we’ve created and made available in our Voice Elements Developer toolkit. In my experience, it is an excellent tool to get to the bottom of issues quickly.
There are several conditions that we log as a rule when using the Voice Elements toolkit. Most importantly, I’ll use a Try/Catch statement around my code, and log any exceptions that may occur. This way it’s easy to determine when issues occur. In addition, I’ll often log all of the responses to prompts that I get from users. In addition, whenever I enter or exit a function, I’ll log that as well. When users report issues, it makes things very easy to get to the bottom of issues. It can also be useful to add logs to new functionality so that you can quickly find any issues as you develop and debug your application.
I’ve seen several instances, where customers will send us their Voice Elements log, and we’ll determine that the issue is a simple application bug that could have easily been caught if they had implemented their own logging.
For many, there is a perception that logging can significantly impact the performance of an application. In our experience, we’ve found the performance impact to be negligible.
For example, HMP Elements logs all SIP packets sent and received, and we have found it to have little impact on our performance — in a high density system running 1000 ports. In addition, our logging tool has been deployed across thousands of different implementations, and we’ve yet to hear of a performance issue caused by it.