Azure 诊断故障排除Azure Diagnostics troubleshooting

本文介绍有关使用 Azure 诊断的故障排除信息。This article describes troubleshooting information that's relevant to using Azure Diagnostics. 有关 Azure 诊断的详细信息,请参阅 Azure 诊断概述For more information about Azure diagnostics, see Azure Diagnostics overview.

逻辑组件Logical components

诊断插件启动器 (DiagnosticsPluginLauncher.exe):启动 Azure 诊断扩展。Diagnostics Plugin Launcher (DiagnosticsPluginLauncher.exe): Launches the Azure Diagnostics extension. 用作入口点进程。Serves as the entry point process.

诊断插件 (DiagnosticsPlugin.exe):配置、启动和管理监视代理的生存期。Diagnostics Plugin (DiagnosticsPlugin.exe): Configures, launches, and manages the lifetime of the monitoring agent. 这是由启动器启动的主要进程。It is the main process that is launched by the launcher.

监视代理(MonAgent*.exe 进程):监视、收集和传输诊断数据。Monitoring Agent (MonAgent*.exe processes): Monitors, collects, and transfers the diagnostics data.

日志/项目路径 Log/artifact paths

以下是一些重要日志和项目的路径。Following are the paths to some important logs and artifacts. 文档剩余部分将始终引用此信息。We refer to this information throughout the rest of the document.

Azure 云服务Azure Cloud Services

项目Artifact PathPath
Azure 诊断配置文件Azure Diagnostics configuration file %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\Config.txt%SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\Config.txt
日志文件Log files C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\
诊断数据的本地存储Local store for diagnostics data C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\TablesC:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Tables
监视代理配置文件Monitoring agent configuration file C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MaConfig.xmlC:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MaConfig.xml
Azure 诊断扩展包Azure Diagnostics extension package %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>%SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>
日志收集实用工具路径Log collection utility path %SystemDrive%\Packages\GuestAgent\%SystemDrive%\Packages\GuestAgent\
MonAgentHost 日志文件MonAgentHost log file C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.logC:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.log

虚拟机Virtual machines

项目Artifact PathPath
Azure 诊断配置文件Azure Diagnostics configuration file C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\RuntimeSettingsC:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\RuntimeSettings
日志文件Log files C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\
诊断数据的本地存储Local store for diagnostics data C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\TablesC:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
监视代理配置文件Monitoring agent configuration file C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xmlC:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xml
状态文件Status file C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\StatusC:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\Status
Azure 诊断扩展包Azure Diagnostics extension package C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>
日志收集实用工具路径Log collection utility path C:\WindowsAzure\Logs\WaAppAgent.logC:\WindowsAzure\Logs\WaAppAgent.log
MonAgentHost 日志文件MonAgentHost log file C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.logC:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.log

指标数据不显示在 Azure 门户中Metric data doesn't appear in the Azure portal

Azure 诊断提供可在 Azure 门户中显示的指标数据。Azure Diagnostics provides metric data that can be displayed in the Azure portal. 如果无法查看门户中的这些数据,请检查 Azure 诊断存储帐户中的 WADMetrics* 表,以查看是否存在相应的指标记录。If you have problems seeing the data in portal, check the WADMetrics* table in the Azure Diagnostics storage account to see if the corresponding metric records are there.

此处,表的 PartitionKey 是资源 ID、虚拟机或虚拟机规模集。Here, the PartitionKey of the table is the resource ID, virtual machine, or virtual machine scale set. RowKey 是指标名称(也称为性能计数器名称)。RowKey is the metric name (also known as the performance counter name).

如果资源 ID 不正确,请检查“诊断配置” > “指标” > “ResourceId”,以查看是否已正确设置资源 ID。If the resource ID is incorrect, check Diagnostics Configuration > Metrics > ResourceId to see if the resource ID is set correctly.

如果没有特定指标数据,请检查“诊断配置” > “PerformanceCounter”,以查看是否包含指标(性能计数器)。If there's no data for the specific metric, check Diagnostics Configuration > PerformanceCounter to see if the metric (performance counter) is included. 默认启用以下计数器:We enable the following counters by default:

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

如果配置设置正确,但仍看不到指标数据,请按照以下指南进行故障排除。If the configuration is set correctly but you still can't see the metric data, use the following guidelines to help you troubleshoot.

Azure 诊断不启动 Azure Diagnostics is not starting

