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

1、控制 Windows Azure 中的日志记录与跟踪云诊断控制 Windows Azure 中的日志记录与跟踪Mike Kelly 下载代码示例 与许多程序员一样，我在刚刚开始编写代码时，使用 print 语句进行调试。我不知道如何使用调试器，而 print 语句虽然简陋，却可以作为一种有效的方式用来查看程序在运行时的情况。后来，我学会了使用真正的调试器，而不再使用 print 语句作为调试工具。很快，我开始编写在服务器上运行的代码。我发现这些 print 语句现在被用于更为复杂的“日志记录与跟踪”，而日志记录与跟踪是任何编写服务器应用程序的程序员的基本技术。即使您能够将调试器与生产服务器应用

2、程序相连（这通常无法实现，因为用来托管应用程序的计算机上存在一定的安全限制），也很难通过传统的调试器来揭示服务器应用程序所遇到的问题类型。许多服务器应用程序都是分布式的，运行在多台计算机上，因此对一台计算机上发生的情况进行调试，并不总是能诊断出真正的问题。此外，服务器应用程序经常是在某位操作人员的控制下运行，操作人员不了解如何使用传统的调试器，而每次遇到问题都找来开发人员并不可取或者不切实际。在本文中，我将介绍一些用于服务器应用程序的基本的日志记录、跟踪和调试技术。然后，将深入介绍如何在 Windows Azure 项目中利用这些技术。在此期间，您会看到如何对一些实际的应用程序执行日志记录和跟

3、踪，并且我会介绍如何使用 Windows PowerShell 来管理针对运行中的服务的诊断。日志记录策略理想情况下，任何服务器应用程序（几乎所有 Web 应用程序，包括运行在 Windows Azure 下的应用程序）都应该在一开始就设计好日志记录和跟踪策略。日志记录信息应该足够可靠，能够描述每个组件中发生的几乎每一件事。但是，就像我最早在程序中添加的那些 print 语句会产生大量输出一样，日志记录也会产生大量输出。因此，设计优良的日志记录和跟踪需要包含一些方法，用来调整任意组件的日志记录的类型和容量。这就使操作人员和开发人员能够关注某个表现不正常的组件，甚至可能是某台计算机，以便获得更详

4、细的信息来准确了解其中发生的情况，而不会在日志中生成大量无用信息，这些信息会分散注意力，甚至可能大大降低应用程序的性能。此外，由于服务器应用程序通常都是分布式应用程序，因此必须从多台计算机（可能处于不同的应用程序角色）收集信息并进行汇总，以便全面了解发生特定问题时的情况。因此，非常重要的一点是，利用某种方法来识别通过计算机的事务线程，这样就可以汇总相关的事实信息。Windows Azure 中提供的日志记录在社区技术预览 (CTP) 发行期间已经成熟。早期的日志记录并不比 print 语句复杂很多，可作为 Windows Azure 表存储空间中的文本来捕获。从 PDC09 版开始，Windo

5、ws Azure 开始提供一套功能更加全面的日志记录与跟踪基础结构，这套基础结构基于 Windows 事件跟踪 (ETW) 框架。此 ETW 框架在 ASP.NET 中是通过 System.Diagnostics 命名空间中的类来支持的。Microsoft.WindowsAzure.Diagnostics 命名空间继承并扩展了标准的 System.Diagnostics 类，从而能够使用 System.Diagnostics 作为 Windows Azure 环境中的日志记录框架。图 1 显示了 Windows Azure 诊断如何实现 ETW。图 1 Windows Azure 诊断的高度概

6、览ETW 提供了一个模型，在此模型中可以将代码记录到一个或多个 TraceSource。每个源中允许的日志记录级别是由 SourceSwitch 控制的。这些源将依次连接到一个或多个使用者，使用者会通过各种方法来永久保存日志记录信息。Windows Azure 提供了一种标准的使用者或侦听器，用来将您生成的日志记录信息永久保存到 Windows Azure 表存储空间或 Blob 存储空间。如果您希望利用事件数据来完成其他的任务，则可以自行编写使用者，或者也可以使用现成的使用者（但有些使用者必须经过修改才能在 Windows Azure 环境中使用）。ETW 框架为每个事件都关联了一个 Tra

