将Azure诊断日志写入Blob存储对性能的影响 [英] Performance impact of writing Azure diagnostic logs to blob storage

问题描述

我们在Azure上运行的C#Web应用程序使用System.Diagnostics.Trace编写跟踪语句以进行调试/故障排除.一旦我们为这些日志启用Blob存储(使用Azure门户中的应用程序日志记录(blob)"选项)，我们的应用程序的响应时间就会大大降低.如果我关闭此选项，Web应用程序将再次加速(尽管显然我们不再将日志存储在Blob存储中).

Our C# web app, running on Azure, uses System.Diagnostics.Trace to write trace statements for debugging/troubleshooting. Once we enable blob storage for these logs (using the "Application Logging (blob)" option in the Azure portal), the response time for our application slows down considerably. If I turn this option off, the web app speeds up again (though obviously we don't get logs in blob storage anymore).

有人知道这是否可以预期吗?我们当然会在每个请求上写很多跟踪语句(每个请求100个左右)，但是我认为这对于Web应用程序来说并不罕见.有什么方法可以诊断为什么为日志启用Blob存储会大大减慢这些跟踪语句的执行速度?例如，编写trace语句是否与正在Blob存储中更新的日志同步?

Does anyone know if this is expected? We certainly write a lot of trace statements on every request (100 or so per request), but I would not think this was unusual for web application. Is there some way to diagnose why enabling blob storage for the logs dramatically slows down the execution of these trace statements? Is writing the trace statement synchronous with the logs being updated in blob storage, for instance?

推荐答案

我找不到有关如何实现在Azure中记录到Blob存储的任何信息.但是，这就是我能够得出的结论:

I was unable to find any information about how logging to blob storage in Azure was implemented. However, this is what I was able to deduce:

我确认禁用

I confirmed that disabling the global lock had no effect. Therefore, the performance problem was not directly related to lock contention.

我还确认，如果我打开自动刷新关闭，则不会发生性能问题.

I also confirmed that if I turn AutoFlush off, the performance problem did not occur.

通过进一步的交叉引用

From further cross referencing the source code for the .NET trace API, my conclusion is that it appears that when you enable blob storage for logs, it injects some kind of trace listener into your application (the same way you might add a listener in web.config) and it synchronously writes every trace statement it receives to blob storage.

因此，似乎有几种方法可以解决此问题:

As such, it seems that there are a few ways to workaround this behavior:

1. 不要打开自动刷新"，而是定期手动刷新.这将防止同步Blob写操作中断每个日志语句.
2. 编写您自己的守护程序，该守护程序将定期将本地日志文件复制到Blob存储或类似的内容
3. 完全不使用此Blob存储功能，而是利用

1. Don't turn on AutoFlush, but manually flush periodically. This will prevent the synchronous blob writes from interrupting every log statement.
2. Write your own daemon that will periodically copy local log files to blob storage or something like this
3. Don't use this blob storage feature at all but instead leverage the tracing functionality in Application Insights.

我最终做了#3，因为事实证明，我们已经配置了Application Insights，然后打开，我们只是没有意识到它可以处理跟踪日志记录和查询.在禁用跟踪事件的采样之后，我们现在，有一种方法可以轻松地远程查询任何日志语句，并根据任何条件(关键字匹配，特定请求的所有跟踪，特定时间段内的所有跟踪等)获得完整的跟踪.使用Application Insights跟踪侦听器编写日志语句时会产生明显的同步开销，因此应用程序中的任何内容都无需更改(我们可以继续使用.NET跟踪类).另外，由于Application Insights跟踪在跟踪源中非常灵活，因此我们甚至可以根据需要切换到另一个性能更高的日志记录API(例如ETW或log4net)，并且Application Insights仍然可以工作.

I ended up doing #3 because, as it turns out, we already had Application Insights configured and on, we just didn't realize it could handle trace logging and querying. After disabling sampling for tracing events, we now have a way to easily query for any log statement remotely and get the full set of traces subject to any criteria (keyword match, all traces for a particular request, all traces in a particular time period, etc.) Moreover, there is no noticeable synchronous overhead to writing log statements with the Application Insights trace listener, so nothing in our application has to change (we can continue using the .NET trace class). As a bonus, since Application Insights tracing is pretty flexible with the tracing source, we can even switch to another higher performance logging API (e.g. ETW or log4net) if needed and Application Insights still works.

最终，您应该考虑使用Application Insights来存储和查询跟踪.首先取决于您为什么想要在Blob存储中存储日志，它可能满足也可能不满足您的需求，但这对我们有用.

Ultimately, you should consider using Application Insights for storing and querying your traces. Depending on why you wanted your logs in blob storage in the first place, it may or may not meet your needs, but it worked for us.

这篇关于将Azure诊断日志写入Blob存储对性能的影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！