有关为和 Azure 诊断无法启动的信息,请参阅之前提供的日志文件位置中的 DiagnosticsPluginLauncher.log 和 DiagnosticsPlugin.log 文件 。For information about why Azure Diagnostics failed to start, see the DiagnosticsPluginLauncher.log and DiagnosticsPlugin.log files in the log files location that was provided earlier.

如果这些日志指示 Monitoring Agent not reporting success after launch,则表示启动 MonAgentHost.exe 失败。If these logs indicate Monitoring Agent not reporting success after launch, it means there was a failure launching MonAgentHost.exe. 在之前部分中指示 MonAgentHost log file 的位置查看日志。Look at the logs in the location that's indicated for MonAgentHost log file in the previous section.

日志文件的最后一行包含退出代码。The last line of the log files contains the exit code.

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

如果发现退出代码为负数,请参阅参考部分中的退出代码表If you find a negative exit code, refer to the exit code table in the References section.

未将诊断数据记录到 Azure 存储Diagnostics data is not logged to Azure Storage

确定是未显示数据还是仅显示部分数据。Determine if none of the data is appearing or some of the data is appearing.

诊断基础结构日志Diagnostics infrastructure logs

诊断将在诊断基础结构日志中记录所有错误。Diagnostics logs all errors in the Diagnostics infrastructure logs. 请确保已在配置中允许捕获诊断基础结构日志Make sure you have enabled the capture of Diagnostics infrastructure logs in your configuration. 然后,可在配置的存储帐户中快速查找 DiagnosticInfrastructureLogsTable 表中显示的任何相关错误。Then you can quickly look for any relevant errors that appear in the DiagnosticInfrastructureLogsTable table in your configured storage account.

未显示数据No data is appearing

完全不显示事件数据的最常见原因,是存储帐户信息定义不正确。The most common reason that event data doesn't appear at all is that the storage account information is defined incorrectly.

解决方案:更正诊断配置,然后重新安装诊断。Solution: Correct your Diagnostics configuration and reinstall Diagnostics.

如果存储帐户配置正确,请远程访问计算机,验证 DiagnosticsPlugin.exe 和 MonAgentCore.exe 是否正在运行。If the storage account is configured correctly, remote access into the machine and verify that DiagnosticsPlugin.exe and MonAgentCore.exe are running. 如果未运行,请按照 Azure 诊断不启动中的步骤进行操作。If they aren't running, follow the steps in Azure Diagnostics is not starting.

如果进程正在运行,请转到数据是否是本地捕获的?并按此处的介绍进行操作。If the processes are running, go to Is data getting captured locally? and follow the instructions there.

如果这样做无法解决问题,请尝试以下操作:If this doesn't solve the problem, try to:

  1. 卸载代理Uninstall the agent
  2. 删除目录 C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosticsRemove directory C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics
  3. 重新安装代理Install agent again

部分数据丢失Part of the data is missing

如果获得了部分数据,则表示数据收集/传输管道设置正确。If you are getting some data but not all, it means that the data collection/transfer pipeline is set correctly. 请按照此处的子节说明,缩小问题范围。Follow the subsections here to narrow down the issue.

是否配置了收集?Is the collection configured?

诊断配置包含要收集的特定类型数据的介绍。The Diagnostics configuration contains instructions for a particular type of data to be collected. 查看配置以验证是否仅查找已配置进行收集的数据。Review your configuration to verify that you are only looking for data that you've configured for the collection.

主机是否生成数据?Is the host generating data?

  • 性能计数器:打开 perfmon 并检查计数器。Performance counters: Open perfmon and check the counter.

  • 跟踪日志:远程访问 VM 并向应用的配置文件添加 TextWriterTraceListener。Trace logs: Remote access into the VM and add a TextWriterTraceListener to the app’s config file. 请参阅 https://msdn.microsoft.com/library/sk36c28t.aspx 设置文本侦听器。See https://msdn.microsoft.com/library/sk36c28t.aspx to set up the text listener. 确保 <trace> 元素具有 <trace autoflush="true">Make sure the <trace> element has <trace autoflush="true">.
    如果没有看到生成跟踪日志,请查看“关于跟踪日志丢失的更多信息”。If you don't see trace logs being generated, see More about trace logs missing.

  • ETW 跟踪:远程访问 VM 并安装 PerfView。ETW traces: Remote access into the VM and install PerfView. 在 PerfView 中运行“文件” > “用户命令” > “侦听 etwprovder1” > “etwprovider2”等。In PerfView, run File > User Command > Listen etwprovder1 > etwprovider2, and so on. 侦听命令区分大小写,ETW 提供程序的逗号分隔列表之间不能有空格。The Listen command is case-sensitive, and there cannot be spaces between the comma-separated list of ETW providers. 如果命令未能运行,可选择 Perfview 工具右下角的“日志”按钮,查看尝试运行的内容以及结果。If the command fails to run, you can select the Log button in the bottom right of the Perfview tool to see what attempted to run and what the result was. 假设输入正确,则会弹出一个新窗口。Assuming the input is correct, a new window pops up. 几秒钟后,即可看到 ETW 跟踪信息。In a few seconds, you begin seeing ETW traces.

  • 事件日志:远程访问 VM。Event logs: Remote access into the VM. 打开 Event Viewer确保事件存在。Open Event Viewer, and then ensure that the events exist.