7、ceEventType，如图 2 所示。前五个严重程度行是最常用的值，它们指出了跟踪输出的相对重要程度。请注意，Windows Communication Foundation (WCF) 将使用“暂停”、“继续”和“转移”这几个类型。图 2 跟踪事件类型跟踪事件类型 值 含义 关键0x0001严重错误或应用程序崩溃错误0x0002可修复的错误警告0x0004不严重的问题，但可能意味着会发生更严重的问题信息0x0008提示性信息详细0x0010调试跟踪（例如详细的执行流程信息、参数等等）开始0x0100开始某项逻辑操作停止0x0200停止某项逻辑操作暂停0x0400暂停某项逻辑操作继续0x08

8、00继续某项逻辑操作转移0x1000转移到新活动如果只想查找真正的问题，您可能需要确保捕获“严重”值，或许还包括“错误”值。如果想详细了解发生的情况，则需要查看“详细”以上级别的所有内容。您的日志记录策略应该对层次结构中各值使用一致的事件类型和详细日志记录项。如果在您的应用程序中启用了对所有重点值的日志记录，应该有可能真正追踪应用程序的执行流程。这对于在生产环境中解决错误或问题具有重大价值。您可以将侦听器、源和开关连接起来，从而通过编程来实现不同级别的输出，但这通常是通过配置文件来完成的。您可以在 app.config（对于 Windows Azure 工作者角色）或 web.config（对

9、于 Windows Azure Web 角色）中配置输出。但如果将此配置放入 ServiceConfiguration.cscfg 中，您就可以在 Windows Azure 服务运行期间调整日志记录与跟踪选项，而不用为正在运行的代码重新部署任何更新甚至停止服务。我会在下文中对此做出详细解释。Windows Azure 还提供了 RESTful 接口，用于远程控制某些日志记录选项。Windows PowerShell 可以使用该 RESTful 接口。日志记录、跟踪和调试输出日志记录、跟踪和调试输出这几个术语有时可以互换使用。在本文中，我会将您的代码中通常称为诊断输出 的内容分为四种不同的类型

10、。这四种类型大致是按从最详细到最简略的顺序排列。 调试输出：此类信息仅出现在应用程序的调试版中；而对于发行版，在编译时需要排除此类信息（根据编译时是否定义了 DEBUG 预处理器符号进行排除，默认情况下 Visual Studio 只会在调试版中定义此符号）。通常，调试输出包括类似于您添加的“声明”之类的信息，这些信息有助于发现代码不符合预期前提条件、会导致错误甚至数据结构转储的情况。添加这些声明可帮助您在调试和测试过程中调试算法。 跟踪：此类信息是指一些语句，用于在程序运行时帮助跟踪控制流和程序状态。想象一下：运行一个调试器，一步步执行代码，然后在监视窗口中查看关键变量的值。跟踪语句的作用就

11、是在您无法连接调试器时再现这种体验。从理论上说，跟踪语句应该能够提供足够的上下文信息，通过阅读跟踪语句，您可以了解应用程序在每个控制点都选择哪条执行路径，以及代码中接下来的操作类型。如果在编译时定义了 TRACE 预处理器符号，就会启用跟踪，在发行版和调试版中都可以进行跟踪。（默认情况下，Visual Studio 在调试版和发行版中均定义了 TRACE，当然，您可以进行更改。） 事件日志记录：此类信息是指一些语句，用于在应用程序运行过程中捕获主要事件，例如：开始事务，或者向数据库中添加项目。事件日志记录与跟踪的差别在于它捕获的是重要状态，而不是详细的控制流。 错误日志记录：此类信息是指一些特

12、殊的事件日志记录，用于捕获异常或可能存在危险的情况。具体的例子包括：捕获的任何异常；您应该能够访问另一台计算机上的资源却不能访问的情况（当然，您的应用程序应该能够妥善处理，但也需要注意）；以及您认为不会出错却从 API 返回错误的情况。在尚未出现错误但有征兆表明很快会出现错误的情况下（例如，配额接近上限，或者某项事务成功执行但花费的时间超出正常情况），错误日志记录对操作人员也很有用。这些类型的日志记录事件可帮助操作人员在问题发生之前主动采取措施，使应用程序避免发生停机。大多数优秀的开发人员都习惯于在应用程序中包含调试输出，以帮助他们在开发过程中诊断问题，而且许多人已经开发出了用于错误日志记录的

