控制 Windows Azure 中的日志记录与跟踪.docx
《控制 Windows Azure 中的日志记录与跟踪.docx》由会员分享，可在线阅读，更多相关《控制 Windows Azure 中的日志记录与跟踪.docx（24页珍藏版）》请在冰豆网上搜索。
控制WindowsAzure中的日志记录与跟踪
云诊断
控制WindowsAzure中的日志记录与跟踪
MikeKelly
下载代码示例
与许多程序员一样，我在刚刚开始编写代码时，使用print语句进行调试。
我不知道如何使用调试器，而print语句虽然简陋，却可以作为一种有效的方式用来查看程序在运行时的情况。
后来，我学会了使用真正的调试器，而不再使用print语句作为调试工具。
很快，我开始编写在服务器上运行的代码。
我发现这些print语句现在被用于更为复杂的“日志记录与跟踪”，而日志记录与跟踪是任何编写服务器应用程序的程序员的基本技术。
即使您能够将调试器与生产服务器应用程序相连（这通常无法实现，因为用来托管应用程序的计算机上存在一定的安全限制），也很难通过传统的调试器来揭示服务器应用程序所遇到的问题类型。
许多服务器应用程序都是分布式的，运行在多台计算机上，因此对一台计算机上发生的情况进行调试，并不总是能诊断出真正的问题。
此外，服务器应用程序经常是在某位操作人员的控制下运行，操作人员不了解如何使用传统的调试器，而每次遇到问题都找来开发人员并不可取或者不切实际。
在本文中，我将介绍一些用于服务器应用程序的基本的日志记录、跟踪和调试技术。
然后，将深入介绍如何在WindowsAzure项目中利用这些技术。
在此期间，您会看到如何对一些实际的应用程序执行日志记录和跟踪，并且我会介绍如何使用WindowsPowerShell来管理针对运行中的服务的诊断。
日志记录策略
理想情况下，任何服务器应用程序（几乎所有Web应用程序，包括运行在WindowsAzure下的应用程序）都应该在一开始就设计好日志记录和跟踪策略。
日志记录信息应该足够可靠，能够描述每个组件中发生的几乎每一件事。
但是，就像我最早在程序中添加的那些print语句会产生大量输出一样，日志记录也会产生大量输出。
因此，设计优良的日志记录和跟踪需要包含一些方法，用来调整任意组件的日志记录的类型和容量。
这就使操作人员和开发人员能够关注某个表现不正常的组件，甚至可能是某台计算机，以便获得更详细的信息来准确了解其中发生的情况，而不会在日志中生成大量无用信息，这些信息会分散注意力，甚至可能大大降低应用程序的性能。
此外，由于服务器应用程序通常都是分布式应用程序，因此必须从多台计算机（可能处于不同的应用程序角色）收集信息并进行汇总，以便全面了解发生特定问题时的情况。
因此，非常重要的一点是，利用某种方法来识别通过计算机的事务线程，这样就可以汇总相关的事实信息。
WindowsAzure中提供的日志记录在社区技术预览（CTP）发行期间已经成熟。
早期的日志记录并不比print语句复杂很多，可作为WindowsAzure表存储空间中的文本来捕获。
从PDC09版开始，WindowsAzure开始提供一套功能更加全面的日志记录与跟踪基础结构，这套基础结构基于Windows事件跟踪（ETW）框架。
此ETW框架在ASP.NET中是通过System.Diagnostics命名空间中的类来支持的。
Microsoft.WindowsAzure.Diagnostics命名空间继承并扩展了标准的System.Diagnostics类，从而能够使用System.Diagnostics作为WindowsAzure环境中的日志记录框架。
图1显示了WindowsAzure诊断如何实现ETW。
图1WindowsAzure诊断的高度概览
ETW提供了一个模型，在此模型中可以将代码记录到一个或多个TraceSource。
每个源中允许的日志记录级别是由SourceSwitch控制的。
这些源将依次连接到一个或多个使用者，使用者会通过各种方法来永久保存日志记录信息。
WindowsAzure提供了一种标准的使用者或侦听器，用来将您生成的日志记录信息永久保存到WindowsAzure表存储空间或Blob存储空间。
如果您希望利用事件数据来完成其他的任务，则可以自行编写使用者，或者也可以使用现成的使用者（但有些使用者必须经过修改才能在WindowsAzure环境中使用）。
ETW框架为每个事件都关联了一个TraceEventType，如图2所示。
前五个严重程度行是最常用的值，它们指出了跟踪输出的相对重要程度。
请注意，WindowsCommunicationFoundation（WCF）将使用“暂停”、“继续”和“转移”这几个类型。
图2跟踪事件类型
跟踪事件类型
值
含义
关键
0x0001
严重错误或应用程序崩溃
错误
0x0002
可修复的错误
警告
0x0004
不严重的问题，但可能意味着会发生更严重的问题
信息
0x0008
提示性信息
详细
0x0010
调试跟踪（例如详细的执行流程信息、参数等等）
开始
0x0100
开始某项逻辑操作
停止
0x0200
停止某项逻辑操作
暂停
0x0400
暂停某项逻辑操作
继续
0x0800
继续某项逻辑操作
转移
0x1000
转移到新活动
如果只想查找真正的问题，您可能需要确保捕获“严重”值，或许还包括“错误”值。
如果想详细了解发生的情况，则需要查看“详细”以上级别的所有内容。
您的日志记录策略应该对层次结构中各值使用一致的事件类型和详细日志记录项。
如果在您的应用程序中启用了对所有重点值的日志记录，应该有可能真正追踪应用程序的执行流程。
这对于在生产环境中解决错误或问题具有重大价值。
您可以将侦听器、源和开关连接起来，从而通过编程来实现不同级别的输出，但这通常是通过配置文件来完成的。
您可以在app.config（对于WindowsAzure工作者角色）或web.config（对于WindowsAzureWeb角色）中配置输出。
但如果将此配置放入ServiceConfiguration.cscfg中，您就可以在WindowsAzure服务运行期间调整日志记录与跟踪选项，而不用为正在运行的代码重新部署任何更新甚至停止服务。
我会在下文中对此做出详细解释。
WindowsAzure还提供了RESTful接口，用于远程控制某些日志记录选项。
WindowsPowerShell可以使用该RESTful接口。
日志记录、跟踪和调试输出
日志记录、跟踪和调试输出这几个术语有时可以互换使用。
在本文中，我会将您的代码中通常称为诊断输出的内容分为四种不同的类型。
这四种类型大致是按从最详细到最简略的顺序排列。
▪调试输出：
此类信息仅出现在应用程序的调试版中；而对于发行版，在编译时需要排除此类信息（根据编译时是否定义了DEBUG预处理器符号进行排除，默认情况下VisualStudio只会在调试版中定义此符号）。
通常，调试输出包括类似于您添加的“声明”之类的信息，这些信息有助于发现代码不符合预期前提条件、会导致错误甚至数据结构转储的情况。
添加这些声明可帮助您在调试和测试过程中调试算法。
▪跟踪：
此类信息是指一些语句，用于在程序运行时帮助跟踪控制流和程序状态。
想象一下：
运行一个调试器，一步步执行代码，然后在监视窗口中查看关键变量的值。
跟踪语句的作用就是在您无法连接调试器时再现这种体验。
从理论上说，跟踪语句应该能够提供足够的上下文信息，通过阅读跟踪语句，您可以了解应用程序在每个控制点都选择哪条执行路径，以及代码中接下来的操作类型。
如果在编译时定义了TRACE预处理器符号，就会启用跟踪，在发行版和调试版中都可以进行跟踪。
（默认情况下，VisualStudio在调试版和发行版中均定义了TRACE，当然，您可以进行更改。
）
▪事件日志记录：
此类信息是指一些语句，用于在应用程序运行过程中捕获主要事件，例如：
开始事务，或者向数据库中添加项目。
事件日志记录与跟踪的差别在于它捕获的是重要状态，而不是详细的控制流。
▪错误日志记录：
此类信息是指一些特殊的事件日志记录，用于捕获异常或可能存在危险的情况。
具体的例子包括：
捕获的任何异常；您应该能够访问另一台计算机上的资源却不能访问的情况（当然，您的应用程序应该能够妥善处理，但也需要注意）；以及您认为不会出错却从API返回错误的情况。
在尚未出现错误但有征兆表明很快会出现错误的情况下（例如，配额接近上限，或者某项事务成功执行但花费的时间超出正常情况），错误日志记录对操作人员也很有用。
这些类型的日志记录事件可帮助操作人员在问题发生之前主动采取措施，使应用程序避免发生停机。
大多数优秀的开发人员都习惯于在应用程序中包含调试输出，以帮助他们在开发过程中诊断问题，而且许多人已经开发出了用于错误日志记录的某种解决方案。
但是，您需要确保不仅考虑到调试输出和错误日志记录选项，还拥有一种可靠的跟踪和事件日志记录策略，从而真正有助于诊断只有在生产环境中的高压负载下才会发生的问题。
此外，还需要慎重考虑，您现在当作调试输出的许多内容是否确实需要跟踪以及在发行版和调试版中均提供。
生产环境中表现不正常的应用程序通常运行的是发行版。
如果跟踪语句已存在，但是被禁用了（我会在下文中介绍如何操作），您可以有选择地启用它们，以便从发行版获得类似于调试版的详细输出，从而帮助您诊断问题。
WindowsAzure中的跟踪与日志记录
您可以直接使用WindowsAzure的日志记录功能，该功能是WindowsAzureSDK的一部分。
使用Logger.NET、EnterpriseLibrary、log4net或Ukadc.Diagnostics之类的日志记录框架有一些好处。
这些框架为您的日志记录消息附加了结构，也有助于提供上文所述的某些可配置性。
但是，大部分框架未经调整，不能在WindowsAzure环境中使用；有些也远不止是日志记录框架。
对于本文的示例代码，我决定只使用标准的WindowsAzure日志记录与跟踪API，并在其上加上一个薄层来提供动态配置功能。
您可能会发现，如果在此基础上为您的日志记录与跟踪策略构建一些帮助程序类和一个框架，会对您有所帮助，或者也可以留意其他框架是否具有适用于WindowsAzure的版本。
使用VisualStudio在WindowsAzure中创建新服务后，就已经在该服务中启用基本的日志记录功能。
通过WindowsAzure模板生成的样板工作者角色和Web角色的代码已经配置并启用了诊断侦听器。
若要在WindowsAzure服务中启用简单的日志记录，请在VisualStudio中使用“WindowsAzure云服务（VisualC#）”模板来启动新项目。
然后为项目指定名称。
在我的示例中，我使用了MSDNSampleLoggingService。
单击“确定”。
“新建云服务项目”向导将运行。
在该向导中，为项目添加一个工作者角色和一个Web角色。
将工作者角色重命名为LoggingWorkerRole，将Web角色重命名为LoggingWebRole，然后单击“确定”。
VisualStudio将会创建该项目。
此时，您可以浏览生成的代码。
查看LoggingWorkerRole项目中的app.config，您会注意到出现了以下代码：
复制代码
xmlversion="1.0"encoding="utf-8"?
>
此代码会将标准WindowsAzure诊断侦听器连接到您的代码，这就意味着，除非您进行更改，否则您从工作者角色执行的任何日志记录和跟踪都会被定向到WindowsAzure侦听器（DiagnosticMonitorTraceListener）。
对于为此服务创建的Web角色，您会在web.config中找到类似的条目。
如果您查看工作者角色项目中的WorkerRole.cs文件，还会在OnStart方法中看到以下行：
复制代码
DiagnosticMonitor.Start（"DiagnosticsConnectionString"）;
并且在Run方法中，您会看到对跟踪的调用：
复制代码
//Thisisasampleworkerimplementation.Replacewithyourlogic.
Trace.WriteLine（"LoggingWorkerRoleentrypointcalled","Information"）;
最后，如果您查看位于“服务”根目录下的ServiceConfiguration.cscfg文件，您会看到对应于工作者角色和Web角色的以下行：
复制代码
value="UseDevelopmentStorage=true"/>
该行用于告知WindowsAzure侦听器，使用哪个存储帐户来永久保存日志记录与跟踪信息。
在本例中，日志记录信息将存储在本地计算机上的开发存储空间中。
如果将此设置切换为WindowsAzure云存储帐户，则可以将日志定位到云存储空间。
下面是本文所提供的示例代码中的格式示例：
复制代码
value="DefaultEndpointsProtocol=https;AccountName=Xxxxxx;AccountKey=Yyyyyy"/>
AccountName和AccountKey值需要根据您的实际Azure帐户和密钥来自定义。
您可以从您服务的存储帐户门户（网址为）获取此信息。
AccountName是URL中对应于表和Blob存储端点的第一部分（“”之前的部分）。
AccountKey是您的存储帐户的base-64编码的主访问密钥。
请注意，由于有一个单独的存储帐户用于诊断，因此您可以选择将诊断信息与其他的应用程序数据分开存放。
为此，请在门户页面上单击“新建服务”，选择“存储帐户”，然后指定名称（例如MyAppLogs），从而设置单独的存储帐户。
您可能需要设置一个相关性组，使您的日志与服务存储在相同的区域中。
至此，您已经快速了解了WindowsAzure服务中的跟踪代码，可以运行您创建的简单Web角色项目了。
请注意，在调试版中，WindowsAzure所提供的默认侦听器还会将输出定位到VisualStudio中的输出窗口，因此您会在调试窗口中看到OnStart消息：
复制代码
Information:
LoggingWorkerRoleentrypointcalled
如果您想在服务运行后查看日志，该怎么办？
默认情况下，WindowsAzure不会将日志永久保存到存储空间。
您可以在自己角色的OnStart方法中添加几行代码，命令WindowsAzure这么做：
复制代码
TimeSpantsOneMinute=TimeSpan.FromMinutes
（1）;
DiagnosticMonitorConfigurationdmc=
DiagnosticMonitor.GetDefaultInitialConfiguration（）;
//Transferlogstostorageeveryminute
dmc.Logs.ScheduledTransferPeriod=tsOneMinute;
//Transferverbose,critical,etc.logs
dmc.Logs.ScheduledTransferLogLevelFilter=LogLevel.Verbose;
//Startupthediagnosticmanagerwiththegivenconfiguration
DiagnosticMonitor.Start（"DiagnosticsConnectionString",dmc）;
如果将此代码添加到WorkerRole.cs中并重新运行，会使WindowsAzure每分钟向开发存储空间转移一次日志。
您也可以选择根据需要转移日志（请参见我的示例应用程序中admin.aspx.cs文件的代码来了解如何操作），或者使用下文介绍的WindowsPowerShell命令。
请记住，一旦将日志转移到存储空间，您就需要为所使用的存储空间付费，而且当您不再需要这些信息时，需要自行将其删除。
当您将日志传送到WindowsAzure存储空间后，还需要一个工具来查看存储表，从中可以看到日志。
我使用了Cerebrata的CloudStorageStudio（）。
Cerebrata曾经发布过一款名为AzureDiagnosticsManager的工具，CodePlex（）上也提供了用于查看云存储空间和诊断信息的免费工具。
日志存放在名为WADLogsTable的表中，您可以在图3中看到该表。
图3永久保存在开发存储空间中的日志
当您查看存储空间中的日志时，会注意到两件事。
首先，WindowsAzure会自动将一些信息与每个记录的事件相关联，例如时间戳、滴答计数（以100纳秒为单位提供更详细的时间信息），以及有关部署、角色和角色实例的信息。
这使您能够根据需要将日志限定在特定的实例范围内。
其次，每个事件都关联了Level和EventId。
Level对应于图2中的值：
记录为“信息”的跟踪事件的Level值为4，记录为“错误”的跟踪事件的Level值为2。
通过Trace.WriteLine发送（如样板代码所执行的操作）的一般事件的Level值为5（详细）。
EventId的值由您指定。
上文所示的基本Trace.WriteLine调用并没有让您指定该值；您必须使用其他跟踪方法来传递EventId。
有选择地启用跟踪与日志记录
典型的应用程序通常由多个逻辑组件组成。
例如，您可能有一个数据库组件，用来处理WindowsAzure存储空间中的数据模型。
您的Web角色可能被依次划分到一个管理组件和一个用户组件中（根据应用程序的需要，甚至可能进一步划分到逻辑组件中）。
您可以将日志记录与跟踪选项（启用哪种日志记录，详细程度如何）与这些组件相关联。
这样，您就可以有选择性地仅在需要的组件中启用跟踪，从而避免混乱。
此处的关键方法是不直接调用Trace，而是使用多个TraceSource实例，通常情况下，对每个命名空间使用一个。
TraceSource有一个关联的SourceSwitch，用于控制是否启用该源以及所需的输出级别。
重要的是，SourceSwitch值不是在编译时设置的，而是在运行时设置的。
因此，您可以从应用程序的各个部分启用或禁用诊断输出，而不需要重新编译应用程序甚至重新部署不同的版本。
在示例代码中，WorkerDiagnostics.cs和WebDiagnostics.cs包含跟踪源和开关的配置。
下面摘录了一段：
复制代码
//Tracesources
publicTraceSourceConfigTrace;
publicTraceSourceWorkerTrace;
//Addadditionalsourceshere
//Correspondingtraceswitchestocontrol
//levelofoutputforeachsource
publicSourceSwitchConfigTraceSwitch{get;set;}
publicSourceSwitchWorkerTraceSwitch{get;set;}
//Addadditionalswitches1:
1withtracesourceshere
然后，在角色的配置文件中，您可以将这些内容连接到侦听器，如图4所示。
它首先会将标准的WindowsAzure诊断侦听器设置为共享侦听器，使其可供项引用。
然后会配置两个源：
WorkerTrace源和ConfigTrace源。
此外，还会设置相应的开关，您可以用来调整输出级别。
ConfigTrace提供了最详细的输出；WorkerTrace仅提供“错误”输出。
图4配置跟踪源和侦听器
复制代码
name="AzureDiagnostics">
升级会员 