Azure 诊断故障排除

本文介绍有关使用 Azure 诊断的故障排除信息。 有关诊断的详细信息,请参阅 Azure 诊断概述

逻辑组件

组件如下:

  • 诊断插件启动器 (DiagnosticsPluginLauncher.exe):启动诊断扩展。 它用作入口点进程。
  • 诊断插件 (DiagnosticsPlugin.exe):配置、启动和管理监视代理的生命周期。 这是由启动器启动的主要进程。
  • 监视代理(MonAgent.exe 进程):监视、收集和传输诊断数据。

日志/项目路径

以下路径指向一些重要日志和项目。 本文始终引用此信息。

Azure 云服务

项目 `Path`
Azure 诊断配置文件 %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\Config.txt
日志文件 C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\
诊断数据的本地存储 C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Tables
监视代理配置文件 C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MaConfig.xml
Azure 诊断扩展包 %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>
日志收集实用工具路径 %SystemDrive%\Packages\GuestAgent\
MonAgentHost 日志文件 C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.log

虚拟机

项目 `Path`
Azure 诊断配置文件 C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\RuntimeSettings
日志文件 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\
诊断数据的本地存储 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
监视代理配置文件 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xml
状态文件 C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\Status
Azure 诊断扩展包 C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>
日志收集实用工具路径 C:\WindowsAzure\Logs\WaAppAgent.log
MonAgentHost 日志文件 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.log

指标数据不显示在 Azure 门户中

诊断提供可在 Azure 门户中显示的指标数据。 如果无法查看门户中的这些数据,请检查诊断存储帐户中的 WADMetrics\* 表,以查看是否存在相应的指标记录,并确保资源提供程序 Microsoft.Insights 已注册。

此处,表的 PartitionKey 是资源 ID、虚拟机或虚拟机规模集。 RowKey 是指标名称。 它也称为性能计数器名称。

如果资源 ID 不正确,请检查“诊断配置”>“指标”>“ResourceId”,以查看是否已正确设置资源 ID。

如果没有特定指标数据,请检查“诊断配置”>“PerformanceCounter”,以查看是否包含指标(性能计数器) 。 默认启用以下计数器:

  • \Processor(_Total)% Processor Time
  • \Memory\Available Bytes
  • \ASP.NET Applications(Total)\Requests/Sec
  • \ASP.NET Applications(Total)\Errors Total/Sec
  • \ASP.NET\Requests Queued
  • \ASP.NET\Requests Rejected
  • \Processor(w3wp)% Processor Time
  • \Process(w3wp)\Private Bytes
  • \Process(WaIISHost)% Processor Time
  • \Process(WaIISHost)\Private Bytes
  • \Process(WaWorkerHost)% Processor Time
  • \Process(WaWorkerHost)\Private Bytes
  • \Memory\Page Faults/sec
  • .NET CLR Memory(Global)% Time in GC
  • \LogicalDisk(C:)\Disk Write Bytes/sec
  • \LogicalDisk(C:)\Disk Read Bytes/sec
  • \LogicalDisk(D:)\Disk Write Bytes/sec
  • \LogicalDisk(D:)\Disk Read Bytes/sec

如果配置设置正确,但仍看不到指标数据,请按照以下指南进行故障排除。

Azure 诊断未启动

有关为何诊断无法启动的信息,请参阅之前提供的日志文件位置中的 DiagnosticsPluginLauncher.log 和 DiagnosticsPlugin.log 文件。

如果这些日志指示 Monitoring Agent not reporting success after launch,则表示启动 MonAgentHost.exe 失败。 在之前的“虚拟机”部分中指示的 MonAgentHost 日志文件位置查看日志。

日志文件的最后一行包含退出代码。

DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0

如果发现退出代码为负数,请参阅参考部分中的退出代码表

未将诊断数据记录到 Azure 存储

确定是未显示数据还是仅显示了部分数据。

诊断基础结构日志

诊断将在诊断基础结构日志中记录所有错误。 请确保已在配置中允许捕获诊断基础结构日志。 然后,可在配置的存储帐户中快速查找 DiagnosticInfrastructureLogsTable 表中显示的任何相关错误。

