控制 Windows Azure 中的日志记录和跟踪.docx

云诊断 控制 Windows Azure 中的日志记录与跟踪 HYPERLINK /magazine/ee532098.aspx?sdmr=MikeKellysdmi=authors Mike Kelly HYPERLINK /mag201006Azure 下载代码示例 与许多程序员一样，我在刚刚开始编写代码时，使用 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) 将使用“暂停”、“继续”和“转移”这几个类型。