13、某种解决方案。但是，您需要确保不仅考虑到调试输出和错误日志记录选项，还拥有一种可靠的跟踪和事件日志记录策略，从而真正有助于诊断只有在生产环境中的高压负载下才会发生的问题。此外，还需要慎重考虑，您现在当作调试输出的许多内容是否确实需要跟踪以及在发行版和调试版中均提供。生产环境中表现不正常的应用程序通常运行的是发行版。如果跟踪语句已存在，但是被禁用了（我会在下文中介绍如何操作），您可以有选择地启用它们，以便从发行版获得类似于调试版的详细输出，从而帮助您诊断问题。Windows Azure 中的跟踪与日志记录您可以直接使用 Windows Azure 的日志记录功能，该功能是 Windows Azu

14、re SDK 的一部分。使用 Logger.NET、Enterprise Library、log4net 或 Ukadc.Diagnostics 之类的日志记录框架有一些好处。这些框架为您的日志记录消息附加了结构，也有助于提供上文所述的某些可配置性。但是，大部分框架未经调整，不能在 Windows Azure 环境中使用；有些也远不止是日志记录框架。对于本文的示例代码，我决定只使用标准的 Windows Azure 日志记录与跟踪 API，并在其上加上一个薄层来提供动态配置功能。您可能会发现，如果在此基础上为您的日志记录与跟踪策略构建一些帮助程序类和一个框架，会对您有所帮助，或者也可以留意其他

