Welcome to today’s post.
I will discuss how to log diagnostics information from your .NET Core application to an Azure Application Service.
I will also discuss how to optimize logging to account for Application Service Plan limits of cost and Storage Account limits.
Firstly, I will classify the levels categories of logging in the table below:
| Level | Categories |
| Disabled | None |
| Error | Error, Critical |
| Warning | Warning, Error, Critical |
| Information | Info, Warning, Error, Critical |
| Verbose | Trace, Debug, Info, Warning, Error, Critical |
The above levels of logging determine the frequency of logging and on which environment (development or production) we will output the log to. In the following table we show the frequency of logging associated with each category:
| Logging Category | Purpose | Logging Frequency |
| Trace | Debugging information. Sensitive information. | Very High. |
| Debug | Debugging information. Sensitive information. | High. |
| Information | Informative. Trace for application flow. Mainly for analysis purposes. | Often. |
| Warning | Includes non-critical errors. Application continues. Error may need investigation. | Occasional. |
| Error | Errors and exceptions that cannot be handled. Will require investigation. | Rare. |
| Critical | A critical failure. Requires immediate attention. | Very Rare. |
In development, the first two categories of logging, Trace and Debug are utilized quite often. Warning, Error, and Critical categories can be logged to the console. Trace, Debug and Information categories can be logged to a file.
In production, the Debug category should be disabled, and the next two categories, Trace and Information should be directed to a low cost, high capacity storage. Warning, Error, and Critical categories can be logged to a low or a high-volume data storage as the logs generated are infrequent.
Bearing in mind the above considerations, we can finetune our logging to optimize information output and storage costs in our cloud environment.
After implementation of logging in your application to capture errors like the one below in an exception block below:
catch (Exception ex)
{
_logger.LogError(ex, "Error running book search filter {searchstring}", SearchString);
..
}
Next, save, build and deploy the application to Azure.
Next, run the web application and induce the error.
Note: Errors from a web application hosted in an Azure Application Service will not output logs into the file system! In fact, if you go into the Kudu console and the folder D:\home\site\wwwroot\LogFiles, there will be no custom logs written there.
Where have the logs be written to?
The answer is a file within a blob storage container within Azure storage.
To logging for your Application Service in Azure, select the App Service Logs option under Monitoring in your Application Service.
A screen full of options displays including these options:
- Application Logging (File System)
- Application Logging (Blob)
- Web Server Logging
With the file system option, it will only be enabled for up to 12 hours, then it will be disabled.
This option is likely to possibly fill up the file storage space, so it is limited.
With the application blob logging option, this is the option that is permitted long-term for the web application hosted within the Application Service.
Once the blob logging option is selected, then enter a retention period. Bear in mind your storage limits and type of storage used (LRS, GDS etc). For an evaluation for basic plan, set this to 1. For production plans this may be a number of days.
Next, select a storage account to provision the blob file storage:
Next, save the logging settings for the Application Service.
Open the web site.
Induce the error.
Open the Azure Portal.
Open the Storage Account containing your blob. Navigate to the blob container folder:
Select the blob container:
Open the Blob file.
There is a URL which can be copied and pasted into the browser to download the log file.
Once opened, the error message that your application has logged will show.
If you nominated a level of Error as per the logging configuration screen, then Application Service will filter this particular error level and dump it into the log file as shown:
That’s all.
I hope this post has proved useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.
