Using Azure Web Apps includes many benefits that come just out of the box, you just need to know that they're there and how to use them properly. Logging is one of those benefits that integrate seamlessly to your Azure Web App.
Reference to the official Azure Web Apps Logging Document
In this post I'll show ways on maximizing the Azure Web Apps logging experience.
These are the different log types you can get for your Azure Web App:
Web Server Logging - Also known as http logs or iis logs, this will log all requests to your website in W3C Extended Log File Format.
Detailed Error Messages - Detailed version of the html files produced when your website responds with an error message. This is good to enable for debugging some error responses in your website. It is stored in the website's file system.
Failed Request Tracing - Also known as FREB, here you can get lots of information from IIS through its different stacks for each failing request. Note that these log files are also stored in the website's file system.
You can get some more information about FREB here.
Eventlog.xml - You may see this file sometimes under your LogFiles directory of your website (d:\home\LogFiles). This file contains ETW designated events, usually it is generated and populated with errors of some crash that occurred.
Kudu Traces - In your website's file system under d:\home\LogFiles\kudu\trace you can find the traces file for Kudu which drives some of the developer experience features of Azure Web Apps like: git deployment and WebJobs.
Application Logs - See detailed information on application logs in the next section.
Log files stored in the website's file system will show up under
d:\home\LogFiles.
Setting different logs in the Azure portal
These are the logs coming from your Application/Service/Website/WebJob.
If you're using ASP.NET it's simple to write application logs, just use the Trace class, for example:
Trace.WriteLine("Message"); // Write a verbose message
Trace.TraceInformation("Message"); // Write an information message
Trace.TraceWarning("Message");
Trace.TraceError("Message");
In the Azure portal you can direct different verbosity levels to different targets (at the same time). The targets are: file system, Azure table storage and Azure blob storage.
For example you can have all Information level (and up including Warning and Error) logs go to Azure table storage and all logs (including Verbose and up) go to blob storage.
Setting application logs in the Azure portal
For node.js websites the way to write application logs is by writing to the console using console.log('message') and console.error('message') which goes to Information/Error level log entries. Currently the only supported target for the log files for node.js is the file system.
Other web site types like php and python are not supported for the application logs feature.
Triggered (Scheduled/On Demand)
Whatever is written to console output and console error will go to a log file for the specific triggered webjob run. You can see it on the WebJobs dashboard but the file itself is located under d:\home\data\jobs\triggered\{jobname}\{jobrunid}.
Continuous
Whatever is written to console output and console error will go to the application logs as log entries with log level Information/Error. The first 100 log entries when the continuous WebJob starts will also show up in the continuous WebJob log file that is available on the WebJobs dashboard.
The file itself is under d:\home\data\jobs\continuous\{jobname}.
.NET WebJobs
If you're using .NET console application as your WebJob, you can follow the same guideline as for an ASP.NET website. Once you use the Trace class, your traces are handled as application logs (including triggered WebJobs).
Here is the list of fields each application log entry consists of:
There are a couple a differences between logs stored in file system, table storage and blob storage:
Blob storage - Stored as a csv file with the following structure:
Timestamp(DateTime), Level, ApplicationName, InstanceID, Timestamp(Ticks), EventID, ProcessID, ThreadID, Message, ActivityIdTable storage - Each log entry is stored as a table entity, with a Partition Key that is the log's date (formatted as "YYYYMMDDHH") and a Row Key which is an ordered GUID to help get the logs in the same order as they happened.
File system - Has a subset of the fields mentioned in the following format:
{Date} PID[{Process ID}] {Event Type} {Message}
The activity id field can be very powerful. It can help you correlate all log entries which came from a single request.
The easiest way to use it is to enable Failed Request Tracing on the Azure portal. This will have a side-effect of setting an activity id for each request your website receives where the activity id will propagate to all your application logs.
The actual proper way to set the activity id would have been using this code in the
global.asax.csfile:public class MvcApplication : System.Web.HttpApplication { protected void Application_BeginRequest() { System.Diagnostics.Trace.CorrelationManager.ActivityId = Guid.NewGuid(); } }But since ASP.NET is doing some funky things, the activity id may get lost (become empty) when using async operations.
Note that the same activity id concept would work for .NET WebJobs. For that you should use: System.Diagnostics.Trace.CorrelationManager.ActivityId = Guid.NewGuid(); before an operation that requires an activity id.
File system
Log files will have some retention policy for each type:
Blob storage
Web server logs and application logs stored in blob storage can be configured with a retention policy for deleting log files older than X days.
One more cool feature that Azure Web Apps release recently is the Azure Site Extensions.
Azure site extensions is basically a gallery of extensions to your Azure Web App that can originate from Microsoft or from the community. These site extensions can be useful utilities for your website administration.
One of those site extensions is called Azure Website Log Browser.
The Log Browser makes it super easy for you to access all of your Azure Web App logs described here.
Features
The tool itself should be self-explanatory, just install and start using it.
Here are some screen-shots:
Install the Log Browser from the new Azure Portal
Main page
View a log file
View log entries from table storage
The Log Browser site extension is open source and is hosted on GitHub. You can use this repository to help you get started on your own site extension idea or to contribute to the Log Browser site extension.
Azure Web Apps has a very nice and powerful logging experience, together with the Log Browser you get an online dashboard and log viewing experience for free and with minimal effort.