数据是否是本地捕获的?Is data getting captured locally?

接下来,请确保本地捕获到了数据。Next, make sure the data is getting captured locally. 数据本地存储在诊断数据本地存储中的 *.tsf 文件中。The data is locally stored in *.tsf files in the local store for diagnostics data. 不同类型的日志被收集在不同的 .tsf 文件中。Different kinds of logs get collected in different .tsf files. 文件名称与 Azure 存储中的表名相似。The names are similar to the table names in Azure Storage.

例如,Performance Counters 收集在 PerformanceCountersTable.tsf 中。For example, Performance Counters get collected in PerformanceCountersTable.tsf. 事件日志收集在 WindowsEventLogsTable.tsf 中。Event logs get collected in WindowsEventLogsTable.tsf. 使用本地日志提取部分中的说明打开本地收集文件,验证它们是否是在磁盘上收集的。Use the instructions in the Local log extraction section to open the local collection files and verify that you see them getting collected on disk.

如果没有看到在本地收集日志,并且已确认主机正在生成数据,则可能是有配置问题。If you don't see logs getting collected locally, and have already verified that the host is generating data, you likely have a configuration issue. 仔细查看配置。Review your configuration carefully.

还要查看为 MonitoringAgent MaConfig.xml 生成的配置。Also review the configuration that was generated for MonitoringAgent MaConfig.xml. 验证是否存在描述相关日志源的部分。Verify that there is a section that describes the relevant log source. 然后验证该部分是否在诊断配置和监视代理配置间的转换中丢失。Then verify that it is not lost in translation between the Diagnostics configuration and the monitoring agent configuration.

是否传输了数据?Is data getting transferred?

如果已验证数据是本地捕获的,但仍未在存储帐户中看到它,请按以下步骤操作:If you have verified that the data is getting captured locally but you still don't see it in your storage account, take the following steps:

  • 验证提供存储帐户是否正确,且是否有为给定的存储帐户滚动更新过密钥。Verify that you have provided a correct storage account, and that you haven't rolled over keys for the given storage account. 对于 Azure 云服务,有时我们发现人们不更新其 useDevelopmentStorage=trueFor Azure Cloud Services, sometimes we see that people don't update useDevelopmentStorage=true.

  • 验证提供的存储帐户是否正确。Verify that the provided storage account is correct. 确保未受到一些禁止组件访问公共存储终结点的网络限制。Make sure you don't have network restrictions that prevent the components from reaching public storage endpoints. 执行此操作的一种方法是远程访问计算机,自行尝试向相同的存储帐户写入一些内容。One way to do that is to remote access into the machine, and then try to write something to the same storage account yourself.

  • 最后,可并查看监视代理报告的故障。Finally, you can look at what failures are being reported by the monitoring Agent. 监视代理将其日志写入位于诊断数据本地存储中的 maeventtable.tsfThe monitoring agent writes its logs in maeventtable.tsf, which is located in the local store for diagnostics data. 按照本地日志提取部分中的说明打开此文件。Follow the instructions in the Local log extraction section for opening this file. 然后尝试确定是否有 errors 指示读取本地文件或写入存储失败。Then try to determine if there are errors that indicate failures reading to local files writing to storage.

捕获并存档日志Capturing and archiving logs

