将 Azure 诊断日志写入 Blob 存储的性能影响

Question

我们在 Azure 上运行的 C# Web 应用使用 System.Diagnostics.Trace 编写用于调试/故障排除的跟踪语句。一旦我们为这些日志启用 blob 存储（使用 Azure 门户中的“应用程序日志记录 (blob)”选项），我们的应用程序的响应时间就会大大减慢。如果我关闭此选项，网络应用程序会再次加速（尽管显然我们不再在 blob 存储中获取日志）。

有人知道这是否是预期的吗？我们当然会为每个请求（每个请求大约 100 个）编写大量跟踪语句，但我认为这对于 Web 应用程序来说并不罕见。有什么方法可以诊断为什么为日志启用 blob 存储会显着减慢这些跟踪语句的执行速度？例如，在 blob 存储中写入跟踪语句是否与正在更新的日志同步？

Answer 1

我找不到有关如何在 Azure 中实现日志记录到 Blob 存储的任何信息。但是，这是我能够推断出的：

我确认禁用global lock 无效。因此，性能问题与锁竞争没有直接关系。

我还确认，如果我关闭AutoFlush，则不会出现性能问题。

从进一步的交叉引用the source code for the .NET trace API 来看，我的结论是，当您为日志启用 blob 存储时，它会在您的应用程序中注入某种跟踪侦听器（与您在 web.config 中添加侦听器的方式相同）它会将接收到的每个跟踪语句同步写入 blob 存储。

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

1. 不要打开 AutoFlush，而是定期手动刷新。这将防止同步 blob 写入中断每个日志语句。
2. 编写您自己的守护程序，它会定期将本地日志文件复制到 blob 存储或类似的东西
3. 根本不要使用这个 blob 存储功能，而是利用 the tracing functionality in Application Insights。

我最终选择了 #3，因为事实证明，我们已经配置并开启了 Application Insights，我们只是没有意识到它可以处理跟踪日志记录和查询。在disabling sampling 跟踪事件之后，我们现在可以轻松地远程查询任何日志语句并获取符合任何条件的完整跟踪集（关键字匹配、特定请求的所有跟踪、特定时间段内的所有跟踪等）此外，使用 Application Insights 跟踪侦听器编写日志语句没有明显的同步开销，因此我们的应用程序中无需更改任何内容（我们可以继续使用 .NET 跟踪类）。作为奖励，由于 Application Insights 跟踪对于跟踪源非常灵活，如果需要，我们甚至可以切换到另一个性能更高的日志记录 API（例如 ETW 或 log4net），并且 Application Insights 仍然有效。

最终，您应该考虑使用 Application Insights 来存储和查询您的跟踪。根据您最初希望将日志存储在 Blob 存储中的原因，它可能会也可能不会满足您的需求，但它对我们有用。