未显示数据

完全不显示事件数据的最常见原因,是存储帐户信息定义不正确。

解决方案:更正诊断配置,然后重新安装诊断。

如果存储帐户配置正确,请远程访问计算机,验证 DiagnosticsPlugin.exe 和 MonAgentCore.exe 是否正在运行。 如果未运行,请按照 Azure 诊断未启动中的步骤进行操作。

如果进程正在运行,请转到数据是否是本地捕获的?并按此处的介绍进行操作。

如果仍有问题,请尝试:

  1. 卸载代理。
  2. 删除目录 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics。
  3. 再次安装代理。

部分数据丢失

如果获得了部分数据,则表示数据收集/传输管道设置正确。 请按照此处的子节说明,缩小问题范围。

是否配置了收集?

诊断配置包含要收集的特定类型数据的介绍。 查看配置以验证是否仅查找已配置进行收集的数据。

主机是否生成数据?

  • 性能计数器:打开 perfmon 并检查计数器。
  • 跟踪日志:远程访问 VM 并向应用的配置文件添加 TextWriterTraceListener。 要设置文本侦听器,请参阅创建和初始化跟踪侦听器。 确保 <trace> 元素具有 <trace autoflush="true">。 如果没有看到生成跟踪日志,请查看“关于缺失的跟踪日志的更多信息”部分。
  • Windows 事件跟踪 (ETW) 跟踪:远程访问 VM 并安装 PerfView 工具。 在 PerfView 中运行“文件”>“用户命令”>“侦听 etwprovder1”>“etwprovider2”等 。 侦听命令区分大小写,ETW 提供程序的逗号分隔列表之间不能有空格。 如果命令未能运行,可选择 PerfView 工具右下角的“日志”,查看尝试运行的内容以及结果。 假设输入正确,则会打开一个新窗口。 几秒钟后,可看到 ETW 跟踪。
  • 事件日志:远程访问 VM。 打开事件查看器并确保事件存在。

数据是否是本地捕获的?

接下来,请确保本地捕获到了数据。 数据本地存储在诊断数据本地存储中的 *.tsf 文件中。 不同类型的日志被收集在不同的 .tsf 文件中。 文件名称与 Azure 存储中的表名相似。

例如,性能计数器收集在 PerformanceCountersTable.tsf 中。 事件日志收集在 WindowsEventLogsTable.tsf 中。 使用本地日志提取部分中的说明打开本地收集文件,验证它们是否是在磁盘上收集的。

如果没有看到在本地收集日志,并且已确认主机正在生成数据,则可能是有配置问题。 仔细查看配置。

还要查看为 MonitoringAgent MaConfig.xml 生成的配置。 验证是否存在描述相关日志源的部分。 然后验证该部分未在诊断配置和监视代理配置间的转换中丢失。

是否传输了数据?

如果已验证数据是本地捕获的,但仍未在存储帐户中看到它,请按以下步骤操作:

  • 验证提供的存储帐户是否正确,且是否有为给定的存储帐户滚动更新过密钥。 对于 Azure 云服务,有时用户不更新 useDevelopmentStorage=true
  • 验证提供的存储帐户是否正确。 确保未受到一些禁止组件访问公共存储终结点的网络限制。 执行此操作的一种方法是远程访问计算机,并自行尝试向相同的存储帐户写入一些内容。
  • 最后,可查看监视代理报告的故障。 监视代理将其日志写入位于诊断数据本地存储中的 maeventtable.tsf。 按照本地日志提取部分中的说明打开此文件。 然后尝试确定是否有 errors 指示读取本地文件或写入存储失败。

捕获和存档日志

如果打算联系支持人员,他们可能会要求你做的第一件事是从计算机收集日志。 可以通过自行收集节省时间。 在日志收集实用程序路径上运行 CollectGuestLogs.exe 实用程序。 它会在同一文件夹中生成一个 .zip 文件,其中包含所有相关 Azure 日志。