若打算联系支持人员,他们可能会要求你做的第一件事是从计算机收集日志。If you are thinking about contacting support, the first thing they might ask you is to collect logs from your machine. 可以通过自行收集节省时间。You can save time by doing that yourself. 在日志收集实用程序路径上运行 CollectGuestLogs.exe 实用程序。Run the CollectGuestLogs.exe utility at Log collection utility path. 它会在同一文件夹中生成一个 .zip 文件,其中包含所有相关 Azure 日志。It generates a .zip file with all relevant Azure logs in the same folder.

找不到诊断数据表Diagnostics data tables not found

Azure 存储中保存 ETW 事件的表是使用以下代码命名的:The tables in Azure storage that hold ETW events are named by using the following code:

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

以下是示例:Here is an example:

        <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"
        }
    }
]

此代码生成四个表:This code generates four tables:

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

参考References

如何检查诊断扩展配置How to check Diagnostics extension configuration

检查扩展配置的最简方法是转到 Azure 资源浏览器、再转到 Azure 诊断扩展 (IaaSDiagnostics/PaaDiagnostics) 所在的虚拟机或云服务。The easiest way to check your extension configuration is to go to Azure Resource Explorer, and then go to the virtual machine or cloud service where the Azure Diagnostics extension (IaaSDiagnostics / PaaDiagnostics) is.

或者,通过远程桌面连接到计算机并查看“日志项目路径部分”中所述的 Azure 诊断配置文件。Alternatively, remote desktop into the machine and look at the Azure Diagnostics Configuration file that's described in the Log artifacts path section.

在任何一种情况下,都请先搜索“Microsoft.Azure.Diagnostics”,再搜索“xmlCfg”或“WadCfg”字段。In either case, search for Microsoft.Azure.Diagnostics, and then for the xmlCfg or WadCfg field.

如果在虚拟机上进行搜索,且存在 WadCfg 字段,则表示配置为 JSON 格式。If you're searching on a virtual machine and the WadCfg field is present, it means the config is in JSON format. 如果存在 xmlCfg 字段,则表示配置在 XML 中,且已进行 base64 编码。If the xmlCfg field is present, it means the config is in XML and is base64-encoded. 你需要将其解码才能查看诊断加载的 XML。You need to decode it to see the XML that was loaded by Diagnostics.

对于云服务角色,如果从磁盘选择配置,数据采用 base64 编码,则需要将其解码才能查看诊断加载的 XML。For the cloud service role, if you pick the configuration from disk, the data is base64-encoded, so you need to decode it to see the XML that was loaded by Diagnostics.

Azure 诊断插件退出代码Azure Diagnostics plugin exit codes

该插件返回以下退出代码:The plugin returns the following exit codes:

退出代码Exit code 说明Description
00 成功。Success.
-1-1 常规错误。Generic error.
-2-2 无法加载 rcf 文件。Unable to load the rcf file.

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。This internal error should only happen if the guest agent plugin launcher is manually invoked incorrectly on the VM.

-3-3 无法加载诊断配置文件。Cannot load the Diagnostics configuration file.

解决方案:这是配置文件未通过架构验证的结果。Solution: Caused by a configuration file not passing schema validation. 解决方案是提供符合架构的配置文件。The solution is to provide a configuration file that complies with the schema.

-4-4 监视代理诊断的另一个实例已在使用本地资源目录。Another instance of the monitoring agent Diagnostics is already using the local resource directory.

解决方案:为“LocalResourceDirectory”指定不同的值。Solution: Specify a different value for LocalResourceDirectory.

-6-6 来宾代理插件启动器尝试使用无效的命令行启动诊断。The guest agent plugin launcher attempted to launch Diagnostics with an invalid command line.

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。This internal error should only happen if the guest agent plugin launcher is manually invoked incorrectly on the VM.

-10-10 Diagnostics 插件退出并返回未处理的异常。The Diagnostics plugin exited with an unhandled exception.
-11-11 来宾代理程序无法创建负责启动和监视监视代理的进程。The guest agent was unable to create the process responsible for launching and monitoring the monitoring agent.

解决方案:验证是否有足够的系统资源可用于启动新进程。Solution: Verify that sufficient system resources are available to launch new processes.

-101-101 调用诊断插件时参数无效。Invalid arguments when calling the Diagnostics plugin.

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。This internal error should only happen if the guest agent plugin launcher is manually invoked incorrectly on the VM.

-102-102 插件进程无法初始化自身。The plugin process is unable to initialize itself.

解决方案:验证是否有足够的系统资源可用于启动新进程。Solution: Verify that sufficient system resources are available to launch new processes.

