5

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

由于我之前从未使用过这个trace的东西,所以我开始研究它。经过一段时间的 Google、SO 和 MSDN,我终于对事情的运作方式有了一个很好的了解。但我也发现了一件非常令人不安的事情。

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

我也是这样,直到我开始检查CorrelationManager实际居住的地方。毕竟 - 这是一个静态属性。在玩了一些 Reflector 之后,我发现了一些可怕的东西 - 它存储在CallContext我们不应该在 ASP.NET 中使用哪种东西,对吗?

所以......我在这里错过了什么吗?ASP.NET 中的跟踪真的存在根本缺陷吗?

补充: Emm,我有点自己重写这些东西的边缘。我仍然想使用整洁的工具来探索痕迹。有什么理由我不应该这样做?也许还有更好的东西?如果我能尽快得到一些答案,那就太好了。:)

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

补充 3:哇,太棒了……微软的人找不到在 ASP.NET 中使用 Correlation Manager 有什么问题。所以显然我们毕竟没有修复这个错误......

4

2 回答 2

3

你提出了一个非常有趣的问题。查看 Reflector 后,我还看到 CorrelationManager 正在使用 CallContext 来存储活动 ID。我没有进行过多的跟踪工作,所以我不能真正代表它跟踪的活动类型,但是如果它在页面请求的整个生命周期中跟踪单个活动,根据您上面引用的文章,那里活动 id 可能与实际活动不相关。这项活动似乎会在中途消失。

HttpContext 似乎非常适合从头到尾跟踪整个页面请求,因为即使执行更改为不同的线程,它也会继续执行。但是,HttpContext 不会像 CallContext 那样传输到您的业务对象。顺便说一句,我看到 CallContext 也可以在客户端和服务器应用程序之间使用远程处理时进行传输,这非常漂亮,但在跟踪网站的情况下,这并不是那么有用。

如果您还没有,请查看此人的网站。本文中描述的问题与Cup(Of T) 文章提到的问题并不完全相同,但它仍然很有趣。他还在页面上提供了几个非常有用的链接,这些链接描述了 CorrelateionManager 的组件。

不幸的是,我对你的问题没有真正的答案,但我肯定觉得这个话题很有趣,并将继续研究它。因此,当您了解更多信息时,请更新此帖子。我很想看看你或其他人(希望有人能对这个话题有所了解)在调查这个问题时发现了什么。

无论如何,祝你好运。我会和我工作中的一些偷窥者谈谈这个问题,如果我发现任何东西,我会在以后发布更多。

克里斯

于 2009-02-12T08:17:14.867 回答
1

OK,就这样结束了。

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

同时,我创建了自己的小跟踪类。它不支持默认跟踪框架所做的所有花里胡哨,但这正是我所需要的。:) 进一步来说:

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

快乐的结局,我希望。:)

于 2009-02-13T14:31:18.597 回答