Compartir a través de

Azure 诊断故障排除

  • Artículo

本文介绍有关使用 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.tsf、PerformanceCountersTables_\*\*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”接收器。