简体繁体 English

Azure应用服务跟踪

[英]Azure App Service Tracing

原文 2017-09-12 16:18:47 2 2 c#/ azure/ azure-web-sites/ azure-app-service-plans/ .net-trace

We have an app deployed in Azure App Service, and it has the below logging configuration: 我们在Azure App Service中部署了一个应用程序，它具有以下日志记录配置：

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? 如果我们不在System.Diagnostics命名空间（System.Diagnostics.Trace / System.Diagnostics.TraceSource）中使用任何方法，那么此设置的意义是什么？ 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 System.Diagnostics.Trace.TraceInformation或System.Diagnostics.Trace.WriteLine

to write a trace. 写迹线。

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. 即使您没有在应用程序中使用System.Diagnostics.Trace命名空间，也可能有一些NuGet程序包或其他依赖项。

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. 您应该检查Blob存储中的输出文件，以了解详细级别会生成多少数据。

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. 对于生产工作负载，通常需要将其仅设置为错误。

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跟踪是用于对应用程序进行故障排除的强大功能，但是绝对不应在生产环境中使用它。 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. ASP.NET跟踪使用诸如DataTables之类的数据结构来存储跟踪信息，随着时间的流逝，这些结构可能导致内存过多，从而导致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. 正如Byron Tardif在答复中提到的那样，如果可能的话，您可以在生产环境中将Level设置为error。