找不到诊断数据表

Azure 存储中保存 ETW 事件的表是使用以下代码命名的:

        if (String.IsNullOrEmpty(eventDestination)) {
            if (e == "DefaultEvents")
                tableName = "WADDefault" + MD5(provider);
            else
                tableName = "WADEvent" + MD5(provider) + eventId;
        }
        else
            tableName = "WAD" + eventDestination;

下面是一个示例:

        <EtwEventSourceProviderConfiguration provider="prov1">
          <Event id="1" />
          <Event id="2" eventDestination="dest1" />
          <DefaultEvents />
        </EtwEventSourceProviderConfiguration>
        <EtwEventSourceProviderConfiguration provider="prov2">
          <DefaultEvents eventDestination="dest2" />
        </EtwEventSourceProviderConfiguration>
"EtwEventSourceProviderConfiguration": [
    {
        "provider": "prov1",
        "Event": [
            {
                "id": 1
            },
            {
                "id": 2,
                "eventDestination": "dest1"
            }
        ],
        "DefaultEvents": {
            "eventDestination": "DefaultEventDestination",
            "sinks": ""
        }
    },
    {
        "provider": "prov2",
        "DefaultEvents": {
            "eventDestination": "dest2"
        }
    }
]

此代码生成四个表:

事件 表名称
provider="prov1" <Event id="1" /> WADEvent+MD5("prov1")+"1"
provider="prov1" <Event id="2" eventDestination="dest1" /> WADdest1
provider="prov1" <DefaultEvents /> WADDefault+MD5("prov1")
provider="prov2" <DefaultEvents eventDestination="dest2" /> WADdest2

参考

请查看以下参考资料

检查诊断扩展配置

检查扩展配置的最简单方法是转到 Azure 资源浏览器。 然后转到诊断扩展 (IaaSDiagnostics/PaaDiagnostics) 所在的虚拟机或云服务。

或者,通过远程桌面连接到计算机并查看“日志项目路径”部分中所述的诊断配置文件。

在任何一种情况下,都请先搜索“Microsoft.Azure.Diagnostics”,再搜索“xmlCfg”或“WadCfg”字段。

如果在虚拟机上进行搜索,且存在 WadCfg 字段,则表示配置为 JSON 格式 。 如果存在 xmlCfg 字段,则表示配置在 XML 中,且已进行 base64 编码。 你需要将其解码才能查看诊断加载的 XML。

对于云服务角色,如果从磁盘选择配置,数据采用 base64 编码。 需要将其解码才能查看诊断加载的 XML。

Azure 诊断插件退出代码

该插件返回以下退出代码:

退出代码 说明
0 成功。
-1 常规错误。
-2 无法加载 rcf 文件。

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。

-3 无法加载诊断配置文件。

解决方案:这是配置文件未通过架构验证的结果。 解决方案是提供符合架构的配置文件。

-4 监视代理诊断的另一个实例已在使用本地资源目录。

解决方案:为“LocalResourceDirectory”指定不同的值 。

-6 来宾代理插件启动器尝试使用无效的命令行启动诊断。

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。

-10 诊断插件因未处理的异常而退出。
-11 来宾代理程序无法创建负责启动和监视监视代理的进程。

解决方案:验证是否有足够的系统资源可用于启动新进程。

-101 调用诊断插件时参数无效。

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。

-102 插件进程将无法初始化自身。

解决方案:验证是否有足够的系统资源可用于启动新进程。

-103 插件进程将无法初始化自身。 具体而言,它无法创建记录器对象。

解决方案:验证是否有足够的系统资源可用于启动新进程。

-104 无法加载来宾代理提供的 rcf 文件。

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。

-105 诊断插件无法打开诊断配置文件。

这是一个内部错误,仅当在 VM 上不正确地手动调用了诊断插件时才会发生。

-106 无法读取诊断配置文件。

这是配置文件未通过架构验证的结果。

解决方案:提供符合架构的配置文件。 有关详细信息,请参阅检查诊断扩展配置

-107 传递给监视代理的资源目录无效。

