Windows Azure 1.4 诊断综述
原文发布于 2011 年 8 月 24 日（星期三）
我知道已经有大量帖子和文章介绍过 Windows Azure 中诊断功能的用法。这实际上给我在充实最近发布内容的详情时带来了一些麻烦。我发现了众多不同的文章，但它们涉及许多不同版本的 Azure，因此要确定哪些文章适合最新的 Azure SDK (1.4) 相当耗时。所以，本文汇总了将 Azure 诊断与 1.4 版 SDK 结合使用的要点。
首先，你们中的许多人可能都知道，Azure 包括一个内置的跟踪侦听器，可获取您的 Trace.* 命令（如 Trace.Write、Trace.WriteLine、Trace.TraceInformation 等）并将其存储在内存中。但是，您需要“做些什么”才能将其从内存移到永久存储中。这可能需要执行手动数据转移，或者配置一个计划来转移数据。此外，您还可以选择移动事件日志中的信息，捕获性能计数器，移动 IIS 日志以及自定义日志。
除了上述所有典型的日志记录和调试工具外，您还可以将所用部署配置为允许您通过 RDP 连接到承载应用程序的 Azure 服务器，以及启用 IntelliTrace 在已部署的应用程序实现有限的调试和疑难解答。让我们来演练这些不同部分。
要配置不同的诊断组件（例如，将数据保存到存储中的频率、应分配的存储空间量、要捕获的性能计数器等），最简单的方法是在标准 Web 角色 Azure 应用程序附带的 WebRole.cs 文件中编写一些代码（我认为除 VM 角色之外的大多数 Azure 功能都具有类似于 WebRole 类的内容，如包含辅助角色项目的 WorkerRole.cs 文件）。在开始查看代码之前，您应该深入了解 Azure 角色项目，并选中“配置”选项卡上指示“为诊断结果指定存储帐户凭据:”的框。使用选取器按钮选择您在 Azure 中具有的存储帐户；请勿使用本地开发。这会将一个新连接字符串保存到名为 Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString 的项目中。
现在，我们看一下 Web 角色类中的整个代码块，然后我将解释其中一些细节：
public override bool OnStart()
{
// For information on handling configuration changes
// see the MSDN topic at https://go.microsoft.com/fwlink/?linkid=166357\&clcid=0x804（该链接可能指向英文页面）
try
{
//initialize the settings framework
Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});
//get the storage account using the default Diag connection string
CloudStorageAccount cs =
CloudStorageAccount.FromConfigurationSetting(
"Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");
//get the diag manager
RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(
RoleEnvironment.DeploymentId,
RoleEnvironment.CurrentRoleInstance.Role.Name,
RoleEnvironment.CurrentRoleInstance.Id);
//get the current configuration
DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();
//if that failed, get the values from config file
if (dc == null)
dc = DiagnosticMonitor.GetDefaultInitialConfiguration();
//Windows Azure Logs
dc.Logs.BufferQuotaInMB = 10;
dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);
//Windows Event Logs
dc.WindowsEventLog.BufferQuotaInMB = 10;
dc.WindowsEventLog.DataSources.Add("System!*");
dc.WindowsEventLog.DataSources.Add("Application!*");
dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);
//Performance Counters
dc.PerformanceCounters.BufferQuotaInMB = 10;
PerformanceCounterConfiguration perfConfig =
new PerformanceCounterConfiguration();
perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";
perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);
dc.PerformanceCounters.DataSources.Add(perfConfig);
dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);
//Failed Request Logs
dc.Directories.BufferQuotaInMB = 10;
dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);
//Infrastructure Logs
dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;
dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =
LogLevel.Verbose;
dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =
TimeSpan.FromMinutes(60);
//Crash Dumps
CrashDumps.EnableCollection(true);
//overall quota; must be larger than the sum of all items
dc.OverallQuotaInMB = 5000;
//save the configuration
dm.SetCurrentConfiguration(dc);
}
catch (Exception ex)
{
System.Diagnostics.Trace.Write(ex.Message);
}
return base.OnStart();
}
现在，我将详细介绍这些代码。我首先获取用于诊断的连接字符串的值，以便我可以连接到所使用的存储帐户。随后使用该存储帐户获取诊断监视器配置类。在拥有该类之后，即可开始配置各种日志记录组件。
所有 Trace.* 调用都保存在 Windows Azure 日志中。我将其配置为在其所用的表中最多存储 10MB 数据，并每 5 分钟将写入内容保存到表中一次（对日志记录级别或详细或更高的所有写入）。这样，您就可在以下网站中看到 Windows Azure 用于存储该日志记录数据的不同表和队列列表： https://msdn.microsoft.com/zh-cn/library/hh180875.aspx – 以及 – https://msdn.microsoft.com/zh-cn/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx（该链接可能指向英文页面）。基础结构日志和诊断日志几乎是一样的。
对于事件查看器条目，我必须将要捕获的每个日志添加到 WindowsEventLog 类的数据源列表中。我可以提供的值有 Application!* 、System!* 或 UserData!* 。其他属性与 Windows Azure 日志的相同。
对于性能计数器，您必须描述要捕获哪些计数器以及这些计数器对数据进行采样的频率。在上面的示例中，我为 CPU 添加了一个计数器，并将其配置为每 60 秒进行一次数据采样。
我最后做的几件事是启用故障转储捕获，将所有日志记录数据的总体配额更改为大约 5GB，然后保存更改。务必增加总体配额，否则可能会引发异常，提示您没有足够的可用存储来进行上述更改。目前 5GB 似乎是一个安全值，但您的情况可能有所不同。
现在万事俱备，可以发布应用程序了。当您从 Visual Studio 发布应用程序时，还有几件事需要注意：
在“发布设置”(Publish Settings) 对话框中，应选中用于启用 IntelliTrace 的框；稍后我将对此进行详细介绍。另外，还建议您单击指向“配置远程桌面连接…”(Configure Remote Desktop connections…) 的链接；有时我发现这是解决问题的唯一途径。由于远程桌面上的文档已经有点过时了，因此我只建议您使用此对话框而不是手动编辑配置文件。这将打开如下所示的对话框：
这里主要需要注意两件事：
- 您似乎可以使用任何具有 PFX 文件的证书。请注意，您必须将此证书上载到托管服务才能发布应用程序。
- “用户名”(User name) 字段可以是所需的任何内容；将创建一个使用该用户名和密码的本地帐户。
现在两个对话框均已完成，可以发布应用程序了。点击应用程序一次，将其激活，并确保您的 Web 角色代码可以执行。完成后，应该可以检查应用程序的诊断设置并查看实现的自定义设置，如下所示（注意：我使用的是免费的 CodePlex 工具来管理 Azure，可从 https://wapmmc.codeplex.com/（该链接可能指向英文页面） 下载该工具）：
在执行某些代码，并等到 Windows Azure 日志的下一个计划传输期间开始之后，我可以看到我的 Trace.* 调用显示在 WADLogsTable 中，如下所示：
而且，由于我在应用程序中配置了 RDP 支持，因此当我单击 Web 角色时，将在 Azure 开发人员门户的工具栏中启用与该角色建立 RDP 连接的选项：
现在我可以使用应用程序中的所有日志和跟踪了，如果需要进一步调查，可以通过 RDP 连接到服务器。我启用的另一个很酷的功能是 IntelliSense。对 IntelliSense 的介绍不在本文讨论范围之内，但您可以从下面的网站找到一些有用信息： https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx（该链接可能指向英文页面） 以及 https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx（该链接可能指向英文页面）。启用 IntelliTrace 后，当我在 Visual Studio 服务器资源管理器中查看我的托管服务时，会显示 IntelliTrace 已启用：
然后我可以右键单击应用程序中的某个实例，选择“查看 IntelliTrace 日志”(View IntelliTrace logs) 菜单项。此操作会从 Azure 下载 IntelliTrace 日志并在 Visual Studio 中打开它们，如下所示：
如图所示，我可以看到使用的线程、引发的任何异常、系统信息、加载的模块等。我模拟了一个异常，通过将我的诊断信息的总体存储分配设置为 5MB 进行了测试。您可能还记得我提到过需要 5GB 左右的配额。我进行了更改，发布了应用程序，然后在几分钟后下载了 IntelliTrace 日志。果然，我在日志第二页中发现了下面突出显示的错误：
就是这些了 – Windows Azure 1.4 诊断的综述。我们将捕获跟踪事件、事件日志、性能计数器、IIS 日志、故障转储以及任何自定义诊断日志文件。我可以在需要时通过 RDP 连接到服务器以排查其他问题。我可以从我的应用程序下载 IntelliTrace 日志并在我的 Visual Studio 2010 本地实例中进行有限的调试。
这是一篇本地化的博客文章。请访问 Windows Azure 1.4 Diagnostics All Up Overview 以查看原文