控制WindowsAzure中日志记录与跟踪.docxVIP

云诊断控制 Windows Azure 中的日志记录与跟踪Mike Kelly下载代码示例与许多程序员一样，我在刚刚开始编写代码时，使用 print 语句进行调试。我不知道如何使用调试器，而 print 语句虽然简陋，却可以作为一种有效的方式用来查看程序在运行时的情况。后来，我学会了使用真正的调试器，而不再使用 print 语句作为调试工具。很快，我开始编写在服务器上运行的代码。我发现这些 print 语句现在被用于更为复杂的“日志记录与跟踪”，而日志记录与跟踪是任何编写服务器应用程序的程序员的基本技术。即使您能够将调试器与生产服务器应用程序相连（这通常无法实现，因为用来托管应用程序的计算机上存在一定的安全限制），也很难通过传统的调试器来揭示服务器应用程序所遇到的问题类型。许多服务器应用程序都是分布式的，运行在多台计算机上，因此对一台计算机上发生的情况进行调试，并不总是能诊断出真正的问题。此外，服务器应用程序经常是在某位操作人员的控制下运行，操作人员不了解如何使用传统的调试器，而每次遇到问题都找来开发人员并不可取或者不切实际。在本文中，我将介绍一些用于服务器应用程序的基本的日志记录、跟踪和调试技术。然后，将深入介绍如何在 Windows Azure 项目中利用这些技术。在此期间，您会看到如何对一些实际的应用程序执行日志记录和跟踪，并且我会介绍如何使用 Windows PowerShell来管理针对运行中的服务的诊断。日志记录策略理想情况下，任何服务器应用程序（几乎所有 Web 应用程序，包括运行在 Windows Azure 下的应用程序）都应该在一开始就设计好日志记录和跟踪策略。日志记录信息应该足够可靠，能够描述每个组件中发生的几乎每一件事。但是，就像我最早在程序中添加的那些 print 语句会产生大量输出一样，日志记录也会产生大量输出。因此，设计优良的日志记录和跟踪需要包含一些方法，用来调整任意组件的日志记录的类型和容量。这就使操作人员和开发人员能够关注某个表现不正常的组件，甚至可能是某台计算机，以便获得更详细的信息来准确了解其中发生的情况，而不会在日志中生成大量无用信息，这些信息会分散注意力，甚至可能大大降低应用程序的性能。此外，由于服务器应用程序通常都是分布式应用程序，因此必须从多台计算机（可能处于不同的应用程序角色）收集信息并进行汇总，以便全面了解发生特定问题时的情况。因此，非常重要的一点是，利用某种方法来识别通过计算机的事务线程，这样就可以汇总相关的事实信息。Windows Azure 中提供的日志记录在社区技术预览 (CTP) 发行期间已经成熟。早期的日志记录并不比 print 语句复杂很多，可作为 Windows Azure 表存储空间中的文本来捕获。从 PDC09 版开始，Windows Azure 开始提供一套功能更加全面的日志记录与跟踪基础结构，这套基础结构基于 Windows 事件跟踪 (ETW) 框架。此 ETW 框架在 ASP.NET 中是通过System.Diagnostics命名空间中的类来支持的。Microsoft.WindowsAzure.Diagnostics命名空间继承并扩展了标准的System.Diagnostics类，从而能够使用System.Diagnostics作为 Windows Azure 环境中的日志记录框架。图 1显示了 Windows Azure 诊断如何实现 ETW。图 1 Windows Azure 诊断的高度概览ETW 提供了一个模型，在此模型中可以将代码记录到一个或多个TraceSource。每个源中允许的日志记录级别是由SourceSwitch控制的。这些源将依次连接到一个或多个使用者，使用者会通过各种方法来永久保存日志记录信息。Windows Azure 提供了一种标准的使用者或侦听器，用来将您生成的日志记录信息永久保存到 Windows Azure 表存储空间或 Blob 存储空间。如果您希望利用事件数据来完成其他的任务，则可以自行编写使用者，或者也可以使用现成的使用者（但有些使用者必须经过修改才能在 Windows Azure 环境中使用）。ETW 框架为每个事件都关联了一个TraceEventType，如图 2所示。前五个严重程度行是最常用的值，它们指出了跟踪输出的相对重要程度。请注意，Windows Communication Foundation (WCF) 将使用“暂停”、“继续”和“转移”这几个类型。图 2 跟踪事件类型跟踪事件类型值含义关键0x0001严重错误或应用程序崩溃错误0x0002可修复的错误警告0x0004不严重的问题，但可能意味着会发生更严重的问题信息0x0008提示性信息详细0x0010调试跟踪（例如详细的执行流程信息、参数等等