In software development, you will never anticipate every error when developing. There are times when code has been in place for many days, weeks, months even years without any issues and all of a sudden it crushes badly. You open up your project to have a glimpse on the code and there you notice the comment that you had left there years ago – “When I wrote this, only God and I understood what I was doing. Now, God only knows”. I know this made you panicking. This is where logging comes into play. A logging system constantly keeps an eye on every interaction that are occurring between visitor and your website. If something goes unusual it start keep tracking those issue so that you can do further analysis. That is why even experts suggest that when something goes wrong the first thing that developer should check is the log file and the log database.
Enough talk! Lets get into the main business. I know I can put the tracing method in the following way :
System.Diagnostics.Trace.TraceInformation("Trace statement"); System.Diagnostics.Trace.TraceWarning("Warning statement"); System.Diagnostics.Trace.TraceError("Error statement");
When in development phase I could check all these trace information against my development site right at my output window of visual studio. But now I want to check these info for my production site. What I need to do is to enable some of the configuration from the azure portal. Open up the Settings blade for your website and click Diagnostics logs.
Clicking the Diagnostics log option will open up a new blade from where I need to enable Application Logging.
From here I can also filter which sorts of information/log report (informational, warning or error ) I would like to have store for future investigation.
Along with the application log this panel also allow me to store the following type of logging message if i want.
- Web Server Logging : This option will let me trace HTTP transactions info. I can use this info to check which browser is client mainly using, time taken to execute an action, even I can trace client IP address.
- Detailed Error Logging – This will let me log detailed information for any error occurred.
- Failed Request Tracing – I can get detailed information on failed requests by enabling this. This log includes trace of the IIS components as well which can be useful in identifying error.
Under the hood this service automatically log deployment information when you publish content on your site. This gives you the flexibility to to implement the log tracing for your custom deployment script.
So far, I have setup all the required configuration to store my desired log information in desired storage. Now, lets imagine something really bad happened. I need to download the log file. This is quite easy. I can again go the Logs blade to check my FTP credential.
Once I have the credential on my hand I can open up my favorite FTP client to download all the log file that was generated for my site. But we have seen earlier that azure gives me the flexibility to store different type of log information. This make sense that all the log files will not be stored in the same directory.
The directory structure that the logs are stored in is as follows:
- Application logs : Navigate to /LogFiles/Application/ to download application specific log. This folder may contains one or more text files.
- Web Server Logs – Web server log information can be downloaded from /LogFiles/http/RawLogs this location.
- Detailed Error Logs : Navigate to /LogFiles/DetailedErrors/ to download detailed error logs. This folder contains one or more .html files.
- Failed Request Traces : Navigate to /LogFiles/W3SVC#########/ to download failed request information. This folder contains one XSL file and one or more XML files. Make sure to download the XSL file into the same directory as the XML file. This will ensure human readable formating of your data when viewed in Internet Explorer.
- Deployment logs – Deployment logs can be downloaded from /LogFiles/Git.
Having the log information in flat file is good but I would like to check those in real time. What I can do is open the Tools blade by clicking Tools option.
Clicking the Log Stream will open up a new blade that shows live log information of our interested site. From here If I can check both application log and web server log.
If you don’t log errors, warnings and debug information, how will you know what went wrong when the site goes down? send the information in emails, and also log to file in case the emails don’t go through. That way, either you have an email if the file system is full, or you have a log if the mail server is down. Error handling will allow the application to gracefully handle errors and display error messages accordingly.
From my experience I can say logging system become more helpful when web app actually gets in the road. It helps to catch the unexpected exception by collecting detail information which you will never be able to reproduce in a debugger.
Good Read :