15、框架是否具有适用于 Windows Azure 的版本。使用 Visual Studio 在 Windows Azure 中创建新服务后，就已经在该服务中启用基本的日志记录功能。通过 Windows Azure 模板生成的样板工作者角色和 Web 角色的代码已经配置并启用了诊断侦听器。若要在 Windows Azure 服务中启用简单的日志记录，请在 Visual Studio 中使用“Windows Azure 云服务 (Visual C#)”模板来启动新项目。然后为项目指定名称。在我的示例中，我使用了 MSDNSampleLoggingService。单击“确定”。“新建云服务项目”向导将

16、运行。在该向导中，为项目添加一个工作者角色和一个 Web 角色。将工作者角色重命名为 LoggingWorkerRole，将 Web 角色重命名为 LoggingWebRole，然后单击“确定”。Visual Studio 将会创建该项目。此时，您可以浏览生成的代码。查看 LoggingWorkerRole 项目中的 app.config，您会注意到出现了以下代码：复制代码 此代码会将标准 Windows Azure 诊断侦听器连接到您的代码，这就意味着，除非您进行更改，否则您从工作者角色执行的任何日志记录和跟踪都会被定向到 Windows Azure 侦听器 (DiagnosticMonit

17、orTraceListener)。对于为此服务创建的 Web 角色，您会在 web.config 中找到类似的条目。如果您查看工作者角色项目中的 WorkerRole.cs 文件，还会在 OnStart 方法中看到以下行：复制代码 DiagnosticMonitor.Start(DiagnosticsConnectionString);并且在 Run 方法中，您会看到对跟踪的调用：复制代码 / This is a sample worker implementation. Replace with your logic.Trace.WriteLine(LoggingWorkerRole ent

18、ry point called, Information);最后，如果您查看位于“服务”根目录下的 ServiceConfiguration.cscfg 文件，您会看到对应于工作者角色和 Web 角色的以下行：复制代码 该行用于告知 Windows Azure 侦听器，使用哪个存储帐户来永久保存日志记录与跟踪信息。在本例中，日志记录信息将存储在本地计算机上的开发存储空间中。如果将此设置切换为 Windows Azure 云存储帐户，则可以将日志定位到云存储空间。下面是本文所提供的示例代码中的格式示例：复制代码 AccountName 和 AccountKey 值需要根据您的实际 Azure 帐

19、户和密钥来自定义。您可以从您服务的存储帐户门户（网址为 ）获取此信息。AccountName 是 URL 中对应于表和 Blob 存储端点的第一部分（“”之前的部分）。AccountKey 是您的存储帐户的 base-64 编码的主访问密钥。请注意，由于有一个单独的存储帐户用于诊断，因此您可以选择将诊断信息与其他的应用程序数据分开存放。为此，请在门户页面上单击“新建服务”，选择“存储帐户”，然后指定名称（例如 MyAppLogs），从而设置单独的存储帐户。您可能需要设置一个相关性组，使您的日志与服务存储在相同的区域中。至此，您已经快速了解了 Windows Azure 服务中的跟踪代码，可以运

20、行您创建的简单 Web 角色项目了。请注意，在调试版中，Windows Azure 所提供的默认侦听器还会将输出定位到 Visual Studio 中的输出窗口，因此您会在调试窗口中看到 OnStart 消息：复制代码 Information: LoggingWorkerRole entry point called如果您想在服务运行后查看日志，该怎么办？默认情况下，Windows Azure 不会将日志永久保存到存储空间。您可以在自己角色的 OnStart 方法中添加几行代码，命令 Windows Azure 这么做：复制代码 TimeSpan tsOneMinute = TimeSpan.

21、FromMinutes(1);DiagnosticMonitorConfiguration dmc =DiagnosticMonitor.GetDefaultInitialConfiguration();/ Transfer logs to storage every minutedmc.Logs.ScheduledTransferPeriod = tsOneMinute;/ Transfer verbose, critical, etc. logsdmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose; / Start up t

22、he diagnostic manager with the given configurationDiagnosticMonitor.Start(DiagnosticsConnectionString, dmc);如果将此代码添加到 WorkerRole.cs 中并重新运行，会使 Windows Azure 每分钟向开发存储空间转移一次日志。您也可以选择根据需要转移日志（请参见我的示例应用程序中 admin.aspx.cs 文件的代码来了解如何操作），或者使用下文介绍的 Windows PowerShell 命令。请记住，一旦将日志转移到存储空间，您就需要为所使用的存储空间付费，而且当您不再

23、需要这些信息时，需要自行将其删除。当您将日志传送到 Windows Azure 存储空间后，还需要一个工具来查看存储表，从中可以看到日志。我使用了 Cerebrata 的 Cloud Storage Studio ()。Cerebrata 曾经发布过一款名为 Azure Diagnostics Manager 的工具，CodePlex () 上也提供了用于查看云存储空间和诊断信息的免费工具。日志存放在名为 WADLogsTable 的表中，您可以在图 3 中看到该表。图 3 永久保存在开发存储空间中的日志当您查看存储空间中的日志时，会注意到两件事。首先，Windows Azure 会自动将一些

24、信息与每个记录的事件相关联，例如时间戳、滴答计数（以 100 纳秒为单位提供更详细的时间信息），以及有关部署、角色和角色实例的信息。这使您能够根据需要将日志限定在特定的实例范围内。其次，每个事件都关联了 Level 和 EventId。Level 对应于图 2 中的值：记录为“信息”的跟踪事件的 Level 值为 4，记录为“错误”的跟踪事件的 Level 值为 2。通过 Trace.WriteLine 发送（如样板代码所执行的操作）的一般事件的 Level 值为 5（详细）。EventId 的值由您指定。上文所示的基本 Trace.WriteLine 调用并没有让您指定该值；您必须使用其他跟

25、踪方法来传递 EventId。有选择地启用跟踪与日志记录典型的应用程序通常由多个逻辑组件组成。例如，您可能有一个数据库组件，用来处理 Windows Azure 存储空间中的数据模型。您的 Web 角色可能被依次划分到一个管理组件和一个用户组件中（根据应用程序的需要，甚至可能进一步划分到逻辑组件中）。您可以将日志记录与跟踪选项（启用哪种日志记录，详细程度如何）与这些组件相关联。这样，您就可以有选择性地仅在需要的组件中启用跟踪，从而避免混乱。此处的关键方法是不直接调用 Trace，而是使用多个 TraceSource 实例，通常情况下，对每个命名空间使用一个。TraceSource 有一个关联的

26、 SourceSwitch，用于控制是否启用该源以及所需的输出级别。重要的是，SourceSwitch 值不是在编译时设置的，而是在运行时设置的。因此，您可以从应用程序的各个部分启用或禁用诊断输出，而不需要重新编译应用程序甚至重新部署不同的版本。在示例代码中，WorkerDiagnostics.cs 和 WebDiagnostics.cs 包含跟踪源和开关的配置。下面摘录了一段：复制代码 / Trace sourcespublic TraceSource ConfigTrace;public TraceSource WorkerTrace;/ Add additional sources he

27、re/ Corresponding trace switches to control / level of output for each sourcepublic SourceSwitch ConfigTraceSwitch get; set; public SourceSwitch WorkerTraceSwitch get; set; / Add additional switches 1:1 with trace sources here然后，在角色的配置文件中，您可以将这些内容连接到侦听器，如图 4 所示。它首先会将标准的 Windows Azure 诊断侦听器设置为共享侦听器，使其可供 项引用。然后会配置两个源：WorkerTrace 源和 ConfigTrace 源。此外，还会设置相应的开关，您可以用来调整输出级别。ConfigTrace 提供了最详细的输出；WorkerTrace 仅提供“错误”输出。图 4 配置跟踪源和侦听器复制代码