ASP.NET Web API Logging and Troubleshooting

Thursday, April 18, 2013

Logging exceptions to persistent store or email alert with exception stack helps developer to troubleshoot issues without having to debug the application. This practice helps in exception trend monitoring and improve the application. In the applications where security is high priority it is feasible to trace and log security exceptions. Mostly all of the tracing and logging technologies provide configuration driven trace levels i.e., Information, Warning, Error etc.

This article discusses various tracing and logging technologies and walks through 'configuring ASP.NET Web API application to log unhandled exceptions to database and generate email alert with exception stack using ELMAH'.

AppFabric provides two services for monitoring and caching services.

Monitoring services
Caching services

AppFabric is IIS extension that provides a dashboard to monitor and troubleshoot issues with in WCF and WF applications and services. Installation & configuring AppFabric creates database to store service trace as well. AppFabric installation and configuration process is discussed in another blog post.

AppFabric does not support ASP.NET Web API services to monitor and troubleshoot issues.

In order to log unhandled exceptions from ASP.NET Web API there are number of alternatives as outlined below.

Microsoft Enterprise Library : Exception and Logging application blocks can be utilised to log or email exception stack. Configuring Exception Handling application block is explained in my blog article http://weblogs.asp.net/sukumarraju/archive/2009/10/04/microsoft-enterprise-library-4-1-exception-handling-block.aspx

Configuring Logging application block to email exception block is discussed in my blog article at http://weblogs.asp.net/sukumarraju/archive/2010/08/21/email-exception-stack-using-logging-application-block-email-trace-listener.aspx

Log4Net provides another mechanism to log trace to text file or to database or custom location.

Being built on top of ASP.NET run time WebForms, Web API, MVC, Single page and SignalR can utilise above alternative technologies in addition to ASP.NET Health monitoring to log exceptions or trace to desired location for applications troubleshooting.

Logging unhandled exceptions using ELMAH

ELMAH is an open source tool for ASP.NET services, exceptions that are thrown in ASP.NET applications trigger event handlers in ELMAH tool. It provides pluggable out of box implementation.

Note that all the frameworks that run on ASP.NET can take advantage of ELMAH to log unhandled exceptions.

Step 1: Get the assembly from Nuget

PM> Install-Package Elmah.Contrib.WebApi

Installing the assembly updates application Web.config SectionGroup, connection Strings and Http modules.

Now in memory exception logging for the application, which can be accessed by navigating to http://serviceRootUri/elmah.axd as shown below.

  
  Note that when the application is stopped or app pool recycles the exception will be lost. Because these are in memory exceptions. Selecting the Details hyperlink in the above dashboard opens detailed exception stack with complete server variables and values.
  Step 2: Log exceptions to SQL Server database
  To store exceptions to SQL Server database get the assembly.
             1: PM> Install-Package elmah.sqlserver



Adding the package adds App_Readme folder with SQL script to generate database tables and stored procedures for logging exceptions. Also adds <errorLog> element to Web.config and connection String as below.


  
       1: <connectionStrings>


       2:     <add name="elmah-sqlserver" 


       3: connectionString="Data Source=****;


       4: User ID=****;Password=****;


       5: Initial Catalog=****;" 


       6: providerName="System.Data.SqlClient" />


       7:  


       8: <!-- of course it is required to update above SQL connection-->


       9:  


      10: <security allowRemoteAccess="false" />


      11: <errorLog type="Elmah.SqlErrorLog, Elmah" 


      12: connectionStringName="elmah-sqlserver"


      13: applicationName="Contact Manager" />


      14:  


      15: <!-- applicationName added to distinguish the applications in the 


      16: centralised exceptions database -->



  

  That is it! Unhandled from the application logged into database as shown below.

  

   

  Step 3: Email exception stack

  Provide SMTP (mail server), port, From and To email addresses in <errorMail> section as shown below.

  
    
         1: <elmah>


         2:   <errorMail from="robot@elmah" to="dev@groupcom"  


         3:   async="true" smtpServer="xxxx.xxx.xxxx.xx" smtpPort="25"/>


         4: </elmah>

  

  This generates email alerts with exception stack as shown below.

  

  Note that running applications can take advantage of ELMAH error logging, all it requires is copying required assemblies and configuration into Web.config.

  Conclusion:-  Logging all web applications exceptions to database helps to troubleshoot, it is feasible to implement a dashboard with the exceptions from various applications that are utilising ELMAH. All it requires to configuring ELMAHR (Elmah + SignalR), real time web framework. This is for another blog article !!

   

  Resources

  
    http://code.google.com/p/elmah/ 

    http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx 

    http://msdn.microsoft.com/en-us/library/aa479332.aspx

No Comments