此内部错误应仅当在 VM 上不正确地手动调用了监视代理时才会发生。

-108 无法将诊断配置文件转换为监视代理配置文件。

这是一个内部错误,仅当使用无效的配置文件手动调用了诊断插件时才会发生。

-110 常规诊断配置错误。

这是一个内部错误,仅当使用无效的配置文件手动调用了诊断插件时才会发生。

-111 无法启动监视代理。

解决方案:验证是否有足够的系统资源可用。

-112 常规错误。

本地日志提取

监视代理将日志和项目收集为 .tsf 文件。 .tsf 文件不可读,但可以将其转换为 .csv,如下所示:

<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf

将在与相应 .tsf 文件相同的路径中创建一个名为 <relevantLogFile>.csv 的新文件。

注意

只需对主 .tsf 文件(例如 PerformanceCountersTable.tsf)运行此实用工具。 将自动处理随附的文件(例如 PerformanceCountersTables_\*\*001.tsfPerformanceCountersTables_\*\*002.tsf)。

关于跟踪日志丢失的更多信息

注意

以下信息主要适用于 Azure 云服务,除非已在于基础结构即服务 (IaaS) VM 上运行的应用程序上配置了 DiagnosticsMonitorTraceListener

  • 确保在 web.config 或 app.config 中配置了 DiagnosticMonitorTraceListener。这是云服务项目中默认配置的。 然而,某些客户将其注释掉了,导致诊断不收集相关跟踪语句。
  • 如果没有从 OnStart 或 Run 方法写入日志,请确保 DiagnosticMonitorTraceListener 位于 app.config 中。默认情况下,它位于 web.config 中,但这仅适用于在 w3wp.exe 中运行的代码。 因此需将其置于 app.config 中,以捕获在 WaIISHost.exe 中运行的跟踪。
  • 确保使用 Diagnostics.Trace.TraceXXX 而不是 Diagnostics.Debug.WriteXXX。Debug 语句已从发布版本中删除。
  • 确保已编译的代码实际上具有 Diagnostics.Trace 行。 使用反射器、ildasm 或 ILSpy 进行验证。 从已编译的二进制文件中删除了 Diagnostics.Trace 命令,除非使用 TRACE 条件编译符号 。 这是使用 MSBuild 构建项目时常会发生的问题。

已知问题和缓解措施

以下已知问题具有缓解措施。

.NET 4.5 依赖项

适用于 Windows 的 Azure 诊断扩展对于 .NET Framework 4.5 或更高版本存在运行时依赖关系。 撰写本文时,为 Azure 云服务预配的所有计算机以及基于 Azure VM 的所有官方映像都安装了 .NET 4.5 或更高版本。

尝试在未安装 .NET 4.5 或更高版本的计算机上运行适用于 Windows 的 Azure 诊断扩展时,仍可能遇到问题。 从旧映像或快照创建计算机或者自带自定义磁盘时,会发生这种情况。

此问题在运行 DiagnosticsPluginLauncher.exe 时通常显示为退出代码 255。以下未经处理的异常导致失败:

System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies

缓解: 在计算机上安装 .NET 4.5 或更高版本。

性能计数器数据在存储中可用,但不显示在门户中

默认情况下,VM 中的门户体验会显示某些性能计数器。 如果未看到性能计数器,且知道正在生成数据,因为数据在存储中可用,请确保检查:

  • 存储中的数据是否有英文计数器名称。 如果计数器名称不是英文,门户指标图表无法识别它。

    • 缓解措施:将系统帐户的计算机语言更改为英语。 要执行此操作,请选择“控制面板”>“区域”>“管理”>“复制设置” 。 接下来,清除“欢迎界面和系统帐户”,以免将自定义语言应用到系统帐户。
  • 如果在性能计数器名称中使用通配符 (*),则在将性能计数器发送到 Azure 存储接收器时,门户无法关联已配置和已收集的计数器。

    • 缓解措施:若要确保可以使用通配符并让门户展开 (*),请将性能计数器路由到“Azure Monitor”接收器。