ASP.NET和System.Diagnostics跟踪 - 我错过了什么,或者这是一个坏主意？

Question

出于各种常见原因,我想对我的ASP.NET应用程序使用跟踪.特别是因为我发现了使用Service Trace Viewer工具的可能性,它允许您以强大的方式检查跟踪.

因为我之前从未使用过这种痕迹,所以我开始研究它.经过一段时间的谷歌,SO和MSDN,我终于明白了事情是如何运作的.但我也发现了一个非常不受欢迎的事情.

在ASP.NET应用程序中使用跟踪时,通过Web请求将跟踪消息组合在一起非常有意义.特别是因为我想使用它的原因之一是研究性能问题.上面提到的工具也通过<Corrleation>在生成的XML文件中使用标记来支持这一点.而这反过来又来自System.Diagnostics.Trace.CorrelationManager.它还允许其他很好的功能,如Activity启动/停止,它提供了更好的跟踪消息分组.很酷,对吗？

我也是如此,直到我开始检查CorrelationManager实际居住的地方.毕竟 - 它是一个静态属性.在玩了一些反射器后,我发现了一些可怕的东西 - 它存储在CallContext!我们不应该在ASP.NET中使用哪种东西,对吧？

所以......我在这里错过了一些东西吗？在ASP.NET中跟踪真的存在根本缺陷吗？

补充:嗯,我有点在自己重写这些东西的边缘.我仍然想使用整洁的工具来探索痕迹.我不应该这样做的原因？也许有更好的东西呢？如果我很快得到答案,那将是非常好的.:)

补充2:我的一位同事证实,这不仅仅是一个理论问题.他在他正在研究的系统中观察到了这一点.所以它已经解决了.我打算建立一个新的小系统,按照我想要的方式做事.:)

补充3:哇,很酷......微软的人们在ASP.NET中使用Correlation Manager时没有发现任何问题.显然我们毕竟没有得到这个bug的修复......

Answer 1

好吧，事情就这样结束了。

我的同事打电话给微软并向他们报告了这个错误。成为认证合作伙伴意味着我们可以访问一些优先级更高的修复队列或其他东西......不知道这些东西。无论如何，他们正在努力。希望我们很快就能看到补丁。:)

与此同时，我创建了自己的小跟踪类。它不支持默认跟踪框架所做的所有功能，但这正是我所需要的。：） 进一步来说：

• 它写入与默认格式相同的 XML 格式XmlWriterTraceListener，因此我可以使用该工具来分析日志。
• 它有一个内置的日志轮换——这是我的同事必须自己在XmlWriterTraceListener.
• 实际的日志记录被推迟到另一个线程，因此可以更准确地测量性能。
• 相关性现在存储在HttpContext.ItemsASP.NET 线程特性中，因此不会影响它。

幸福的结局，我希望。:)