跟踪
WCF的核心诊断能力创建在由.NET Framework 提供的现有的跟踪实例上。System.Diagnostics命名空间包含允许应用程序简便地发出跟踪信息并可以在很多格式和位置存储那些细节信息的类。
System.Diagnostics特性跟踪能力在跟踪源和跟踪监听器的概念周围组织。跟踪源使用System.Diagnostics.TraceSource类设置并允许应用程序显示执行细节，比如数据或者事件。跟踪信息由一个可以被一个或者多个跟踪监听器接收并处理的跟踪源发出，类继承自抽象基类System.Diagnostics.TraceListener.
WCF使用这些特性来释放在处理服务调用和反馈的过程中的信息。不需要自定义代码来创建这些细节，开发人员或者IT管理员仅需要添加配置文件来时能跟踪源和跟踪监听器，这些会在稍后讲到。然而，开发人员可以按照需要随意添加他们自己的跟踪调用方法来显示细节信息。
端到端跟踪
监控WCF应用程序的一个中央特性被称作端到端(E2E)跟踪。它的思想是使用.NET Framework 的System.Diagnostics特性来在一个分布式应用程序的多个入口之间传递身份标识符以便于它们的动作可以关联到一个逻辑流中去。使用E2E跟踪，很有可能跟踪一系列跨越服务和机器边界的动作-例如，从在客户端的原始请求道目标服务调用的逻辑。
E2E跟踪使用一个特殊的XML数据元来在逻辑边界之间保持处理细节。XML通过注册一个System.Diagnostics.XMLWriterTraceListener的实例创建的，并将跟踪信息处理成E2E XML格式(在http://schemas.microsoft.com/2004/06/E2ETraceEvent).
列表9.1显示了一段节略的E2E跟踪XML片段
列表9.1 端到端跟踪示例
尤其要注意Correlation节点和ActivityID属性。这些是把很多源中的独立跟踪片段连接到一个统一的逻辑流的主键。关联的背后概念会在接下来讨论。
活动和关联
一个WCF活动是用来为身份证明和监控的易用性进行跟踪分组的一系列逻辑功能的子集。一个例子是对一个服务终结点的调用的处理。尽管活动是独立起作用的，高效的监控要求在多个活动间监控流的结构。
关联是将多个活动关联起来在一个分布式应用程序中创建一个顺序逻辑流的概念。关联通过传输执行，在一个终结点内连接活动，并在多个终结点间传播。连接活动。
活动是通过一个称作活动ID的身份标识符关联起来的。身份标识符是一个GUID，是由System.Diagnostics.CorrelationManager类生成的，它与一个跟踪源关联并可以通过System.Diagnostics.CorrelationManager的静态属性收集。它也有两个原始方法，StartLogicalOperation() 和 StopLogicalOperation(), 用来将关联动作为跟踪目的连接到一个逻辑单元中去。
启动跟踪
跟踪功能默认是禁止的而且可以通过配置一个跟踪源来显示信息，跟踪器通过监听来处理并保存最终的跟踪结果。
列表9.2 显示了SelfHost App.config 配置跟踪的相关部分
列表9.2 在配置文件中开启跟踪
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Warning, ActivityTracing"
propagateActivity="true">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="tracelog" traceOutputOptions="Timestamp">
<filter type="" />
</add>
</sharedListeners>
</system.diagnostics>
<system.serviceModel>
在列表9.2中，<source>节点引用System.ServiceModel跟踪源，这是WCF用来显示跟踪细节的跟踪源。在<listeners>节点，我们可以添加一个或多个跟踪监听器来处理那些细节。类型属性指示监听器类去如何调用，initializeData包含了那个监听器的参数，比如一个文件位置。一个XmlWriteTraceListener配置为向app_tracelog.svlog文件中写入详细信息。
|
注意 服务配置编辑器 为了避免有抽象概念隐藏WCF诊断的细节，我们通过在相关的App.config 文件中手动配置来开启跟踪和消息日志功能。在这一章的后续部分，我们将显示如何使用服务配置编辑器来快速和精确地来进行很多改变而不用直接编辑配置文件。 |
跟踪源有一个用来确定应该被捕捉到的内容的详细层次。表9.1显示了当配置跟踪源时switchValue属性的可能的值。
表9.1 跟踪源的switchValue选项
| 选项 | 目的 |
| Off | 关闭跟踪源。 |
| Critical | 对最严重的应用程序和环境失败进行记录，比如一个服务失败或者一个服务无法启动。 |
| Error | 记录应用逻辑错误或者环境问题-例如，一个不可恢复的异常。 |
| Warning | 可能在将来导致一个异常或者失败的场景，或是用来提示应用程序从一个异常中恢复。 |
| Information | 可能对调试有用处的系统事件的细节，简单的有审计和完全监控。 |
| Verbose | 每一步的全部信息。对于记录问题产生根源有用。 |
| ActivityTracing | 用来在分布式应用程序的逻辑连接组件部分与跟踪刘关联。 |
注意ActivityTracing可以与一个冗余选择器(如switchValue=”Warning, ActivityTracing”)连接使用。
冗余建议
使用更多的冗长选项来跟踪可以快速地导致产生大量的跟踪信息，这会增加系统开销并增加将有用数据从无用数据中区分开来的困难。当诊断一个问题时，我们建议你在警告级别开始跟踪。
当在正常生产条件下操作时，考虑将跟踪关闭或者在严重或是错误级别直到需要更多诊断或者监控信息的条件满足。