-103-103 插件进程无法初始化自身。The plugin process is unable to initialize itself. 具体而言,它无法创建记录器对象。Specifically, it is unable to create the logger object.

解决方案:验证是否有足够的系统资源可用于启动新进程。Solution: Verify that sufficient system resources are available to launch new processes.

-104-104 无法加载来宾代理提供的 rcf 文件。Unable to load the rcf file provided by the guest agent.

仅当在 VM 上不正确地手动调用了来宾代理插件启动器时,才会发生此内部错误。This internal error should only happen if the guest agent plugin launcher is manually invoked incorrectly on the VM.

-105-105 诊断插件无法打开诊断配置文件。The Diagnostics plugin cannot open the Diagnostics configuration file.

此内部错误应仅当在 VM 上不正确地手动调用了诊断插件时才会发生。This internal error should only happen if the Diagnostics plugin is manually invoked incorrectly on the VM.

-106-106 无法读取诊断配置文件。Cannot read the Diagnostics configuration file.

这是配置文件未通过架构验证的结果。Caused by a configuration file not passing schema validation.

解决方案:提供符合架构的配置文件。Solution: Provide a configuration file that complies with the schema. 有关详细信息,请参阅如何检查诊断扩展配置For more information, see How to check Diagnostics Extension Configuration.

-107-107 传递给监视代理的资源目录无效。The resource directory pass to the monitoring agent is invalid.

此内部错误应仅当在 VM 上不正确地手动调用了监视代理时才会发生。This internal error should only happen if the monitoring agent is manually invoked incorrectly on the VM.

-108-108 无法将诊断配置文件转换为监视代理配置文件。Unable to convert the Diagnostics configuration file into the monitoring agent configuration file.

此内部错误应仅当使用无效的配置文件手动调用了诊断插件时才会发生。This internal error should only happen if the Diagnostics plugin is manually invoked with an invalid configuration file.

-110-110 常规诊断配置错误。General Diagnostics configuration error.

此内部错误应仅当使用无效的配置文件手动调用了诊断插件时才会发生。This internal error should only happen if the Diagnostics plugin is manually invoked with an invalid configuration file.

-111-111 无法启动监视代理。Unable to start the monitoring agent.

解决方案:验证是否有足够的系统资源可用。Solution: Verify that sufficient system resources are available.

-112-112 常规错误General error

本地日志提取Local log extraction

监视代理将日志和项目收集为 .tsf 文件。The monitoring agent collects logs and artifacts as .tsf files. .tsf 文件不可读,但可以将其转换为 .csv,如下所示:The .tsf file is not readable but you can convert it into a .csv as follows:

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

将在与相应 .tsf 文件相同的路径中创建一个名为 <relevantLogFile>.csv 的新文件。A new file called <relevantLogFile>.csv is created in the same path as the corresponding .tsf file.

备注

只需对主 tsf 文件(例如 PerformanceCountersTable.tsf)运行此实用工具。You only need to run this utility against the main .tsf file (for example, PerformanceCountersTable.tsf). 将自动处理随附的文件(例如 PerformanceCountersTables_**001.tsf、PerformanceCountersTables_**002.tsf 等)。The accompanying files (for example, PerformanceCountersTables_**001.tsf, PerformanceCountersTables_**002.tsf, and so on) are automatically processed.

关于跟踪日志丢失的更多信息 More about missing trace logs

备注

