监视和诊断 Microsoft Azure 存储并对其进行故障排除（经典）
本指南介绍如何使用 Azure 存储 Analytics、Azure 存储 客户端库中的客户端日志记录和其他第三方工具来识别、诊断和排查Azure 存储相关问题等功能。
本指南的主要目标受众是开发使用 Azure 存储服务的联机服务的开发人员以及负责管理此类联机服务的 IT 专业人员。 本指南的目标是：
- 帮助你维护 Azure 存储帐户的运行状况和性能。
- 提供必要的过程和工具来帮助你确定应用程序中的问题是否与 Azure 存储有关。
- 为提供用于解决与 Azure 存储相关的问题的可操作指南。
注意
本文基于使用称为经典指标和日志的存储分析指标和日志。 建议你使用 Azure Monitor 中的 Azure 存储指标和日志，而不是存储分析日志。 若要了解详细信息，请参阅以下任一文章：
概述
诊断和排查在云环境中托管的分布式应用程序中的问题可能会比在传统环境中更复杂。 应用程序可以部署在 PaaS 或 IaaS 基础结构、本地、移动设备，或这些环境的某种组合中。 通常，应用程序的网络流量可能会遍历公共和专用网络，并且应用程序可以使用多个存储技术，例如Microsoft Azure 存储表、Blob、队列或文件，以及其他数据存储，例如关系数据库和文档数据库。
若要成功管理此类应用程序，应主动监视它们，并了解如何诊断和排查它们及其依赖技术的各个方面。 作为Azure 存储服务的用户，应持续监视应用程序用于行为的任何意外更改的存储服务（例如比平常的响应时间慢），并使用日志记录收集更详细的数据并深入分析问题。 通过监视和日志记录获取的诊断信息将帮助你确定应用程序遇到的问题的根本原因。 然后，可以排查该问题，并确定修正问题的相应步骤。 Azure 存储是一项核心 Azure 服务，是大多数客户部署到 Azure 基础结构的解决方案的重要组成部分。 Azure 存储提供的功能可以简化监视、诊断和排查基于云的应用程序中的存储问题的过程。
本指南的组织方式
“监视存储服务”部分介绍如何使用 Azure 存储 Analytics 指标（存储指标）监视Azure 存储服务的运行状况和性能。
“诊断存储问题”部分介绍如何使用 Azure 存储 Analytics 日志记录（存储日志记录）诊断问题。 它还介绍如何使用客户端库之一中的设施（例如适用于 .NET 的存储客户端库或用于 Java 的 Azure SDK）启用客户端日志记录。
端到端跟踪部分介绍如何关联各种日志文件和指标数据中包含的信息。
“ 故障排除指南 ”部分提供有关可能会遇到的一些常见存储相关问题的故障排除指南。
“追加”部分包括有关使用其他工具的信息，例如 Wireshark 和 Netmon 分析网络数据包数据，以及用于分析 HTTP/HTTPS 消息的 Fiddler。
监视存储服务
如果熟悉 Windows 性能监视，则可以将存储度量值视为 Windows 性能监视器计数器的 Azure 存储等效项。 在存储指标中，你将找到一组全面的指标（Windows 性能监视器术语中的计数器），例如服务可用性、服务请求总数或对服务的成功请求的百分比。 有关可用度量值的完整列表，请参阅存储分析度量值表架构。 可以指定希望存储服务每隔一小时还是每隔一分钟收集和聚合一次度量值。 有关如何启用度量值和监视存储帐户的详细信息，请参阅 Enabling storage metrics and viewing metrics data（启用存储度量值并查看度量值数据）。
可以选择要将哪些每小时指标显示在 Azure 门户中，并配置规则以便在每小时指标超过特定阈值时，通过电子邮件通知管理员。 有关详细信息，请参阅接收警报通知。
建议查看用于存储的 Azure Monitor（预览版）。 它是 Azure Monitor 的一项功能，可通过提供 Azure 存储服务性能、容量和可用性的统一视图来提供对 Azure 存储帐户的全面监视。 无需启用或配置任何设置，即可立即从预定义的交互式图表和所包含的其他可视化效果中查看这些指标。
存储服务会尽力收集指标，但可能不会记录每个存储操作。
在 Azure 门户中，可以查看存储帐户的指标，如可用性、请求总数和平均延迟数。 也已设置通知规则，以便在可用性下降到低于某个级别时向管理员发出警报。 从查看此数据，可以调查的一个可能区域是表服务成功百分比低于 100%（有关详细信息，请参阅 指标显示低 PercentSuccess 或分析日志条目的事务状态为 ClientOtherErrors 部分的操作）。
应通过以下方式持续监视 Azure 应用程序以确保它们正常运行并按预期执行操作：
- 为应用程序建立一些基线指标，以便比较当前数据，并确定 Azure 存储和应用程序行为中的任何重大更改。 在许多情况下，基线指标的值是特定于应用程序的值，在测试应用程序时应建立它们。
- 记录分钟指标并使用它们主动监视意外错误和异常，例如错误计数或请求速率的峰值。
- 记录每小时度量值，并使用这些度量值来监视平均值，例如平均错误计数和请求速率。
- 使用诊断工具调查潜在问题，如后面的“ 诊断存储问题 ”部分所述。
下图中的图表说明了对小时指标进行的求平均值操作为何会隐藏活动中的峰值。 小时度量值似乎显示稳定的请求速率，而分钟度量值却显示了实际发生的波动。
本节的剩余部分介绍应监视哪些度量值以及监视原因。
监视服务运行状况
可以使用 Azure 门户查看全球所有 Azure 区域中存储服务（及其他 Azure 服务）的运行状况。 通过监视，可以立即查看控件外部的问题是否影响用于应用程序的区域中的存储服务。
此外，Azure 门户还可以提供影响各种 Azure 服务的事件的通知。
注意
此信息以前已在 Azure 服务仪表板上与历史数据一起提供。 有关适用于 Azure DevOps 的 Application Insights 的详细信息，请参阅 附录 5：使用 Application Insights 进行 Azure DevOps 监视。
监视容量
存储指标仅存储 Blob 服务的容量指标，因为 Blob 通常占所存储数据的最大比例（撰写本文时，尚不能使用存储指标来监视表和队列的容量）。 如果已启用对 Blob 服务的监视，则可以在 $MetricsCapacityBlob 表中找到此数据。 存储指标每天记录此数据一次，可以使用该值 RowKey 来确定该行是否包含与用户数据（值 data）或分析数据（值 analytics）相关的实体。 每个存储实体都包含有关存储帐户中使用的存储量（Capacity 以字节为单位）和当前容器数（ContainerCount）和 Blob（ObjectCount）的信息。 有关表中存储$MetricsCapacityBlob的容量指标的详细信息，请参阅存储分析指标表架构。
注意
应监视这些值以便获取已接近存储帐户的容量限制的早期警告。 在Azure 门户中，可以添加警报规则，以在聚合存储使用超过或低于指定的阈值时通知你。
若要估计各种存储对象（如 Blob）的大小，请参阅博客文章“了解Azure 存储计费 - 带宽、事务和容量。
监视可用性
应监视存储帐户中存储服务的可用性，方法是监视每小时或分钟指标表中列中的值Availability，例如$MetricsHourPrimaryTransactionsBlob、、、$MetricsHourPrimaryTransactionsTable$MetricsHourPrimaryTransactionsQueue、$MetricsMinutePrimaryTransactionsTable$MetricsMinutePrimaryTransactionsBlob、。 $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob 该 Availability 列包含一个百分比值，该值指示服务的可用性或由行表示的 API 操作（ RowKey 该行是否包含整个服务或特定 API 操作的指标）。
任何小于 100% 的值指示某些存储请求将失败。 可以通过检查指标数据中的其他列来查看失败的原因，这些列显示具有不同错误类型（如 ServerTimeoutError）的请求数。 出于暂时性服务器超时等原因，应会看到 Availability 暂时低于 100% 的情况，而服务移动分区以更好地对请求进行负载均衡;客户端应用程序中的重试逻辑应处理此类间歇性情况。 本文存储分析记录的操作和状态消息列出了存储指标在其Availability计算中包括的事务类型。
在Azure 门户中，可以添加警报规则，以便在某个服务低于指定的阈值时通知你Availability。
本指南的故障排除指南部分介绍了与可用性相关的一些常见存储服务问题。
监视性能
若要监视存储服务的性能，可以使用每小时和每分钟度量值表中的以下度量值。
- 和列中的值
AverageE2ELatencyAverageServerLatency显示存储服务或 API 操作类型处理请求的平均时间。AverageE2ELatency是端到端延迟的度量值，包括读取请求和发送响应所需的时间，以及处理请求所需的时间（因此，请求到达存储服务后包括网络延迟）：AverageServerLatency是仅处理时间的度量值，因此排除与与客户端通信相关的任何网络延迟。 请参阅本指南后面的指标显示 AverageE2ELatency 和 Low AverageServerLatency 部分，了解为什么这两个值之间可能存在显著差异。 - 和列中的值
TotalIngressTotalEgress显示传入和传出存储服务或通过特定 API 操作类型传入和传出的数据总量（以字节为单位）。 - 列中的值
TotalRequests显示 API 操作存储服务接收的请求总数。TotalRequests是存储服务接收的请求总数。
通常，你将监视这些值中的任何一个意外更改，因为这表示存在需要调查的问题。
在Azure 门户中，可以添加警报规则，以便在此服务的任何性能指标低于或超出指定的阈值时通知你。
本指南 的故障排除指南 部分介绍了与性能相关的一些常见存储服务问题。
诊断存储问题
有多种方式可能让你注意到应用程序有问题，这包括：
- 导致应用程序崩溃或停止工作的重大故障。
- 如上一部分 “监视存储服务”中所述，对要监视的指标中的基线值的重大更改。
- 根据应用程序的用户报告，某个特定操作未按预期完成，或者某项功能无法正常工作。
- 在日志文件中或通过某种其他通知方法显示应用程序中生成的错误。
通常，与 Azure 存储服务相关的问题分为以下四大类之一：
- 应用程序的性能问题由用户报告或性能指标的更改显示。
- 一个或多个区域中的 Azure 存储基础结构存在问题。
- 应用程序遇到错误，由用户报告，或者由你监视的错误计数指标之一增加而显示。
- 在开发和测试期间，你可能正在使用本地存储模拟器;可能会遇到一些与存储模拟器的使用相关的问题。
以下各节概述了诊断和排查这四大类中的每一类问题时应遵循的步骤。 本指南后面的“故障排除指南”部分提供了可能遇到的一些常见问题的更多详细信息。
服务运行状况问题
服务运行状况问题通常不受你控制。 Azure 门户提供有关 Azure 服务（包括存储服务）存在的任何持续问题的信息。 如果在创建存储帐户时选择了启用读取访问异地冗余存储，则在主位置中的数据不可用时，应用程序可以暂时切换到辅助位置中的只读副本。 若要从辅助数据库读取，应用程序必须能够在使用主存储和辅助存储位置之间进行切换，并且能够使用只读数据在缩减的功能模式下工作。 使用 Azure 存储客户端库，可以定义重试策略，以便在从主存储读取失败时可以从辅助存储读取。 应用程序还需要注意辅助位置中的数据是否最终一致。 有关详细信息，请参阅博客文章 Azure 存储冗余选项和读取访问异地冗余存储。
性能问题
应用程序的性能可能是主观判定的，尤其是从用户角度来看，更是如此。 因此，请务必设置可用于帮助你确定是否可能存在性能问题的基准指标。 从客户端应用程序角度来看，有许多因素可能会影响 Azure 存储服务的性能。 这些因素可能在存储服务、客户端或网络基础结构中运行;因此，必须制定一个策略来识别性能问题的来源。
在通过度量值确定性能问题的可能根源位置后，可以使用日志文件查找详细信息以便进一步诊断并排查该问题。
本指南 后面的“故障排除指南 ”部分提供有关可能会遇到的一些常见性能相关问题的详细信息。
诊断错误
应用程序用户可能会向你通知客户端应用程序报告的错误。 存储指标还会记录存储服务中不同错误类型的计数，例如 NetworkError、ClientTimeoutError 或 AuthorizationError。 虽然存储指标仅记录不同错误类型的计数，但可以通过检查服务器端日志、客户端日志和网络日志来获取有关单个请求的详细信息。 通常，存储服务返回的 HTTP 状态代码会指示请求失败的原因。
注意
请记住，应该会看到一些间歇性错误：例如，由于暂时性网络条件或应用程序错误而导致的错误。
以下资源对了解与存储相关的状态和错误代码很有帮助：
存储模拟器问题
Azure SDK 提供了一个存储模拟器，可以在开发工作站上运行它。 此模拟器模拟 Azure 存储服务的大部分行为，在开发和测试期间非常有用，使你能够运行使用 Azure 存储服务的应用程序，而无需 Azure 订阅和 Azure 存储帐户。
本指南的故障排除指南部分介绍了使用存储模拟器遇到的一些常见问题。
存储日志记录工具
存储日志记录为 Azure 存储帐户中的存储请求提供服务器端日志记录功能。 有关如何启用服务器端日志记录和访问日志数据的详细信息，请参阅 Enabling Storage Logging and Accessing Log Data（启用存储日志记录和访问日志数据）。
通过用于 .NET 的存储客户端库，可以收集与应用程序执行的存储操作相关的客户端日志数据。 有关详细信息，请参阅 Client-side Logging with the .NET Storage Client Library（使用 .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 以 HTTP 标头值的形式
x-ms-request-id出现在响应消息中。 - 在存储客户端库创建的客户端日志中，服务器请求 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、内存或网络带宽等资源不足。 可以通过将客户端代码修改为更高效（例如，使用对存储服务的异步调用）或使用更大的虚拟机（具有更多核心和更多内存）来解决此问题。
对于表和队列服务，Nagle 算法还可能导致与 AverageServerLatency 相比较高的 AverageE2ELatency。 有关详细信息，请参阅 Nagle 的算法对小型请求不友好。 可以使用命名空间中的System.Net类在代码ServicePointManager中禁用 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。 还应检查每分钟指标，了解导致超过每秒可伸缩性目标的请求数峰值。 有关详细信息，请参阅 “指标”显示 PercentTimeoutError 的增加。
如果针对同一 blob 或 blob 集重复请求时，Blob 下载请求的 AverageServerLatency 较高，请考虑使用 Azure 缓存或 Azure 内容分发网络（CDN）缓存这些 blob。 对于上传请求，可以通过使用较大的数据块大小来提高吞吐量。 对于表查询，也可以在执行相同的查询操作并且数据不会频繁更改的客户端上实施客户端缓存。
高 AverageServerLatency 值也可能是设计欠佳的表或查询的症状，它会导致扫描操作或执行追加/前面预置反模式。 有关详细信息，请参阅 “指标”显示 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 多个实体，请考虑使用多个存储帐户。 还应记住，请求和实体的大小会影响存储服务限制客户端时的影响。 如果你有较大的请求和实体，则可能会更快地受到限制。
低效的查询设计也会导致达到表分区的伸缩性限制。 例如，一个使用筛选器的查询仅选择分区中百分之一的实体，但却扫描该分区中的所有实体，这需要访问每个实体。 读取的每个实体均会计入该分区中的事务总数；因此，很容易就会达到可伸缩性目标。
注意
性能测试应显示应用程序中的任何低效查询设计。
指标显示 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 密钥已过期，则不会在服务器端存储日志记录日志数据中看到任何条目。 下表显示了存储客户端库生成的客户端日志的示例，它说明了如何出现此问题：
| 源 | 详细程度 | 详细程度 | 客户端请求 ID | 操作文本 |
|---|---|---|---|---|
| Microsoft.Azure.Storage | 信息 | 3 | 85d077ab-... | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | 信息 | 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 | 信息 | 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 | 信息 | 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 | 信息 | 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 | 信息 | 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 密钥（例如
sv=2015-04-05）中的版本参数是否与所使用的存储客户端库的版本匹配？ 建议始终使用最新版的存储客户端库。 - 如果重新生成存储访问密钥，可能会使任何现有的 SAS 令牌无效。 如果生成的 SAS 令牌具有较长的到期时间供客户端应用程序缓存，可能会出现此问题。
如果使用存储客户端库生成 SAS 令牌，则可轻松生成有效令牌。 但如果使用的是存储 REST API 并手动构造 SAS 令牌，请参阅使用共享访问签名委派访问权限。
客户端正在接收“HTTP 404 (未找到)”消息
如果客户端应用程序从服务器收到“HTTP 404（未找到）”消息，这意味着客户端正在尝试使用的对象（如实体、表、Blob、容器或队列）在存储服务中不存在。 有多种原因可能会导致此问题，例如：
客户端或其他进程以前删除了该对象
在客户端尝试读取、更新或删除存储服务中的数据的情况下，通常可以轻松地在服务器端日志中识别以前从存储服务中删除有问题的对象的操作。 通常，日志数据显示其他用户或进程删除了该对象。 当客户端删除了该对象时，在服务器端存储日志记录日志中，“操作类型”和“请求的对象键”列会显示相关信息。
在客户端尝试插入对象的情况下，鉴于客户端正在创建新对象，因此这可能会导致 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...）的请求与来自方法（de8b1c3c-...）的请求 UploadFromStream 。发生这种交错，因为客户端应用程序正在异步调用这些方法。 应修改客户端中的异步代码，以确保客户端在尝试将任何数据上传到该容器中的 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：Access-Control-Allow-Origin 标头中找不到源 http://localhost:56309 。
SCRIPT7002：XMLHttpRequest：网络错误0x80070005，拒绝访问。
注意
在排查客户端 JavaScript 问题时，可以使用 Internet Explorer 中的 F12 开发人员工具来跟踪浏览器与存储服务之间交换的消息。
之所以发生这些错误是因为 Web 浏览器实施了同源策略安全限制，以防止网页调用与它来自的域不同的域中的 API。
若要解决 JavaScript 问题，可以为客户端正在访问的存储服务配置跨域资源共享（CORS）。 有关详细信息，请参阅 Cross-Origin Resource Sharing (CORS) Support for Azure Storage Services（Azure 存储服务的跨域资源共享 (CORS) 支持）。
下面的代码示例演示如何配置 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 列中生成的请求 ID（813ea74f...）。
服务器端日志还包括另一个具有相同 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 （冲突 409），例如，来自
CreateIfNotExist资源已存在的操作。 - ConditionNotMet（未修改 304），例如，从条件操作（例如，当客户端发送
ETag值和 HTTPIf-None-Match标头时）请求图像时，仅当自上次操作以来已更新映像时。
可以在公共 REST API 错误代码页上 找到存储服务返回的常见 REST API 错误代码的列表。
容量度量值显示存储容量使用量意外增加
如果发现存储帐户中的容量使用情况发生意外突变，可首先通过查看可用性指标来调查其原因；例如，由于原本希望可以释放空间的应用程序特定清理操作未能按预期工作（例如，因为用于释放空间的 SAS 令牌已过期），因此失败的删除请求数增加可能会导致所用的 Blob 存储量增加。
问题是由于使用存储模拟器进行开发或测试而导致
通常在开发和测试期间使用存储模拟器，以避免对 Azure 存储帐户的要求。 使用存储仿真器时可能发生的常见问题包括：
- 功能“X”在存储模拟器中不起作用。
- 使用存储模拟器时，错误“其中一个 HTTP 标头的值的格式不正确”。
- 运行存储模拟器需要管理权限。
功能“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 存储，有些是第三方产品。 因此，这些附录中讨论的工具不受与 azure 或Azure 存储Microsoft的任何支持协议所涵盖。 因此，作为评估过程的一部分，应检查这些工具提供商提供的许可和支持选项。
附录 1：使用 Fiddler 捕获 HTTP 和 HTTPS 通信
Fiddler 是一个有用的工具，可用于分析客户端应用程序与所用的 Azure 存储服务之间的 HTTP 和 HTTPS 流量。
注意
Fiddler 可以解码 HTTPS 流量。 应仔细阅读 Fiddler 文档，以了解它如何执行此操作及其安全隐患。
本附录提供了一个简要演练，介绍如何配置 Fiddler 以捕获已安装 Fiddler 的本地计算机与 Azure 存储服务之间的流量。
启动 Fiddler 后，它会开始捕获你的本地计算机上的 HTTP 和 HTTPS 流量。 以下是一些用于控制 Fiddler 的有用命令：
- 停止和启动捕获流量。 在主菜单上，转到“文件”，然后选择“捕获流量”以打开和关闭捕获。
- 保存捕获的通信数据。 在主菜单上，转到“文件”，选择“保存”，然后选择“所有会话”。 这使你可以在会话存档文件中保存流量。 稍后可以重新加载会话存档进行分析，或者请求Microsoft支持时发送它。
若要限制 Fiddler 捕获的流量量，可以使用在 “筛选器 ”选项卡中配置的筛选器。以下屏幕截图显示了仅捕获发送到存储终结点的流量的 contosoemaildist.table.core.windows.net 筛选器：
附录 2：使用 Wireshark 捕获网络流量
Wireshark 是一种网络协议分析器，可用于查看各种网络协议的详细数据包信息。
以下过程演示，对于从安装 Wireshark 的本地计算机到 Azure 存储帐户中的表服务的流量，如何捕获其详细数据包信息。
在本地计算机上启动 Wireshark。
在“启动” 部分中，选择本地网络接口或连接到 Internet 的接口。
选择“ 捕获选项”。
将一个筛选器添加到“捕获筛选器”文本框中。 例如，
host contosoemaildist.table.core.windows.net将 Wireshark 配置为仅捕获在 contosoemaildist 存储帐户中发送到表服务终结点或从表服务终结点发送的数据包。 请查看捕获筛选器的完整列表。
选择开始。 Wireshark 现在将在本地计算机上使用客户端应用程序时捕获发送到表服务终结点或从表服务终结点发送的所有数据包。
完成后，选择主菜单上的“ 捕获>停止 ”。
若要在 Wireshark 捕获文件中保存捕获的数据，请在主菜单上选择“文件>保存”。
WireShark 会在 packetlist 窗口中突出显示存在的任何错误。 还可以使用“专家信息”窗口（选择“分析>专家信息”）查看错误和警告的摘要。
还可选择查看 TCP 数据（如果应用程序层看到该数据），方法是右键单击 TCP 数据，并选择“跟踪 TCP 流”。 在不使用捕获筛选器捕获了转储时，此方法很有用。 有关详细信息，请参阅 Following TCP Streams（跟踪 TCP 流）。
注意
有关使用 Wireshark 的详细信息，请参阅 Wireshark Users Guide（Wireshark 用户指南）。
附录 4：使用 Excel 查看度量值和日志数据
使用许多工具可以从 Azure 表存储中下载带分隔符格式的存储指标数据，以便可以轻松地将这些数据加载到 Excel 中以供查看和分析。 Azure Blob 存储中的存储日志记录数据已是带分隔符的格式，可以加载到 Excel 中。 但是，需要根据存储分析日志格式和存储分析指标表架构中的信息添加适当的列标题。
要将存储日志记录数据导入 Excel（从 Blob 存储下载后），请执行以下操作：
- 在“数据”菜单上，选择“从文本”。
- 浏览到要查看的日志文件，然后选择“ 导入”。
- 在文本导入向导的步骤 1 中，选择“带分隔符”。
在文本导入向导的步骤 1 中，选择分号作为唯一的分隔符，然后选择双引号作为文本限定符。 然后选择“完成”，然后选择将数据放置在工作簿中的位置。
附录 5：使用 Application Insights for Azure DevOps 进行监视
在性能和可用性监视过程中，还可以使用用于 Azure DevOps 的 Application Insights 功能。 此工具可以：
- 确保 Web 服务可用且响应迅速。 无论你的应用是网站还是使用 Web 服务的设备应用，它都可以每隔几分钟从世界各地的位置测试一次你的 URL，并告知你是否存在问题。
- 快速诊断 Web 服务中的任何性能问题或异常。 查明 CPU 或其他资源是否过多使用、从异常获取堆栈跟踪并通过日志跟踪轻松地进行搜索。 如果应用程序的性能降至低于可接受的限制，Microsoft 会向你发送电子邮件。 可以同时监视 .NET 和 Java Web 服务。
有关详细信息，可参阅什么是 Application Insights。
后续步骤
有关 Azure 存储中的分析的详细信息，请参阅以下资源：
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。