Azure App Service Tracing

Question

We have an app deployed in Azure App Service, and it has the below logging configuration:

If we are not using any methods in the System.Diagnostics namespace (System.Diagnostics.Trace / System.Diagnostics.TraceSource), then what is the relevance of this setting? We have noticed that the system performs poorly when the level is set to "Verbose" and the performance improves when the level is set to "Warning". However, we do not have code that uses

System.Diagnostics.Trace.TraceInformation or System.Diagnostics.Trace.WriteLine

to write a trace.

Answer 1

As others said, even if you do not call trace methods in your code, underlying components might do it. If tracing is enabled, and over time, it can cause memory increase and performance degradation.

You can find detailed information in this article:

Running in a Production Environment with Tracing Enabled

ASP.NET tracing is a powerful feature for troubleshooting applications, but it should never be left on in a production environment. ASP.NET tracing uses data structures such as DataTables to store trace information, and over time, these can cause a high memory condition that can lead to OOM.

See this blog post for more information.

As Byron Tardif mentioned in his reply, if possible, you can set the Level to error in production environment.

Answer 2

Keep in mind your code is not the only thing that executes when a request comes in.

Even if you are not using the System.Diagnostics.Trace namespace in your application, chances are you have some NuGet packages or other dependencies that might be.

In addition to this, the server code that hosts your app takes this input as a flag to spin up the necessary process to listen for and capture trace events and this in itself competes for resources with your app.

You should check the output file in your blob storage to get an idea of how much data the verbose level generates.

You should not set the logging to verbose unless you are tying to collect information to diagnose an issue. For production workloads you would generally want to set this to errors only.