以下信息主要适用于 Azure 云服务,除非已在于 IaaS VM 上运行的应用程序上配置了 DiagnosticsMonitorTraceListener。The following information applies mostly to Azure Cloud Services unless you have configured the DiagnosticsMonitorTraceListener on an application that's running on your IaaS VM.

  • 确保在 web.config 或 app.config 中配置了 DiagnosticMonitorTraceListener。这是云服务项目中默认配置的。Make sure the DiagnosticMonitorTraceListener is configured in the web.config or app.config. This is configured by default in cloud service projects. 然而,某些客户将其注释掉了,导致诊断不收集相关跟踪语句。However, some customers comment it out, which causes the trace statements to not be collected by diagnostics.

  • 如果没有从 OnStart 或 Run 方法写入日志,请确保 DiagnosticMonitorTraceListener 位于 app.config 中。默认情况下,它位于 web.config 中,但这仅适用于在 w3wp.exe 中运行的代码。If logs are not getting written from the OnStart or Run method, make sure the DiagnosticMonitorTraceListener is in the app.config. By default it is in the web.config, but that only applies to code running within w3wp.exe. 因此需将其置于 app.config 中,以捕获在 WaIISHost.exe 中运行的跟踪。So you need it in app.config to capture traces that are running in WaIISHost.exe.

  • 确保使用的是 Diagnostics.Trace.TraceXXX,而不是 Diagnostics.Debug.WriteXXXMake sure you are using Diagnostics.Trace.TraceXXX instead of Diagnostics.Debug.WriteXXX. 从发布版本中删除了 Debug 语句。The Debug statements are removed from a release build.

  • 确保已编译的代码实际上具有 Diagnostics.Trace 行(使用反射器、ildasm 或 ILSpy 验证)。Make sure the compiled code actually has the Diagnostics.Trace lines (use Reflector, ildasm, or ILSpy to verify). 从已编译的二进制文件中删除了 Diagnostics.Trace 命令,除非使用 TRACE 条件编译符号。Diagnostics.Trace commands are removed from the compiled binary unless you use the TRACE conditional compilation symbol. 这是使用 msbuild 构建项目时常会发生的问题。This is a common problem that occurs when you're using msbuild to build a project.

已知问题和缓解措施Known issues and mitigations

下面是已知问题和已知缓解措施的列表:Here is a list of known issues with known mitigations:

1. .NET 4.5 依赖项1. .NET 4.5 dependency

Microsoft Azure 诊断扩展对于 .NET 4.5 框架或更高版本存在运行时依赖关系。Windows Azure Diagnostics Extension has a runtime dependency on .NET 4.5 framework or later. 在撰写时,为 Azure 云服务配置的所有计算机以及基于 Azure 虚拟机的所有官方映像都安装了 .NET 4.5 或更高版本。At the time of writing, all machines that are provisioned for Azure Cloud Services, as well as all official images that are based on Azure virtual machines, have .NET 4.5 or later installed.

尝试在未安装 .NET 4.5 或更高版本的计算机上运行 Microsoft Azure 诊断扩展时,仍可能遇到问题。It is still possible encounter a situation where you try to run Windows Azure Diagnostics Extension on a machine that doesn't have .NET 4.5 or later. 从旧映像或快照创建计算机或者自带自定义磁盘时,会发生这种情况。This happens when you create your machine from an old image or snapshot, or when you bring your own custom disk.

这在运行 DiagnosticsPluginLauncher.exe 时通常显示为退出代码 255。This generally manifests as an exit code 255 when running DiagnosticsPluginLauncher.exe. 由以下未经处理的异常引发的故障:Failure happens due to the following unhandled exception:

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 或更高版本。Mitigation: Install .NET 4.5 or later on your machine.

2.性能计数器数据在存储中可用,但不显示在门户中2. Performance counters data is available in storage but not showing in the portal

默认情况下,虚拟机中的门户体验会显示某些性能计数器。The portal experience in the virtual machines shows certain performance counters by default. 如果未看到性能计数器,且知道正在生成数据,因为数据在存储中可用,此时进行以下检查:If you don't see the performance counters, and you know that the data is getting generated because it is available in storage, check the following:

  • 存储中的数据是否有英文计数器名称。Whether the data in storage has counter names in English. 如果计数器名称不是英文,门户指标图表将无法识别它。If the counter names are not in English, the portal metric chart won't able to recognize it. 缓解措施:将系统帐户的计算机语言更改为英语。Mitigation: Change the machine's language to English for system accounts. 要执行此操作,请选择“控制面板” > “区域” > “管理” > “复制设置”。To do this, select Control Panel > Region > Administrative > Copy Settings. 接下来,取消选择“欢迎界面和系统帐户”,以免将自定义语言应用到系统帐户。Next, deselect Welcome screen and system accounts so that the custom language is not applied to the system account.

  • 如果在性能计数器名称中使用通配符 (*),则在将性能计数器发送到 Azure 存储接收器时,门户将无法关联已配置和已收集的计数器。If you are using wildcards (*) in your performance counter names, the portal won't able to correlate the configured and collected counter when the performance counters are sent to the Azure Storage sink. 缓解措施:要确保可以使用通配符并让门户展开 (*),请将性能计数器路由到“Azure Monitor”接收器Mitigation: To make sure you can use wildcards and have the portal expand the (*), route your performance counters to the "Azure Monitor" sink.