监视、诊断和排查Microsoft Azure 存储 (经典)
本指南介绍如何使用 Azure 存储分析、Azure 存储客户端库中的客户端日志记录等功能以及其他第三方工具来识别、诊断和排查与 Azure 存储相关的问题。
本指南主要供使用 Azure 存储服务的联机服务开发人员和负责管理此类联机服务的 IT 专业人员阅读。 本指南的目标是：
- 帮助维护 Azure 存储帐户的运行状况和性能。
- 为你提供必要的流程和工具，帮助你确定应用程序中的问题是否与 Azure 存储相关。
- 提供解决与 Azure 存储相关的问题的可操作指南。
注意
本文基于使用存储分析指标和日志，称为经典指标和日志。 建议使用 Azure Monitor 中的 Azure 存储指标和日志，而不是存储分析日志。 若要了解详细信息，请参阅以下任何文章：
概述
在云环境中托管的分布式应用程序中诊断和故障排除问题可能比在传统环境中更复杂。 应用程序可以部署在 PaaS 或 IaaS 基础结构中、本地、移动设备上或这些环境的某种组合中。 通常，应用程序的网络流量可能遍历公用和专用网络，并且应用程序可以使用多种存储技术，例如Microsoft Azure 存储表、Blob、队列或文件，以及关系数据库和文档数据库等其他数据存储。
若要成功管理此类应用程序，应主动监视它们，并了解如何诊断和排查这些应用程序及其依赖技术的各个方面。 作为 Azure 存储服务的用户，应持续监视应用程序使用的存储服务，以了解行为 (的任何意外更改，例如) 响应时间比平常慢，并使用日志记录来收集更详细的数据并深入分析问题。 从监视和日志记录中获取的诊断信息将帮助你确定应用程序遇到的问题的根本原因。 然后，你可以对问题进行故障排除，并确定修正该问题的适当步骤。 Azure 存储是一项核心 Azure 服务，是客户部署到 Azure 基础结构的大多数解决方案的重要组成部分。 Azure 存储包括用于简化基于云的应用程序中存储问题的监视、诊断和故障排除的功能。
本指南的组织方式
监视存储服务部分介绍如何使用 Azure 存储分析 指标 (存储指标) 监视 Azure 存储服务的运行状况和性能。
诊断存储问题部分介绍如何使用 Azure 存储分析日志记录 (存储日志记录) 诊断问题。 此外，还介绍了如何使用其中一个客户端库中的工具（例如用于 .NET 的存储客户端库或用于 Java 的 Azure SDK）启用客户端日志记录。
端到端跟踪部分介绍如何关联各种日志文件和指标数据中包含的信息。
故障排除指南部分提供有关可能会遇到的一些常见存储相关问题的故障排除指南。
Appendices 部分包含有关使用其他工具的信息，例如 Wireshark 和 Netmon 用于分析网络数据包数据，以及 Fiddler 用于分析 HTTP/HTTPS 消息的信息。
监视存储服务
如果熟悉 Windows 性能监视，则可以将存储指标视为与 Windows 性能监视器 计数器等效的 Azure 存储。 在存储指标中，可以在 Windows 性能监视器术语) 中找到一组全面的指标 (计数器，例如服务可用性、服务请求总数或成功请求的百分比。 有关可用指标的完整列表，请参阅存储分析指标表架构。 可以指定是希望存储服务每小时还是每分钟收集和聚合指标。 有关如何启用指标和监视存储帐户的详细信息，请参阅 启用存储指标和查看指标数据。
你可以选择要在Azure 门户中显示的每小时指标，并配置规则，每当每小时指标超过特定阈值时通过电子邮件通知管理员。 有关详细信息，请参阅 接收警报通知。
建议查看 Azure Monitor for Storage (预览版) 。 它是 Azure Monitor 的一项功能，通过提供 Azure 存储服务性能、容量和可用性的统一视图，提供对 Azure 存储帐户的全面监视。 它不需要启用或配置任何内容，并且可以立即从预定义的交互式图表和包含的其他可视化效果中查看这些指标。
存储服务会尽力收集指标，但可能不会记录每个存储操作。
在Azure 门户中，可以查看存储帐户的可用性、请求总数和平均延迟数等指标。 还设置了通知规则，以在可用性低于特定级别时向管理员发出警报。 查看此数据后，一个可能的调查区域是表服务成功百分比低于 100% (有关详细信息，请参阅 指标显示低 PercentSuccess 或分析日志条目具有 ClientOtherErrors 事务状态的操作 部分) 。
应持续监视 Azure 应用程序，确保它们正常运行，并按预期运行：：
- 为应用程序建立一些基线指标，使你能够比较当前数据，并确定 Azure 存储和应用程序行为的任何重大更改。 在许多情况下，基线指标的值将特定于应用程序，应在测试应用程序的性能时建立它们。
- 记录分钟指标并使用它们主动监视意外错误和异常，例如错误计数或请求率的峰值。
- 记录每小时指标，并使用它们监视平均值，例如平均错误计数和请求率。
- 使用诊断工具调查潜在问题，如后面的诊断存储问题部分所述。
下图中的图表说明了每小时指标的平均值如何隐藏活动的峰值。 每小时指标显示稳定的请求速率，而分钟指标显示实际发生的波动。
本部分的其余部分介绍了应监视的指标以及原因。
监视服务运行状况
可以使用Azure 门户查看存储服务 (和其他 Azure 服务) 在全球所有 Azure 区域中的运行状况。 通过监视，可以立即查看无法控制的问题是否正在影响用于应用程序的区域中的存储服务。
Azure 门户还可以提供影响各种 Azure 服务的事件通知。
注意
此信息和历史数据以前在 Azure 服务仪表板上可用。 有关适用于 Azure DevOps 的 Application Insights 的详细信息，请参阅 附录 5：使用适用于 Azure DevOps 的 Application Insights 进行监视。
监视容量
存储指标仅存储 Blob 服务的容量指标，因为 blob 在写入时通常占存储数据 (的最大比例，因此无法使用存储指标来监视表和队列) 的容量。 如果为 Blob 服务启用了监视，则可以在 $MetricsCapacityBlob 表中找到此数据。 存储指标每天记录一次此数据，可以使用 的值 RowKey 来确定该行是否包含与用户数据相关的实体 (值 data) 或分析数据 (值 analytics) 。 每个存储实体都包含有关 (以字节) Capacity 度量的已用存储量以及存储帐户中 () ) 和 blob ObjectCount 的当前 (ContainerCount 容器数的信息。 有关表中存储$MetricsCapacityBlob的容量指标的详细信息，请参阅存储分析指标表架构。
注意
应监视这些值，以提前警告你即将达到存储帐户的容量限制。 在Azure 门户，可以添加警报规则，以便在聚合存储使用量超过或低于指定的阈值时通知你。
若要估计各种存储对象（如 Blob）的大小，请参阅博客文章 了解 Azure 存储计费 - 带宽、事务和容量。
监视可用性
应监视存储帐户中存储服务的可用性，方法是监视每小时或分钟指标表中列中的值 Availability ，例如 、$MetricsHourPrimaryTransactionsBlob、$MetricsHourPrimaryTransactionsTable、$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsBlob、$MetricsMinutePrimaryTransactionsTable$MetricsMinutePrimaryTransactionsQueue、。 $MetricsCapacityBlob 列 Availability 包含一个百分比值，该值指示服务的可用性或由行表示的 API 操作的可用性， (RowKey 显示行是否包含整个服务或特定 API 操作的指标) 。
任何小于 100% 的值都表示某些存储请求失败。 可以通过检查指标数据中的其他列来了解失败的原因，这些列显示具有不同错误类型的请求数，例如 ServerTimeoutError。 在服务移动分区以更好地对请求进行负载均衡时，预期 Availability 会出现暂时低于 100% 的原因，例如暂时性服务器超时;客户端应用程序中的重试逻辑应处理此类间歇性情况。 存储分析记录的操作和状态消息一文列出了存储指标在其Availability计算中包括的事务类型。
在Azure 门户中，可以添加警报规则，以便在服务低于指定的阈值时Availability通知你。
本指南的 故障排除指南 部分介绍了一些与可用性相关的常见存储服务问题。
监视性能
若要监视存储服务的性能，可以使用每小时和分钟指标表中的以下指标。
- 和
AverageServerLatency列中的值AverageE2ELatency显示存储服务或 API 操作类型处理请求的平均时间。AverageE2ELatency是端到端延迟的度量，包括读取请求和发送响应所花费的时间，以及处理请求所花费的时间 (因此包括请求到达存储服务后的网络延迟) ;AverageServerLatency只是处理时间的度量值，因此排除与客户端通信相关的任何网络延迟。 请参阅本指南后面的 指标显示高 AverageE2ELatency 和低 AverageServerLatency 部分，了解为什么这两个值之间可能存在显著差异。 - 和
TotalEgress列中的值TotalIngress显示传入和传出存储服务或通过特定 API 操作类型传入和传出的数据总量（以字节为单位）。 - 列中的值
TotalRequests显示 API 操作的存储服务收到的请求总数。TotalRequests是存储服务接收的请求总数。
通常，你将监视这些值中的任何一个的意外更改，因为这表示存在需要调查的问题。
在Azure 门户，可以添加警报规则，以便在此服务的任何性能指标低于或超过指定的阈值时发出通知。
本指南的 故障排除指南 部分介绍了一些与性能相关的常见存储服务问题。
诊断存储问题
可以通过多种方式了解应用程序中的问题，包括：
- 导致应用程序崩溃或停止工作的重大故障。
- 与要监视的指标中的基线值相比发生了重大更改，如上一节 监视存储服务中所述。
- 应用程序用户报告某些特定操作未按预期完成或某些功能不起作用。
- 应用程序中生成的错误显示在日志文件中或通过某些其他通知方法显示。
通常，与 Azure 存储服务相关的问题分为四大类之一：
- 应用程序存在性能问题，由用户报告或性能指标更改显示。
- 一个或多个区域中的 Azure 存储基础结构存在问题。
- 应用程序遇到错误，由用户报告，或者由监视的错误计数指标之一增加所显示。
- 在开发和测试期间，你可能正在使用本地存储模拟器;可能会遇到一些专门与存储模拟器的使用相关的问题。
以下部分概述了诊断和排查这四个类别中每个类别的问题时应遵循的步骤。 本指南后面的 故障排除指南 部分提供了你可能会遇到的一些常见问题的更多详细信息。
服务运行状况问题
服务运行状况问题通常不受控制。 Azure 门户提供有关 Azure 服务（包括存储服务）的任何持续问题的信息。 如果在创建存储帐户时选择了 Read-Access Geo-Redundant 存储，则如果数据在主要位置不可用，应用程序可以暂时切换到辅助位置中的只读副本。 若要从辅助数据库读取数据，应用程序必须能够在使用主存储位置和辅助存储位置之间切换，并且能够使用只读数据在缩减功能模式下工作。 使用 Azure 存储客户端库可以定义重试策略，以便在从主存储读取失败时从辅助存储进行读取。 应用程序还需要注意辅助位置中的数据最终一致。 有关详细信息，请参阅博客文章 Azure 存储冗余选项和读取访问异地冗余存储。
性能问题
应用程序的性能可能是主观的，尤其是从用户的角度来看。 因此，请务必提供基线指标，以帮助确定可能存在性能问题的位置。 从客户端应用程序的角度来看，许多因素可能会影响 Azure 存储服务的性能。 这些因素可能在存储服务、客户端或网络基础结构中运行;因此，必须制定一个策略来识别性能问题的来源。
从指标中确定性能问题原因的可能位置后，可以使用日志文件查找详细信息，以进一步诊断和排查问题。
本指南后面的 故障排除指南 部分提供了有关可能会遇到的一些常见性能相关问题的详细信息。
诊断错误
应用程序的用户可能会通知客户端应用程序报告的错误。 存储指标还记录存储服务中不同错误类型的计数，例如 NetworkError、ClientTimeoutError 或 AuthorizationError。 虽然存储指标仅记录不同错误类型的计数，但可以通过检查服务器端、客户端和网络日志来获取有关各个请求的更多详细信息。 通常，存储服务返回的 HTTP 状态代码会指示请求失败的原因。
注意
请记住，应会看到一些间歇性错误：例如，暂时性网络条件导致的错误或应用程序错误。
以下资源有助于了解与存储相关的状态和错误代码：
存储模拟器问题
Azure SDK 包括可在开发工作站上运行的存储模拟器。 此模拟器模拟 Azure 存储服务的大部分行为，在开发和测试期间非常有用，使你能够运行使用 Azure 存储服务的应用程序，而无需 Azure 订阅和 Azure 存储帐户。
本指南的 故障排除指南 部分介绍了使用存储模拟器时遇到的一些常见问题。
存储日志记录工具
存储日志记录提供 Azure 存储帐户中存储请求的服务器端日志记录。 有关如何启用服务器端日志记录和访问日志数据的详细信息，请参阅 启用存储日志记录和访问日志数据。
使用适用于 .NET 的存储客户端库可以收集与应用程序执行的存储操作相关的客户端日志数据。 有关详细信息，请参阅 使用 .NET 存储客户端库进行客户端日志记录。
注意
在某些情况下， (（例如 SAS 授权失败) ），用户可能会报告一个错误，你可以在服务器端存储日志中找不到请求数据。 可以使用存储客户端库的日志记录功能来调查问题的原因是否在客户端上，或使用网络监视工具来调查网络。
使用网络日志记录工具
可以捕获客户端和服务器之间的流量，以提供有关客户端和服务器正在交换的数据以及基础网络条件的详细信息。 有用的网络日志记录工具包括：
- Fiddler 是一个免费的 Web 调试代理，可用于检查 HTTP 和 HTTPS 请求和响应消息的标头和有效负载数据。 有关详细信息，请参阅 附录 1：使用 Fiddler 捕获 HTTP 和 HTTPS 流量。
- Microsoft 网络监视器 (Netmon) 和 Wireshark 是免费的网络协议分析器，可用于查看各种网络协议的详细数据包信息。 有关 Wireshark 的详细信息，请参阅 附录 2：使用 Wireshark 捕获网络流量。
- 如果要对客户端计算机可以通过网络连接到 Azure 存储服务的检查执行基本连接测试，则无法使用客户端上的标准 ping 工具执行此操作。 但是，可以使用 tcping 工具来检查连接。
在许多情况下，来自存储日志记录和存储客户端库的日志数据足以诊断问题，但在某些情况下，可能需要这些网络日志记录工具可以提供的更详细信息。 例如，使用 Fiddler 查看 HTTP 和 HTTPS 消息，可以查看发送到存储服务或从存储服务发送的标头和有效负载数据，这使你能够检查客户端应用程序如何重试存储操作。 Wireshark 等协议分析器在数据包级别运行，使你能够查看 TCP 数据，从而排查数据包丢失和连接问题。
端到端跟踪
使用各种日志文件的端到端跟踪是调查潜在问题的有用技术。 可以使用指标数据中的日期/时间信息来指示在日志文件中查找详细信息的位置，以帮助排查问题。
关联日志数据
查看来自客户端应用程序、网络跟踪和服务器端存储日志记录的日志时，能够跨不同日志文件关联请求至关重要。 日志文件包含许多用作相关标识符的不同字段。 客户端请求 ID 是用于关联不同日志中的条目的最有用的字段。 但是，有时，使用服务器请求 ID 或时间戳可能很有用。 以下部分提供有关这些选项的更多详细信息。
客户端请求 ID
存储客户端库为每个请求自动生成唯一的客户端请求 ID。
- 在存储客户端库创建的客户端日志中，客户端请求 ID 显示在
Client Request ID与请求相关的每个日志条目的 字段中。 - 在网络跟踪（例如 Fiddler 捕获的网络跟踪）中，客户端请求 ID 在请求消息中显示为
x-ms-client-request-idHTTP 标头值。 - 在服务器端存储日志记录日志中，客户端请求 ID 显示在“客户端请求 ID”列中。
注意
多个请求可能会共享相同的客户端请求 ID，因为客户端可以分配此值 (尽管存储客户端库) 自动分配新值。 客户端重试时，所有尝试共享相同的客户端请求 ID。 对于从客户端发送的批处理，该批具有单个客户端请求 ID。
服务器请求 ID
存储服务自动生成服务器请求 ID。
- 在服务器端存储日志记录日志中，服务器请求 ID 显示在 列中
Request ID header。 - 在网络跟踪（例如 Fiddler 捕获的网络跟踪）中，服务器请求 ID 在响应消息中显示为
x-ms-request-idHTTP 标头值。 - 在存储客户端库创建的客户端日志中，服务器请求 ID 显示在
Operation Text日志条目的 列中，其中显示了服务器响应的详细信息。
注意
存储服务始终为其接收的每个请求分配唯一的服务器请求 ID，因此客户端的每个重试尝试和批处理中包含的每个操作都具有唯一的服务器请求 ID。
下面的代码示例演示如何使用自定义客户端请求 ID。
var connectionString = Constants.connectionString;
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");
BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");
string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());
using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
BlobDownloadInfo download = blobClient.Download();
using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
{
download.Content.CopyTo(downloadFileStream);
downloadFileStream.Close();
}
}
时间 戳
还可以使用时间戳来查找相关的日志条目，但请注意客户端和服务器之间可能存在的任何时钟偏差。 对于基于客户端时间戳的匹配服务器端条目，搜索加/减 15 分钟。 请记住，包含指标的 Blob 的 Blob 元数据指示 Blob 中存储的指标的时间范围。 如果同一分钟或小时有多个指标 Blob，则此时间范围非常有用。
疑难解答指南
本部分将帮助你诊断和排查应用程序在使用 Azure 存储服务时可能遇到的一些常见问题。 使用以下列表查找与特定问题相关的信息。
故障排除决策树
你的问题是否与其中一个存储服务的性能有关？
- 指标显示高 AverageE2ELatency 和低 AverageServerLatency。
- 指标显示 AverageE2ELatency 低和 AverageServerLatency 低，但客户端遇到高延迟。
- 指标显示高 AverageServerLatency。
- 队列上的消息传递出现意外延迟。
你的问题是否与其中一个存储服务的可用性有关？
客户端应用程序是否从存储服务接收 HTTP 4XX (（例如 404) 响应）？
指标显示低 PercentSuccess 或分析日志条目具有事务状态为 ClientOtherErrors 的操作。
安装适用于 .NET 的 Azure SDK 时遇到问题。
指标显示高 AverageE2ELatency 和低 AverageServerLatency
Azure 门户监视工具的下图显示了一个示例，其中 AverageE2ELatency 明显高于 AverageServerLatency。
存储服务仅计算成功请求的指标 AverageE2ELatency ，与 AverageServerLatency 不同，包括客户端发送数据并从存储服务接收确认所花费的时间。 因此， AverageE2ELatency 和 AverageServerLatency 之间的差异可能是由于客户端应用程序响应速度缓慢或网络条件所致。
注意
还可以在存储日志记录日志数据中查看单个存储操作的 E2ELatency 和 ServerLatency 。
调查客户端性能问题
客户端响应缓慢的可能原因包括可用连接或线程数有限，或者 CPU、内存或网络带宽等资源不足。 可以通过将客户端代码修改为更高效 (来解决此问题，例如，使用对存储服务) 的异步调用，或者使用具有更多核心和更多内存的较大虚拟机 () 。
对于表和队列服务，与 AverageServerLatency 相比，Nagle 算法还会导致 AverageE2ELatency 较高。 有关详细信息，请参阅 Nagle 的算法对小型请求不友好。 可以使用 命名空间中的 类在代码 ServicePointManager 中 System.Net 禁用 Nagle 算法。 在对应用程序中的表或队列服务进行任何调用之前，应执行此操作，因为这不会影响已打开的连接。 以下示例来自 Application_Start 辅助角色中的 方法。
var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;
应检查客户端日志，以查看客户端应用程序提交的请求数，并针对常规 检查。客户端中与 NET 相关的性能瓶颈，例如 CPU、.NET 垃圾回收、网络利用率或内存。 作为对 .NET 客户端应用程序进行故障排除的起点，请参阅 调试、跟踪和分析。
调查网络延迟问题
通常，网络导致的高端到端延迟是由于暂时性条件导致的。 可以使用 Wireshark 等工具调查暂时性和持久性网络问题，例如丢弃的数据包。
有关使用 Wireshark 排查网络问题的详细信息，请参阅 附录 2：使用 Wireshark 捕获网络流量。
指标显示低 AverageE2ELatency 和低 AverageServerLatency，但客户端遇到高延迟
在此方案中，最可能的原因是到达存储服务的存储请求出现延迟。 应调查来自客户端的请求未通过 Blob 服务的原因。
客户端延迟发送请求的一个可能原因是可用连接或线程数有限。
此外，检查客户端是否正在执行多次重试，并调查原因（如果是）。 若要确定客户端是否正在执行多次重试，可以：
- 检查存储分析日志。 如果发生多次重试，则会看到多个操作具有相同的客户端请求 ID，但服务器请求 ID 不同。
- 检查客户端日志。 详细日志记录将指示已重试。
- 调试代码，并检查与请求关联的对象的属性
OperationContext。 如果重试了操作，则RequestResults属性将包含多个唯一的服务器请求 ID。 还可以检查每个请求的开始时间和结束时间。 有关详细信息，请参阅 服务器请求 ID 部分中的代码示例。
如果客户端中没有任何问题，则应调查潜在的网络问题，例如数据包丢失。 可以使用 Wireshark 等工具来调查网络问题。
有关使用 Wireshark 排查网络问题的详细信息，请参阅 附录 2：使用 Wireshark 捕获网络流量。
指标显示高 AverageServerLatency
如果 Blob 下载请求的 AverageServerLatency 较高 ，应使用存储日志记录日志来查看是否重复请求同一 blob (或 blob 集) 。 对于 Blob 上传请求，应调查客户端使用的块大小 (例如，大小小于 64 K 的块可能会导致开销，除非读取的区块也少于 64 K 个区块) 并且多个客户端并行将块上传到同一 Blob。 还应检查导致超过每秒可伸缩性目标的请求数峰值的每分钟指标。 有关详细信息，请参阅 Metrics show an increase in PercentTimeoutError。
如果在对同一 Blob 或一组 blob 重复请求时看到 Blob 下载请求的 AverageServerLatency 较高，请考虑使用 Azure 缓存或 Azure 内容分发网络 (CDN) 缓存这些 blob。 对于上传请求，可以使用更大的块大小来提高吞吐量。 对于对表的查询，还可以在执行相同查询操作且数据不经常更改的客户端上实现客户端缓存。
AverageServerLatency 值过高也可能是设计不佳的表或查询的症状，这些表或查询会导致扫描操作或遵循追加/追加反模式。 有关详细信息，请参阅 Metrics show an increase in PercentThrottlingError。
注意
可在此处找到全面的性能清单：Microsoft Azure 存储性能和可伸缩性清单。
队列上的消息传递出现意外延迟
如果在应用程序将消息添加到队列的时间与可从队列中读取消息的时间之间遇到延迟，请执行以下步骤来诊断问题：
- 验证应用程序是否成功将消息添加到队列。 在成功之前，请检查应用程序是否未多次重试
AddMessage方法。 存储客户端库日志将显示存储操作的任何重复重试。 - 验证将消息添加到队列的辅助角色与从队列中读取消息的辅助角色之间没有时钟偏差。 时钟倾斜会使处理出现延迟。
- 检查从队列中读取消息的辅助角色是否失败。 如果队列客户端调用 方法，
GetMessage但无法通过确认做出响应，则消息将在队列中保持不可见状态，invisibilityTimeout直到期限到期。 此时，消息将再次可供处理。 - 检查队列长度是否随时间而增长。 如果没有足够的辅助角色可用于处理其他辅助角色正在队列中放置的所有消息，则可能会发生这种情况。 此外，检查指标，以查看删除请求是否失败，以及消息的取消排队计数，这可能指示尝试删除消息的重复失败。
- 检查存储日志记录日志，了解 E2ELatency 和 ServerLatency 值在比平常更长的时间内高于预期的任何队列操作。
指标显示 PercentThrottlingError 的增加
超出存储服务的可伸缩性目标时，会发生限制错误。 存储服务会受到限制，以确保任何客户端或租户都不能以牺牲其他客户端或租户为代价使用该服务。 有关详细信息，请参阅 标准存储帐户的可伸缩性和性能目标 ，详细了解存储帐户的可伸缩性目标和存储帐户中分区的性能目标。
如果 PercentThrottlingError 指标显示失败并出现限制错误的请求百分比增加，则需要调查以下两种方案之一：
PercentThrottlingError 的增加通常与存储请求数的增加同时发生，或者最初对应用程序进行负载测试时发生。 这也可能在客户端中显示为存储操作中的“503 服务器繁忙”或“500 操作超时”HTTP 状态消息。
PercentThrottlingError 的暂时性增加
如果发现 PercentThrottlingError 的值峰值与应用程序的高活动时段相吻合，则可以在客户端中实现指数 (而不是线性) 回退策略。 回退重试可减少分区上的即时负载，并帮助应用程序消除流量高峰。 有关如何使用存储客户端库实现重试策略的详细信息，请参阅 Microsoft.Azure.Storage.RetryPolicies 命名空间。
注意
还可能会看到 PercentThrottlingError 值中的峰值，这些峰值与应用程序的高活动时段不一致。 最有可能的原因是存储服务移动分区以改进负载均衡。
PercentThrottlingError 的永久增加
如果在事务量永久增加或对应用程序执行初始负载测试时 ，PercentThrottlingError 始终高值，则需要评估应用程序如何使用存储分区，以及它是否接近存储帐户的可伸缩性目标。 例如，如果看到队列 (限制错误，该错误计数为单个分区) ，请考虑使用其他队列将事务分散到多个分区。 如果看到表出现限制错误，则需要考虑使用不同的分区方案，通过使用更广泛的分区键值将事务分散到多个分区。 此问题的一个常见原因是前追加/追加反模式，在该模式中，选择日期作为分区键，然后将特定日期的所有数据写入一个分区：在负载下，这可能会导致写入瓶颈。 考虑不同的分区设计，或评估使用 Blob 存储是否是更好的解决方案。 此外，检查是否由于流量高峰而发生限制，并调查平滑请求模式的方法。
如果跨多个分区分发事务，则仍必须了解为存储帐户设置的可伸缩性限制。 例如，如果使用了 10 个队列，每个队列每秒最多处理 2,000 个 1KB 消息，则存储帐户的总限制为每秒 20,000 条消息。 如果需要每秒处理超过 20,000 个实体，请考虑使用多个存储帐户。 还应记住，请求和实体的大小会影响存储服务何时限制客户端。 如果请求和实体较大，可能会更早地受到限制。
低效的查询设计还可能导致你达到表分区的可伸缩性限制。 例如，具有筛选器的查询仅选择分区中实体的 1%，但扫描分区中的所有实体需要访问每个实体。 每个实体读取都将计入该分区中的事务总数;因此，可以轻松达到可伸缩性目标。
注意
性能测试应显示应用程序中任何低效的查询设计。
指标显示 PercentTimeoutError 的增加
指标显示其中一项存储服务的 PercentTimeoutError 有所增加。 同时，客户端从存储操作接收大量“500 操作超时”HTTP 状态消息。
注意
存储服务通过将分区移动到新服务器来对请求进行负载均衡时，可能会暂时看到超时错误。
PercentTimeoutError 指标是以下指标的聚合：ClientTimeoutError、AnonymousClientTimeoutError、SASClientTimeoutError、ServerTimeoutError、AnonymousServerTimeoutError 和 SASServerTimeoutError。
服务器超时是由服务器上的错误引起的。 客户端超时是因为服务器上的操作已超过客户端指定的超时;例如，使用存储客户端库的客户端可以使用 类的 QueueRequestOptions 属性为操作ServerTimeout设置超时。
服务器超时表示存储服务存在问题，需要进一步调查。 可以使用指标来查看是否达到了服务的可伸缩性限制，并确定可能导致此问题的任何流量高峰。 如果问题是间歇性的，则可能是由于服务中的负载均衡活动造成的。 如果问题持续存在，并且不是由应用程序达到服务的可伸缩性限制引起的，则应引发支持问题。 对于客户端超时，你必须决定超时是否在客户端中设置为适当的值，并更改在客户端中设置的超时值，或者调查如何改进存储服务中操作的性能，例如，通过优化表查询或减小消息的大小。
指标显示 PercentNetworkError 的增加
指标显示其中一项存储服务的 PercentNetworkError 增加。 PercentNetworkError 指标是以下指标的聚合：NetworkError、AnonymousNetworkError 和 SASNetworkError。 当存储服务在客户端发出存储请求时检测到网络错误时，会发生这些错误。
此错误的最常见原因是客户端在存储服务超时到期前断开连接。 调查客户端中的代码，了解客户端与存储服务断开连接的原因和时间。 还可以使用 Wireshark 或 Tcping 调查来自客户端的网络连接问题。 这些工具在附录中介绍。
客户端正在接收 HTTP 403 (禁止) 消息
如果客户端应用程序引发 HTTP 403 (禁止) 错误，则可能原因是客户端在发送存储请求时使用过期的共享访问签名 (SAS () ，尽管其他可能的原因包括时钟偏差、无效密钥和空标头) 。 如果导致 SAS 密钥过期，则不会在服务器端存储日志记录日志数据中看到任何条目。 下表显示了存储客户端库生成的客户端日志示例，其中说明了此问题的发生：
| Source | 冗长 | 冗长 | 客户端请求 ID | 操作文本 |
|---|---|---|---|---|
| Microsoft.Azure.Storage | Information | 3 | 85d077ab-... | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -... | Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -... | Waiting for response. |
| Microsoft.Azure.Storage | 警告 | 2 | 85d077ab -... | Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -... | Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = . |
| Microsoft.Azure.Storage | 警告 | 2 | 85d077ab -... | Exception thrown during the operation: The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -... | Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -... | The next location has been set to Primary, based on the location mode. |
| Microsoft.Azure.Storage | 错误 | 1 | 85d077ab -... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden. |
在此方案中，应在客户端将令牌发送到服务器之前调查 SAS 令牌过期的原因：
- 通常，创建可供客户端立即使用的 SAS 时，不应设置开始时间。 如果使用当前时间生成 SAS 的主机与存储服务之间的时钟差异很小，则存储服务可能会收到尚无效的 SAS。
- 不要在 SAS 上设置非常短的到期时间。 同样，生成 SAS 的主机与存储服务之间的小时钟差异可能会导致 SAS 似乎比预期更早过期。
- SAS 密钥中的 version 参数 (例如
sv=2015-04-05) 是否与正在使用的存储客户端库的版本匹配？ 建议始终使用最新版本的 存储客户端库。 - 如果重新生成存储访问密钥，则任何现有的 SAS 令牌都可能失效。 如果为客户端应用程序缓存而生成过期时间较长的 SAS 令牌，则可能会出现此问题。
如果使用存储客户端库生成 SAS 令牌，则很容易生成有效的令牌。 但是，如果使用存储 REST API 并手动构造 SAS 令牌，请参阅 使用共享访问签名委派访问。
客户端正在接收 HTTP 404 (找不到) 消息
如果客户端应用程序从服务器收到 HTTP 404 (找不到) 消息，这意味着存储服务中不存在客户端尝试使用 (的对象，例如实体、表、Blob、容器或队列) 。 有多种可能的原因，例如：
客户端或其他进程之前删除了 对象
在客户端尝试读取、更新或删除存储服务中的数据的情况下，通常很容易在服务器端日志中识别先前从存储服务中删除了有关对象的操作。 通常，日志数据显示其他用户或进程删除了对象。 在服务器端存储日志记录日志中，操作类型和 requested-object-key 列显示客户端删除对象时。
在客户端尝试插入对象的情况下，鉴于客户端正在创建新对象，导致 HTTP 404 (找不到) 响应的原因可能并不明显。 但是，如果客户端正在创建 Blob，它必须能够找到 Blob 容器。 如果客户端正在创建消息，它必须能够找到队列。 如果客户端要添加行，它必须能够找到表。
可以使用存储客户端库中的客户端日志来更详细地了解客户端何时向存储服务发送特定请求。
存储客户端库生成的以下客户端日志说明了当客户端找不到它正在创建的 Blob 的容器时出现的问题。 此日志包括以下存储操作的详细信息：
| 请求 ID | 操作 |
|---|---|
| 07b26a5d-... | DeleteIfExists 用于删除 Blob 容器的 方法。 请注意，此操作包括针对HEAD容器存在检查的请求。 |
| e2d06d78... | CreateIfNotExists 方法，用于创建 Blob 容器。 请注意，此操作包括一个 HEAD 请求，用于检查容器是否存在。 返回 HEAD 404 消息，但会继续。 |
| de8b1c3c-... | UploadFromStream 创建 Blob 的 方法。 请求 PUT 失败并显示 404 消息。 |
日志条目：
| 请求 ID | 操作文本 |
|---|---|
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B". |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = . |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | Preparing to write request data. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| e2d06d78-... | Downloading response body. |
| e2d06d78-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Writing request data. |
| de8b1c3c-... | Waiting for response. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (409) Conflict.. |
| e2d06d78-... | Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Downloading error response body. |
| de8b1c3c-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = . |
| de8b1c3c-... | Exception thrown during the operation: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict.. |
在此示例中，日志显示客户端正在交错来自 CreateIfNotExists 方法的请求 (请求 ID e2d06d78...) 方法 UploadFromStream (de8b1c3c-...) 。由于客户端应用程序异步调用这些方法，因此会发生这种交错。 修改客户端中的异步代码，以确保在尝试将任何数据上传到该容器中的 Blob 之前创建容器。 理想情况下，应提前创建所有容器。
共享访问签名 (SAS) 授权问题
如果客户端应用程序尝试使用不包含操作所需权限的 SAS 密钥，存储服务会向客户端返回 HTTP 404 (“找不到”) 消息。 同时，还会在指标中看到 非零值 SASAuthorizationError 。
下表显示了存储日志记录日志文件中的服务器端日志消息示例：
| 名称 | 值 |
|---|---|
| 请求开始时间 | 2014-05-30T06：17：48.4473697Z |
| 操作类型 | GetBlobProperties |
| 请求状态 | SASAuthorizationError |
| HTTP 状态代码 | 404 |
| 身份验证类型 | Sas |
| 服务类型 | Blob |
| 请求 URL | https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt |
| ？sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&;api-version=2014-02-14 | |
| 请求 ID 标头 | <请求 ID 标头> |
| 客户端请求 ID | <客户端请求 ID> |
调查客户端应用程序尝试执行未向其授予权限的操作的原因。
客户端 JavaScript 代码没有访问对象的权限
如果使用 JavaScript 客户端，并且存储服务返回 HTTP 404 消息，检查浏览器中的以下 JavaScript 错误：
SEC7120： http://localhost:56309 Access-Control-Allow-Origin 标头中找不到源。
SCRIPT7002：XMLHttpRequest：网络错误0x80070005，访问被拒绝。
注意
在排查客户端 JavaScript 问题时，可以使用 Internet Explorer 中的 F12 开发人员工具跟踪浏览器与存储服务之间交换的消息。
发生这些错误的原因是 Web 浏览器实现了 相同的源策略 安全限制，该限制阻止网页从页面所在的域调用不同域中的 API。
若要解决 JavaScript 问题，可以为客户端正在访问的存储服务配置跨源资源共享 (CORS) 。 有关详细信息，请参阅 跨源资源共享 (CORS) Azure 存储服务支持。
以下代码示例演示如何配置 Blob 服务，以允许在 Contoso 域中运行的 JavaScript 访问 Blob 存储服务中的 Blob：
var connectionString = Constants.connectionString;
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobServiceProperties sp = blobServiceClient.GetProperties();
// Set the service properties.
sp.DefaultServiceVersion = "2013-08-15";
BlobCorsRule bcr = new BlobCorsRule();
bcr.AllowedHeaders = "*";
bcr.AllowedMethods = "GET,POST";
bcr.AllowedOrigins = "http://www.contoso.com";
bcr.ExposedHeaders = "x-ms-*";
bcr.MaxAgeInSeconds = 5;
sp.Cors.Clear();
sp.Cors.Add(bcr);
blobServiceClient.SetProperties(sp);
网络故障
在某些情况下，丢失的网络数据包可能会导致存储服务将 HTTP 404 消息返回到客户端。 例如，当客户端应用程序从表服务中删除实体时，会看到客户端从表服务引发存储异常，报告“HTTP 404 (找不到) ”状态消息。 调查表存储服务中的表时，会看到该服务确实按照请求删除了实体。
客户端中的异常详细信息包括表服务为请求分配的请求 ID (7e84f12d...) 。 可以使用此信息通过在日志文件的 列中搜索 request-id-header 来查找服务器端存储日志中的请求详细信息。 还可以使用指标来确定何时发生此类故障，然后根据指标记录此错误的时间搜索日志文件。 此日志条目显示删除失败，并显示“HTTP (404) 客户端其他错误”状态消息。 同一日志条目还包括客户端在 client-request-id (813ea74f...) 列中生成的请求 ID。
服务器端日志还包括另一个具有相同值的条目 client-request-id (813ea74f...) ，用于对同一实体和同一客户端成功执行删除操作。 此成功的删除操作发生在失败的删除请求之前不久。
这种情况的最可能原因是客户端向表服务发送了实体的删除请求，该请求成功但未收到来自服务器的确认 (可能是由于) 的临时网络问题。 然后，客户端使用相同的) 自动重试操作 (client-request-id ，并且此重试失败，因为实体已被删除。
如果此问题经常发生，则应调查客户端无法从表服务接收确认的原因。 如果问题是间歇性的，则应捕获“HTTP (404) 找不到”错误，并将其记录在客户端中，但允许客户端继续。
客户端正在接收 HTTP 409 (冲突) 消息
下表显示了从服务器端日志中提取的两个客户端操作： DeleteIfExists 后跟 CreateIfNotExists 使用相同的 Blob 容器名称。 每个客户端操作都会向服务器发送两个请求，第一个GetContainerProperties是请求检查（如果容器存在），然后DeleteContainer是 或 CreateContainer 请求。
| Timestamp | 操作 | 结果 | 容器名称 | 客户端请求 ID |
|---|---|---|---|---|
| 05:10:13.7167225 | GetContainerProperties |
200 | mmcont | c9f52c89-... |
| 05:10:13.8167325 | DeleteContainer |
202 | mmcont | c9f52c89-... |
| 05:10:13.8987407 | GetContainerProperties |
404 | mmcont | bc881924-... |
| 05:10:14.2147723 | CreateContainer |
409 | mmcont | bc881924-... |
客户端应用程序中的代码删除并立即使用相同的名称重新创建 Blob 容器： CreateIfNotExists 方法 (客户端请求 ID bc881924-...) 最终失败并出现 HTTP 409 (冲突) 错误。 当客户端删除 Blob 容器、表或队列时，需要一小段时间才能再次提供该名称。
如果删除/重新创建模式常见，则客户端应用程序在创建新容器时应使用唯一的容器名称。
指标显示低 PercentSuccess 或分析日志条目具有事务状态为 ClientOtherErrors 的操作
PercentSuccess 指标根据 HTTP 状态代码捕获成功操作的百分比。 状态代码为 2XX 的操作将计为成功，而状态代码在 3XX、4XX 和 5XX 范围内的操作将计为失败并降低 PercentSuccess 指标 值。 在服务器端存储日志文件中，这些操作的事务状态为 ClientOtherErrors 进行记录。
请务必注意，这些操作已成功完成，因此不会影响其他指标，例如可用性。 成功执行但可能导致 HTTP 状态代码失败的操作的一些示例包括：
- ResourceNotFound (未找到 404) ，例如，从
GET请求到不存在的 Blob。 - ResourceAlreadyExists (Conflict 409) ，例如，来自
CreateIfNotExist资源已存在的操作。 - ConditionNotMet (Not Modified 304) ，例如，从条件操作（例如客户端发送
ETag值和 HTTPIf-None-Match标头时）请求图像，仅当自上次操作以来已更新图像时。
可以在“常见 REST API 错误代码”页上找到存储服务返回的 常见 REST API 错误代码列表。
容量指标显示存储容量使用量意外增加
如果发现存储帐户中的容量使用量突然发生意外变化，可以先查看可用性指标来调查原因;例如，失败删除请求数量的增加可能会导致你用作特定于应用程序的清理操作的 Blob 存储量增加，例如，由于用于释放空间的 SAS 令牌已过期) (可能无法按预期工作。
使用存储模拟器进行开发或测试时出现问题
通常在开发和测试期间使用存储模拟器，以避免对 Azure 存储帐户的要求。 使用存储模拟器时可能出现的常见问题包括：
功能“X”在存储模拟器中不起作用
存储模拟器不支持 Azure 存储服务的所有功能，例如文件服务。 有关详细信息，请参阅 使用 Azure 存储模拟器进行开发和测试。
对于存储模拟器不支持的功能，请使用云中的 Azure 存储服务。
使用存储模拟器时出现错误“其中一个 HTTP 标头的值的格式不正确”
你正在针对本地存储模拟器测试使用存储客户端库的应用程序，方法调用（例如 CreateIfNotExists ）失败并显示错误消息“其中一个 HTTP 标头的值格式不正确”。这表示所使用的存储模拟器版本不支持正在使用的存储客户端库的版本。 存储客户端库将 标头 x-ms-version 添加到它发出的所有请求中。 如果存储模拟器无法识别标头中的 x-ms-version 值，则会拒绝请求。
可以使用存储库客户端日志来查看它正在发送的值 x-ms-version header 。 如果使用 Fiddler 跟踪来自客户端应用程序的请求，还可以查看 的值 x-ms-version header 。
如果在不更新存储模拟器的情况下安装和使用最新版本的存储客户端库，通常会发生这种情况。 应安装最新版本的存储模拟器，或使用云存储而不是模拟器进行开发和测试。
运行存储模拟器需要管理权限
运行存储模拟器时，系统会提示你输入管理员凭据。 仅当首次初始化存储模拟器时，才会发生这种情况。 初始化存储模拟器后，不需要管理权限来再次运行它。
有关详细信息，请参阅 使用 Azure 存储模拟器进行开发和测试。 还可以在 Visual Studio 中初始化存储模拟器，这还需要管理权限。
安装适用于 .NET 的 Azure SDK 时遇到问题
尝试安装 SDK 时，尝试在本地计算机上安装存储模拟器时会失败。 安装日志包含以下消息之一：
- CAQuietExec：错误：无法访问 SQL 实例
- CAQuietExec：错误：无法创建数据库
原因是现有 LocalDB 安装存在问题。 默认情况下，存储模拟器在模拟 Azure 存储服务时使用 LocalDB 来持久保存数据。 在尝试安装 SDK 之前，可以通过在命令提示符窗口中运行以下命令来重置 LocalDB 实例。
sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0
该 delete 命令从存储模拟器的先前安装中删除任何旧数据库文件。
存储服务存在其他问题
如果前面的故障排除部分不包括存储服务存在的问题，则应采用以下方法来诊断和排查问题。
- 检查指标，查看预期基线行为是否有任何变化。 从指标中，可以确定问题是暂时性的还是永久性的，以及该问题影响哪些存储操作。
- 可以使用指标信息来帮助搜索服务器端日志数据，以获取有关所发生错误的详细信息。 此信息可能有助于排查和解决问题。
- 如果服务器端日志中的信息不足以成功排查问题，则可以使用存储客户端库客户端日志调查客户端应用程序和工具（如 Fiddler 和 Wireshark）的行为，以调查网络。
有关使用 Fiddler 的详细信息，请参阅 附录 1：使用 Fiddler 捕获 HTTP 和 HTTPS 流量。
有关使用 Wireshark 的详细信息，请参阅 附录 2：使用 Wireshark 捕获网络流量。
附录
附录介绍了一些工具，在诊断和排查 Azure 存储 (和其他服务) 问题时，可能会发现这些工具很有用。 这些工具不是 Azure 存储的一部分，有些是第三方产品。 因此，与 Microsoft Azure 或 Azure 存储签订的任何支持协议均未涵盖这些附录中讨论的工具。 因此，在评估过程中，应检查这些工具提供商提供的许可和支持选项。
附录 1：使用 Fiddler 捕获 HTTP 和 HTTPS 流量
Fiddler 是一个有用的工具，用于分析客户端应用程序与正在使用的 Azure 存储服务之间的 HTTP 和 HTTPS 流量。
注意
Fiddler 可以解码 HTTPS 流量。 应仔细阅读 Fiddler 文档，以了解它如何执行此操作及其安全隐患。
本附录简要演练了如何配置 Fiddler 以捕获已安装 Fiddler 的本地计算机与 Azure 存储服务之间的流量。
启动 Fiddler 后，它将开始捕获本地计算机上的 HTTP 和 HTTPS 流量。 下面是一些用于控制 Fiddler 的有用命令：
- 停止并开始捕获流量。 在“main”菜单上，转到“文件”，然后选择“捕获流量”以打开和关闭捕获。
- 保存捕获的流量数据。 在“main”菜单上，转到“文件”，选择“保存”，然后选择“所有会话”。 这使你可以将流量保存在会话存档文件中。 可以稍后重新加载会话存档进行分析，或将其发送给 Microsoft 支持人员。
若要限制 Fiddler 捕获的流量，可以使用在“筛选器”选项卡中配置的 筛选器 。以下屏幕截图显示了一个筛选器，该筛选器仅捕获发送到存储终结点的 contosoemaildist.table.core.windows.net 流量：
附录 2：使用 Wireshark 捕获网络流量
Wireshark 是一种网络协议分析器，可用于查看各种网络协议的详细数据包信息。
以下过程演示如何捕获从安装了 Wireshark 的本地计算机到 Azure 存储帐户中的表服务的流量的详细数据包信息。
在本地计算机上启动 Wireshark。
在 “开始” 部分中，选择一个或多个连接到 Internet 的本地网络接口。
选择“ 捕获选项”。
将筛选器添加到“ 捕获筛选器 ”文本框中。 例如，
host contosoemaildist.table.core.windows.net将 Wireshark 配置为仅捕获 发送到 contosoemaildist 存储帐户中的表服务终结点或从表服务终结点发送的数据包。 查看 捕获筛选器的完整列表。
选择“开始”。 当你在本地计算机上使用客户端应用程序时，Wireshark 现在将捕获发送到表服务终结点或从表服务终结点发送的所有数据包。
完成后，在“main”菜单中选择“捕获>停止”。
若要将捕获的数据保存在 Wireshark 捕获文件中，请在“main”菜单中选择“文件>保存”。
WireShark 将突出显示 数据包列表 窗口中存在的任何错误。 还可以使用“ 专家信息” 窗口 (选择“ 分析>专家信息) 以查看错误和警告的摘要。
还可以选择在应用程序层看到 TCP 数据时查看 TCP 数据，方法是右键单击 TCP 数据，然后选择“遵循 TCP Stream”。 如果在没有捕获筛选器的情况下捕获了转储，这很有用。 有关详细信息，请参阅 关注 TCP 流。
注意
有关使用 Wireshark 的详细信息，请参阅 Wireshark 用户指南。
附录 4：使用 Excel 查看指标和日志数据
许多工具使你能够以分隔格式从 Azure 表存储下载存储指标数据，以便轻松地将数据加载到 Excel 中以供查看和分析。 存储 来自 Azure Blob 存储 的日志记录数据已采用分隔格式，可以加载到 Excel 中。 但是，你需要根据存储分析日志格式和存储分析指标表架构中的信息添加相应的列标题。
若要在从 Blob 存储下载后将存储日志记录数据导入 Excel，请执行以下操作：
- 在“ 数据 ”菜单上，选择“ 从文本”。
- 浏览到要查看的日志文件，然后选择“ 导入”。
- 在 文本导入向导的步骤 1 中，选择“ 带分隔符”。
在 文本导入向导的步骤 1 中，选择“ 分号 ”作为唯一分隔符，并选择“双引号”作为 “文本限定符”。 然后选择“ 完成 ”，然后选择数据在工作簿中的放置位置。
附录 5：使用适用于 Azure DevOps 的 Application Insights 进行监视
还可以将 Azure DevOps 的 Application Insights 功能用作性能和可用性监视的一部分。 此工具可以：
- 确保 Web 服务可用且响应迅速。 无论你的应用是网站还是使用 Web 服务的设备应用，它都可以每隔几分钟从全球各个位置测试一次 URL，并在出现问题时通知你。
- 快速诊断 Web 服务中的任何性能问题或异常。 找出 CPU 或其他资源是否被拉伸，从异常中获取堆栈跟踪，并轻松搜索日志跟踪。 如果应用的性能低于可接受的限制，Microsoft 可以向你发送电子邮件。 可以监视 .NET 和 Java Web 服务。
有关详细信息，请参阅 什么是 Application Insights。
后续步骤
有关 Azure 存储中的分析的详细信息，请参阅以下资源：
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