監視、診斷與疑難排解 Microsoft Azure 儲存體 (傳統)
本指南說明如何使用 Azure 儲存體 Analytics、Azure 儲存體 用戶端連結庫中的客戶端記錄，以及其他第三方工具來識別、診斷和疑難解答 Azure 儲存體 相關問題等功能。
本指南主要提供給使用 Azure 儲存體服務的開發人員，以及負責管理此類線上服務之 IT 專業人士閱讀。 本指南宗旨如下：
- 協助您維持 Azure 儲存體帳戶的健康情況與效能。
- 提供您必要的程序與工具，協助您判斷應用程式內的某個問題是否與 Azure 儲存體有關。
- 提供您可行的指引，幫助您解決與 Azure 儲存體相關的問題。
注意
本文是以使用稱為傳統計量和記錄的 儲存體分析 計量和記錄為基礎。 我們建議您在 Azure 監視器中使用 Azure 儲存體計量和記錄，而不是儲存體分析記錄。 若要深入瞭解，請參閱以下任一篇文章：
概觀
與傳統環境相比，託管於雲端環境的分散式應用程式一旦發生問題，無論要為其進行診斷或疑難排解，都更加複雜。 應用程式可以在 PaaS 或 IaaS 基礎架構、內部部署環境、行動裝置或是這幾種環境的組合上部署。 一般而言，應用程式的網路流量可能會周遊公用和專用網，而且您的應用程式除了關係資料庫等其他數據存放區之外，也可以使用多個記憶體技術，例如 Microsoft Azure 儲存體 數據表、Blob、佇列或檔案。
若要成功管理這類應用程式，您應該主動監視它們，並瞭解如何診斷和疑難解答這些應用程式及其相依技術的所有層面。 身為 Azure 儲存體 服務的使用者，您應該持續監視應用程式用於行為的任何非預期變更的記憶體服務（例如較慢的回應時間），並使用記錄來收集更詳細的數據，並深入分析問題。 您從監視和記錄取得的診斷資訊可協助您判斷應用程式遇到的問題的根本原因。 之後，您才能針對問題進行疑難排解，並決定該採取哪些合宜的步驟來矯正它。 Azure 儲存體 是核心 Azure 服務，是客戶部署至 Azure 基礎結構的大部分解決方案的重要部分。 Azure 儲存體會在您的雲端架構應用程式裡加入各項功能，從而簡化儲存體問題的監視、診斷與疑難排解程序。
本指南架構
監視記憶體服務一節說明如何使用 Azure 儲存體 Analytics 計量（記憶體計量）監視 Azure 儲存體 服務的健康情況和效能。
診斷記憶體問題一節說明如何使用 Azure 儲存體 分析記錄來診斷問題（記憶體記錄）。 它也會描述如何使用其中一個用戶端連結庫中的功能來啟用客戶端記錄，例如適用於 .NET 的記憶體用戶端連結庫或適用於 Java 的 Azure SDK。
端對端追蹤一節說明如何將各種記錄檔和計量數據中包含的資訊相互關聯。
疑難解答 指引 一節提供一些您可能遇到的常見記憶體相關問題的疑難解答指引。
Appendices 區 段包含使用其他工具的相關信息，例如Wireshark和Netmon來分析網路封包數據，以及用於分析 HTTP/HTTPS 訊息的 Fiddler。
監視您的儲存體服務
如果您熟悉 Windows 效能監視，您可以將記憶體計量視為相當於 Windows 效能監視器 計數器的 Azure 儲存體。 在記憶體計量中，您會發現一組完整的計量（Windows 效能監視器 術語中的計數器），例如服務可用性、服務要求總數，或服務成功要求百分比。 如需可用度量的完整清單，請參閱 儲存體分析度量資料表結構描述。 您可以指定讓儲存體服務每小時或每分鐘收集並彙總度量一次。 如需如何啟用度量並監視您的儲存體帳戶的詳細資訊，請參閱 啟用儲存體度量和檢視度量資料。
您可以選擇要在 Azure 入口網站中顯示哪些每小時計量，並設定規則以在每次每小時計量超出特定臨界值時，便以電子郵件通知系統管理員。 如需詳細資訊，請參閱接收警示通知。
建議您檢閱適用於儲存體的 Azure 監視器 (預覽)。 其是 Azure 監視器的一項功能，藉由統一檢視 Azure 儲存體服務效能、容量和可用性，提供 Azure 儲存體帳戶的全面監視。 您不需要啟用或設定任何項目，而且可以立即從預先定義的互動式圖表和其他包含的視覺效果中檢視這些計量。
記憶體服務會盡最大努力收集計量，但可能不會記錄每個記憶體作業。
在 Azure 入口網站中，您可以檢視儲存體帳戶的計量，例如可用性、總要求總及平均延遲數。 同時設定了一個通知規則，會在可用性降至特定水準以下時，通知管理員。 從檢視此數據，調查的其中一個可能區域是數據表服務成功百分比低於 100%（如需詳細資訊，請參閱 計量顯示低 PercentSuccess 或分析記錄專案具有 ClientOtherErrors 交易狀態的作業一節）。
您應該藉由以下方式，持續監視您的 Azure 應用程式，確保這些程式如預期地健全並正常運作：
- 為應用程式建立一些基準計量，可讓您比較目前的數據，並識別 Azure 記憶體和應用程式行為的任何重大變更。 在許多情況下，基準計量的值會是應用程式專屬的值，而且您應該在效能測試應用程式時加以建立。
- 記錄分鐘計量，並使用它們主動監視非預期的錯誤和異常，例如錯誤計數或要求率的尖峰。
- 記錄每小時度量並使用這些度量監視一些平均值，例如平均錯誤計數與要求率。
- 如診斷記憶體問題一 節稍後所述，使用診斷工具調查潛在問題 。
下圖中的圖表說明每小時計量的平均值計算如何隱藏活動中的異常高值。 每小時度量所顯示的要求率極為穩定，而每分鐘度量顯示的才是真正發生的變動起伏情況。
本小節剩下部分說明您應該監視的度量項目及這麼做的原因。
監視服務健康情況
您可以使用 Azure 入口網站來檢視全球所有 Azure 區域中儲存體服務 (及其他 Azure 服務) 的健康情況。 監視可讓您立即查看控制項以外的問題是否會影響您用於應用程式的區域中的記憶體服務。
Azure 入口網站也可以針對會影響各種 Azure 服務的事件提供通知。
注意
這項資訊先前可在 Azure 服務儀錶板上使用，以及歷程記錄數據。 如需 Application Insights for Azure DevOps 的詳細資訊，請參閱 附錄 5：使用 Application Insights 監視 Azure DevOps。
監視容量
儲存體計量只會儲存 Blob 服務的容量計量，這是因為 Blob 通常佔已儲存的資料最大宗 (寫入期間無法使用儲存體計量來監視資料表與佇列的容量)。 如果您已啟用 Blob 服務的監視功能，您可以在資料表中找到 $MetricsCapacityBlob 此資料。 記憶體計量每天會記錄此數據一次，而您可以使用的值RowKey來判斷數據列是否包含與用戶數據（值）或分析數據（valuedataanalytics） 相關的實體。 每個預存實體都包含記憶體使用量的相關信息（Capacity 以位元組為單位），以及記憶體帳戶中目前使用的容器數量（ContainerCount） 和 Blob 數目ObjectCount。 如需儲存在數據表中$MetricsCapacityBlob之容量計量的詳細資訊，請參閱 儲存體分析 計量數據表架構。
注意
建議您監視這些數值，以便在儲存體帳戶接近容量限制時提早收到警告。 在 Azure 入口網站 中，您可以新增警示規則，以在匯總記憶體使用超過或低於您指定的閾值時通知您。
若要估計 Blob 等各種記憶體物件的大小，請參閱部落格文章瞭解計費 Azure 儲存體 – 頻寬、交易和容量。
監視可用性
您應該監視記憶體帳戶中記憶體服務的可用性，方法是監視每小時或分鐘計量資料表資料列中的Availability值，例如 $MetricsHourPrimaryTransactionsBlob、、、$MetricsMinutePrimaryTransactionsTable$MetricsHourPrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable$MetricsMinutePrimaryTransactionsBlob、 。 $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob 數據 Availability 行包含百分比值，指出服務的可用性或數據列所代表的 API 作業（ RowKey 顯示數據列是否包含整個服務或特定 API 作業的計量）。
任何小於 100% 的值，皆表示某些儲存體要求已經失敗。 您可以檢查計量數據中的其他數據行來查看失敗的原因，這些數據行會顯示具有不同錯誤類型的要求數目，例如 ServerTimeoutError。 基於暫時性伺服器逾時等原因，您應該會看到 Availability 暫時低於 100% 的原因，而服務將分割區移至更好的負載平衡要求;用戶端應用程式中的重試邏輯應該處理這類間歇性狀況。 本文 儲存體分析 記錄的作業和狀態消息會列出記憶體計量在其計算中Availability所包含的交易類型。
在 Azure 入口網站 中，您可以新增警示規則，以在服務低於您指定的閾值時通知您Availability。
本指南 的疑難解答指引 一節說明一些與可用性相關的常見記憶體服務問題。
監視效能
若要監視儲存體服務效能，您可以使用下列來自每小時與每分鐘度量表的度量。
- 和
AverageServerLatency資料列中的AverageE2ELatency值會顯示記憶體服務或 API 作業類型處理要求的平均時間。AverageE2ELatency是端對端延遲的量值，其中包含讀取要求所需的時間，以及傳送回應，以及處理要求所需的時間（因此，在要求到達記憶體服務之後，包括網路等待時間）：AverageServerLatency只是處理時間的量值，因此會排除與客戶端通訊相關的任何網路等待時間。 請參閱本指南稍後的 Metrics show high AverageE2ELatency and low AverageServerLatency 一節，以討論為什麼這兩個值之間可能有顯著差異。 - 和
TotalEgress資料列中的TotalIngress值會顯示進出記憶體服務或透過特定 API 作業類型傳入和移出的數據總量，以位元組為單位。 - 數據列中的
TotalRequests值會顯示 API 作業記憶體服務接收的要求總數。TotalRequests是記憶體服務接收的要求總數。
一般而言，您會監視這些值中是否有非預期的變更，因為這表示您有需要調查的問題。
在 Azure 入口網站 中，您可以新增警示規則，以在此服務的任何效能計量低於或超過您指定的閾值時通知您。
本指南 的疑難解答指引 一節說明一些與效能相關的常見記憶體服務問題。
診斷儲存體問題
您可以藉由許多方式來察覺應用程式裡的問題，包括：
- 導致應用程式當機或停止運作的重大失敗。
- 如上一節 監視記憶體服務中所述，您正在監視的計量中基準值的重大變更。
- 應用程式用戶回報某些特定作業未如預期般完成，或某些功能無法運作。
- 您的應用程式所產生，並顯示在記錄檔或是透過其他通知方法顯示的錯誤。
一般來說，與 Azure 儲存體服務相關的問題不外乎以下四個廣義類別之一：
- 您的應用程式有效能問題，可能是由您的用戶回報，或是由效能計量中的變更所顯示。
- 一或多個區域中 Azure 儲存體 基礎結構發生問題。
- 您的應用程式發生錯誤，可能是由您的用戶回報，或是由您監視的其中一個錯誤計數計量增加所顯示。
- 在開發和測試期間，您可能會使用本機記憶體模擬器;您可能會遇到一些與記憶體模擬器使用方式特別相關的問題。
以下章節概述當您對這四個類別分別進行問題診斷與疑難排解時，應該遵循的步驟。 本指南稍後的疑難解答指引一節提供您可能會遇到的一些常見問題的詳細數據。
服務健康情況問題
服務健康情況問題通常是您無法掌控的部分。 Azure 入口網站 提供 Azure 服務中任何持續問題的相關信息，包括記憶體服務。 若您在建立儲存體帳戶時選擇使用「讀取存取異地備援備援儲存體」，則當主要位置無法提供您的資料時，您的應用程式會暫時切換到次要位置的唯讀副本。 若要從次要復本讀取，您的應用程式必須能夠使用主要和次要儲存位置切換，並且能夠使用唯讀數據在功能模式中運作。 Azure 儲存體用戶端程式庫可讓您定義重試原則，當無法從主要儲存體讀取資料時，才能嘗試從次要儲存體讀取資料。 您的應用程式還需要了解次要位置的資料最終會與主要位置的資料維持一致。 如需詳細資訊，請參閱部落格文章 Azure 儲存體備援選項與讀取存取異地備援儲存體。
效能問題
應用程式效能是很主觀的問題，尤其是從使用者觀點來看。 因此，我們需要一套基準度量來協助您識別出現效能問題的位置。 從用戶端應用程式觀點來看，許多因素都會影響 Azure 儲存體服務的效能。 這些因素可能會在記憶體服務、用戶端或網路基礎結構中運作;因此，請務必制定策略來識別效能問題的來源。
當您從度量中找出了效能問題可能發生的位置時，就可以使用記錄檔來找出詳細資訊以便稍後進行診斷並疑難排解問題。
本指南 稍後的疑難解答指引 一節提供有關您可能會遇到的一些常見效能相關問題的詳細資訊。
診斷錯誤
您的應用程式使用者可能會通知您用戶端應用程式所回報的一些錯誤。 記憶體計量也會記錄記憶體服務的不同錯誤類型計數，例如 NetworkError、ClientTimeoutError 或 AuthorizationError。 雖然儲存體度量只會記錄不同的錯誤類型計數，不過您還是可以藉由檢視伺服器端、用戶端與網路記錄來取得個別要求的詳細資料。 一般來說，儲存體服務所傳回的 HTTP 狀態碼會指示要求失敗的原因。
注意
請記住，您應該會看到一些間歇性錯誤：例如，暫時性網路狀況或應用程式錯誤所造成的錯誤。
以下資源有助您了解儲存體相關狀態與錯誤碼：
儲存體模擬器問題
Azure SDK 包含一個儲存體模擬器，可供您在開發工作站上執行。 此模擬器會模擬大部分的 Azure 記憶體服務行為，並在開發和測試期間很有用，讓您執行使用 Azure 記憶體服務的應用程式，而不需要 Azure 訂用帳戶和 Azure 記憶體帳戶。
本指南 的疑難解答指引 一節說明使用記憶體模擬器時遇到的一些常見問題。
儲存體記錄工具
儲存體記錄功能可針對您的 Azure 儲存體帳戶，提供伺服器端的儲存體要求記錄服務。 如需如何啟用伺服器端記錄及存取記錄資料的詳細資訊，請參閱 啟用儲存體記錄和存取記錄檔資料。
Storage Client Library for .NET 能讓您針對應用程式所執行的儲存體操作，收集與其相關的用戶端記錄資料。 如需詳細資訊，請參閱 使用 .NET 儲存體用戶端程式庫在用戶端記錄。
注意
在某些情況下 (例如 SAS 授權失敗)，使用者可能會回報無法在伺服器端儲存體記錄中找到任何要求資料的錯誤。 您可以使用儲存體用戶端程式庫裡的記錄功能，調查問題是否出現在用戶端，或是使用網路監視工具來調查網路。
使用網路記錄工具
您可以擷取用戶端與伺服器之間的流量，針對用戶端與伺服器在交換的資料，以及在底層運作的網路狀況提供詳細資訊。 有用的網路記錄工具如下：
- Fiddler 是免費的 Web 偵錯 Proxy，可讓您檢視 HTTP 與 HTTPS 要求及回應訊息的標頭與承載資料。 如需詳細資訊，請參閱 附錄 1：使用 Fiddler 擷取 HTTP 與 HTTPS 流量。
- Microsoft Network Monitor (Netmon) 與 Wireshark 都是免費的網路通訊協定分析器，可讓您針對廣泛的網路通訊協定檢視詳細封包資訊。 如需Wireshark的詳細資訊，請參閱 附錄 2：使用Wireshark擷取網路流量。
- 如果您想要執行基本的連線測試以確認用戶端機器能夠透過網路與 Azure 儲存體服務連線的話，您無法使用用戶端上的標準 ping 工具來執行。 不過，您可以使用 tcping 工具來 檢查連線。
在許多案例中，來自儲存體記錄與儲存體用戶端程式庫的記錄資料，用來診斷問題都已綽綽有餘，但是在某些情況中，您可能需要比這些網路記錄工具所能提供的資訊還要詳盡的資料才行。 舉例來說，透過 Fiddler 來檢視 HTTP 與 HTTPS 訊息可以讓您檢視在儲存體服務之間來回傳送的標頭與裝載資料，進一步幫助您確認用戶端應用程式如何重試儲存體操作。 諸如 Wireshark 之類的通訊協定分析器可在封包層級運作，方便您檢視 TCP 資料，從而為遺失的封包與連線問題進行疑難排解。
端對端追蹤
使用各種記錄檔案進行的端對端追蹤方式，是調查潛在問題的有效方法。 您可以使用計量數據的日期/時間資訊，指出要從何處開始查看記錄檔，以取得詳細資訊，以協助您針對問題進行疑難解答。
為記錄資料建立相互關聯
從用戶端應用程式、網路追蹤和伺服器端記憶體記錄檢視記錄時，必須能夠將不同記錄檔的要求相互關聯。 這些記錄檔包含一些可當成相互關聯識別碼來使用的不同欄位。 需為不同記錄中的項目建立相互關聯時，用戶端要求識別碼是最有用處的欄位。 不過，有時候，使用伺服器要求標識碼或時間戳可能很有用。 以下章節針對這些選項提供詳盡的說明。
用戶端要求 ID
儲存體用戶端程式庫會自動為每一項要求產生唯一的用戶端要求識別碼。
- 在記憶體用戶端連結庫所建立的用戶端記錄檔中，用戶端要求標識碼會出現在
Client Request ID與要求相關的每個記錄專案的欄位中。 - 在 Fiddler 所擷取的網路追蹤中，用戶端要求標識碼會在要求訊息
x-ms-client-request-id中顯示為 HTTP 標頭值。 - 在伺服器端的儲存體記錄中，用戶端要求用戶端要求識別碼會顯示在用戶端要求用戶端要求識別碼資料行。
注意
多個要求可以共用同一個用戶端要求識別碼，這是因為用戶端可以指派此值 (雖然儲存體用戶端程式庫會自動指派新的值)。 當用戶端重試時，則所有嘗試都會共用相同的用戶端要求識別碼。 如果批次是從用戶端傳送，則該批次具有單一用戶端要求識別碼。
伺服器要求 ID
儲存體服務會自動產生伺服器要求 ID。
- 在伺服器端記憶體記錄檔中，伺服器要求標識碼會出現在數據行中
Request ID header。 - 在網路追蹤中，例如 Fiddler 所擷取的網路追蹤中，伺服器要求標識符會以 HTTP 標頭值的形式出現在回應訊息中
x-ms-request-id。 - 在記憶體用戶端連結庫所建立的用戶端記錄檔中，伺服器要求標識碼會出現在記錄專案的數據行中
Operation Text，其中顯示伺服器回應的詳細數據。
注意
儲存體服務一律會為每個收到的要求指派唯一的伺服器要求識別碼，因此用戶端的每一次重試以及批次裡所包含的每一項作業，都會具備唯一的伺服器要求識別碼。
下列程式碼範例示範如何使用自訂用戶端要求識別碼。
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 和 low AverageServerLatency。
- 計量顯示低 AverageE2ELatency 和 Low 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 服務。
用戶端延遲傳送要求的可能原因之一，是可用的連線或執行緒數量有限。
此外，請檢查用戶端是否正在執行多個重試，並調查其是否為 。 若要判斷用戶端是否正在執行多次的重試，您可以：
- 檢查 Storage Analytics 記錄。 如果發生多個重試，您會看到多個作業具有相同的用戶端要求標識符，但具有不同的伺服器要求標識符。
- 檢查用戶端記錄。 詳細資訊記錄會指出已發生的重試。
- 對程式代碼進行偵錯，並檢查與要求相關聯的物件屬性
OperationContext。 如果已重試作業，屬性RequestResults將會包含多個唯一的伺服器要求標識符。 您也可以檢查每個要求的開始和結束時間。 如需詳細資訊，請參閱「 伺服器要求 ID」一節裡的程式碼範例。
如果用戶端裡沒有任何問題，請調查封包遺失之類的潛在網路問題。 您可以使用 Wireshark 之類的工具來調查網路問題。
如需使用Wireshark對網路問題進行疑難解答的詳細資訊，請參閱 附錄 2：使用Wireshark擷取網路流量。
度量顯示高 AverageServerLatency
當 Blob 下載要求出現高 AverageServerLatency 的時候，請使用儲存體記錄功能來查看同一個 Blob (或是 Blob 集合) 是否重複出現要求。 針對 Blob 上傳要求，您應該調查用戶端所使用的區塊大小（例如，區塊大小小於 64 K 可能會導致額外負荷，除非讀取也小於 64 K 區塊），以及多個用戶端平行將區塊上傳至相同的 Blob。 您也應該檢查每分鐘計量中導致超過每秒延展性目標的要求數目尖峰。 如需詳細資訊，請參閱 計量顯示 PercentTimeoutError 增加。
如果您在相同 Blob 或一組 Blob 重複要求時看到 Blob 下載要求的 AverageServerLatency，請考慮使用 Azure Cache 或 Azure 內容傳遞網路 （CDN） 快取這些 Blob。 關於上傳要求，您可以使用較大的區塊大小來改善輸送量。 關於資料表查詢，您也可以對執行相同查詢操作，且資料不會經常變動的用戶端，實作用戶端快取處理。
高 AverageServerLatency 值同時也是資料表或查詢設計不良的徵兆，這種情況可能導致掃描作業，或是因為資料表或查詢遵循結尾附加/開頭附加的反模式而引起。 如需詳細資訊，請參閱 計量顯示 PercentThrottlingError 增加。
注意
您可以在這裡找到完整的效能檢查清單：Microsoft Azure 儲存體 效能和延展性檢查清單。
佇列上的訊息在遞送期間出現非預期的延遲
如果您在應用程式將訊息新增至佇列，以及從佇列讀取時發生延遲，請採取下列步驟來診斷問題：
- 確認應用程式已成功將訊息新增至佇列。 在成功之前，請檢查應用程式是否未重試
AddMessage方法數次。 儲存體用戶端程式庫記錄會顯示儲存體作業的重複嘗試情況。 - 確認背景工作角色在將訊息新增至佇列和從佇列讀取訊息的背景工作角色之間沒有時鐘扭曲。 時鐘扭曲會使它看起來像有延遲處理。
- 檢查負責從佇列讀取訊息的背景工作角色是否失敗。 如果佇列用戶端呼叫
GetMessage方法，但無法回應通知，訊息將會在佇列上保持不可見，直到invisibilityTimeout期間到期為止。 此時，訊息才會再次可供處理。 - 檢查佇列長度在一段時間之後是否又增加了。 如果您沒有足夠的背景工作角色可以處理其他背景工作角色在佇列中放置的所有訊息，就可能發生此情況。 此外，請檢查計量，以查看刪除要求是否失敗，以及訊息的清除佇列計數，這可能表示重複嘗試刪除訊息。
- 檢查儲存體記錄中，是否有任何佇列作業在超出慣常的期間內，產生超出預期的 E2ELatency 與 ServerLatency 值。
度量顯示 PercentThrottlingError 增加
當超出儲存體服務的延展性目標時，會出現節流錯誤。 儲存體服務節流是為了確保沒有任何用戶端或是租用戶可犧牲其他服務來使用這項服務。 如需詳細資訊，請參閱標準儲存體帳戶的可擴縮性與效能目標，以深入了解儲存體帳戶的可擴縮性目標，以及儲存體帳戶內分割區的效能目標。
如果 PercentThrottlingError 計量顯示因節流錯誤而失敗的要求百分比增加，您需要調查兩個案例之一：
PercentThrottlingError 的增加通常會與記憶體要求數目增加或一開始對應用程式進行負載測試時同時發生。 當儲存體作業出現「503 伺服器忙碌」或是「500 作業逾時」狀態訊息時，用戶端也會明顯出現這個情況。
PercentThrottlingError 的暫時性增加
如果您看到 PercentThrottlingError 值與應用程式高活動期間相吻合的尖峰，您可以針對用戶端重試實作指數式（非線性）輪詢策略。 輪流重試可減少分割區上的立即負載，並協助應用程式將流量尖峰平滑化。 如需有關如何使用儲存體用戶端程式庫實作重試原則的詳細資訊，請參閱 Microsoft.Azure.Storage.RetryPolicies 命名空間。
注意
您可能也會看到 PercentThrottlingError 值與應用程式高活動期間不一致的尖峰。 最有可能的原因是記憶體服務移動分割區以改善負載平衡。
PercentThrottlingError 的永久增加
如果您看到 PercentThrottlingError 在交易磁碟區永久增加或當您在應用程式上執行初始負載測試之後，其值一致很高，則您需要評估應用程式使用記憶體分割的方式，以及它是否接近記憶體帳戶的延展性目標。 例如，如果您在佇列上看到節流錯誤（這算為單一分割區），請考慮使用其他佇列將交易分散到多個分割區。 如果您發現某個資料表出現節流錯誤，您需要考慮採用不同的資料分割結構描述，並使用範圍較大的資料分割索引鍵，將所有交易分散到多個資料分割。 此問題的一個常見原因是您選取日期做為分割區索引鍵的前置/附加反模式，然後特定一天的所有數據都會寫入至一個分割區：在負載下，這可能會導致寫入瓶頸。 請考慮採用不同的資料分割設計，或是評估使用 Blob 儲存體是否會更好。 此外，請檢查是否因為流量尖峰而發生節流，並調查如何順暢處理您的要求模式。
如果您將所有交易分散到多個資料分割，您必須同時注意儲存體帳戶所設定的延展性限制。 例如，如果您使用十個佇列，每個佇列每秒處理最多 2,000 個 1KB 訊息，則記憶體帳戶的整體限制為每秒 20,000 則訊息。 如果您需要每秒處理超過 20,000 個實體，請考慮使用多個記憶體帳戶。 您也應該記住，當記憶體服務對客戶端進行節流時，要求和實體的大小有影響。 如果您有較大的要求和實體，可能會更快進行節流。
當查詢設計不敷使用時，也會導致資料表分割到達延展性限制。 舉例來說，當查詢中的篩選器只會選取資料分割中實體的 1%，但卻會掃描資料分割中所有實體時，需要存取每個實體。 每個實體讀取動作都會記入該資料分割的總交易數，因此，您可以輕鬆地達到延展性目標。
注意
您的效能測試作業應該會顯示應用程式中任何不敷使用的查詢設計。
度量顯示 PercentTimeoutError 增加
您的度量顯示其中一個儲存體服務的 PercentTimeoutError 有增加情況。 同時，用戶端從儲存體作業中收到大量的「500 作業逾時」HTTP 狀態訊息。
注意
由於儲存服務會將資料分割移至新的伺服器來達到負載平衡目的，因此可能會暫時出現逾時錯誤。
PercentTimeoutError 度量是下列度量的彙總：ClientTimeoutError、AnonymousClientTimeoutError、SASClientTimeoutError、ServerTimeoutError、AnonymousServerTimeoutError 及 SASServerTimeoutError。
伺服器逾時是因為伺服器上的錯誤引起。 用戶端逾時是因為伺服器上的作業已超過用戶端指定的逾時;例如，使用記憶體用戶端連結庫的用戶端可以使用 類別的 屬性來設定作業 ServerTimeout 的 QueueRequestOptions 逾時。
伺服器逾時情況代表儲存體服務發生問題，需要進一步調查原因。 您可以使用計量，查看是否到達服務的可擴縮性限制，並找出可能引起此問題的任何流量暴增情況。 如果此問題是間歇性發生，可能是因為服務中的負載平衡活動所引起。 如果此問題持續發生，而且不是因為應用程式到達服務的點閱限制引起，則請提出支援問題。 針對用戶端逾時，您必須決定逾時是否設定為用戶端中的適當值，並變更客戶端中設定的逾時值，或調查如何藉由優化數據表查詢或減少訊息大小來改善記憶體服務中的作業效能。
度量顯示 PercentNetworkError 增加
您的度量顯示其中一個儲存體服務的 PercentNetworkError 有增加情況。 PercentNetworkError 度量是下列度量的彙總：NetworkError、AnonymousNetworkError 及 SASNetworkError。 當儲存體服務在用戶端進行儲存體要求時偵測到網路錯誤，就會發生這類情況。
此錯誤最常見的原因，就是用戶端在儲存體服務逾時之前就中斷連線。 請調查用戶端裡的程式碼，了解用戶端何時及為何與儲存體服務中斷連線。 您也可以使用Wireshark或 Tcping 來調查來自客戶端的網路連線問題。 這些工具如 附錄所述。
用戶端收到 HTTP 403 (禁止) 訊息
如果您的用戶端應用程式擲回 HTTP 403 (禁止) 錯誤，則可能是因為用戶端在傳送儲存體要求時使用過期的共用存取簽章 (SAS) (但也可能是時鐘誤差、無效的金鑰與空白標頭引起)。 如果過期的 SAS 金鑰是原因，您將不會在伺服器端的記憶體記錄記錄資料中看到任何專案。 下列資料表以儲存體用戶端程式庫所產生的用戶端記錄為例，說明此問題的原因：
| 來源 | 詳細資訊 | 詳細資訊 | 用戶端要求 ID | 作業內容 |
|---|---|---|---|---|
| Microsoft Azure 儲存體 | 資訊 | 3 | 85d077ab-… | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft Azure 儲存體 | 資訊 | 3 | 85d077ab -… | Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request. |
| Microsoft Azure 儲存體 | 資訊 | 3 | 85d077ab -… | Waiting for response. |
| Microsoft Azure 儲存體 | 警告 | 2 | 85d077ab -… | Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden. |
| Microsoft Azure 儲存體 | 資訊 | 3 | 85d077ab -… | Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = . |
| Microsoft Azure 儲存體 | 警告 | 2 | 85d077ab -… | Exception thrown during the operation: The remote server returned an error: (403) Forbidden.. |
| Microsoft Azure 儲存體 | 資訊 | 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 儲存體 | 資訊 | 3 | 85d077ab -… | The next location has been set to Primary, based on the location mode. |
| Microsoft Azure 儲存體 | 錯誤 | 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、容器或佇列) 並不存在儲存體服務中。 這種情況有數種可能的原因，例如：
用戶端或其他程序先前刪除了該物件
在客戶端嘗試讀取、更新或刪除記憶體服務中的數據的情況下，通常很容易在伺服器端記錄先前從記憶體服務中刪除有問題的物件作業。 記錄資料通常會顯示另一位使用者或是程序刪除了該物件。 在伺服器端的儲存體記錄中，operation-type 物件與 requested-object-key 資料欄會顯示用戶端刪除物件的時間。
在客戶端嘗試插入物件的案例中，鑒於用戶端正在建立新的物件，因此這可能會導致 HTTP 404 （找不到）回應的原因可能並不明顯。 不過，如果用戶端正在建立 Blob，它必須能夠找到 Blob 容器。 如果用戶端正在建立訊息，它必須能夠找到佇列。 如果用戶端正在新增數據列，則必須能夠尋找數據表。
您可以使用儲存體用戶端程式庫裡的用戶端記錄，更深入地了解用戶端何時將特定要求傳送至儲存體服務。
下列由儲存體用戶端程式庫所產生的用戶端記錄，說明了當用戶端找不到 Blob 所建立的容器時的問題。 此記錄內含下列儲存體作業的詳細資料：
| 要求識別碼 | 作業 |
|---|---|
| 07b26a5d-... | DeleteIfExists 刪除 Blob 容器的方法。 請注意，這項作業包含 HEAD 檢查容器是否存在的要求。 |
| e2d06d78… | CreateIfNotExists 建立 Blob 容器的方法。 請注意，這項作業包含 HEAD 檢查容器是否存在的要求。 會 HEAD 傳回 404 訊息，但會繼續。 |
| de8b1c3c-... | UploadFromStream 建立 Blob 的方法。 要求 PUT 失敗，並出現 404 訊息。 |
記錄項目：
| 要求識別碼 | 作業內容 |
|---|---|
| 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 來自 方法的要求（要求標識符 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 | <用戶端要求標識碼> |
調查用戶端應用程式嘗試執行其未獲授與許可權的作業的原因。
用戶端 JavaScript 程式碼沒有存取該物件的權限
如果您使用的是 JavaScript 用戶端，而儲存體服務傳回 HTTP 404 訊息，則請在瀏覽器中檢查下列 JavaScript 錯誤：
SEC7120：Access-Control-Allow-Origin 標頭中找不到原始 http://localhost:56309 來源。
SCRIPT7002：XMLHttpRequest：網路錯誤0x80070005，拒絕存取。
注意
當您需要為用戶端的 JavaScript 問題進行疑難排解時，可以使用 Internet Explorer 中的 F12 開發人員工具，追蹤瀏覽器與儲存體服務之間所交換的訊息。
之所以發生這些錯誤，是因為網頁瀏覽器實作了 同源原則 安全性限制，這會防止網頁呼叫與其來源網域不同之網域中的 API。
若要解決 JavaScript 問題，您可以為用戶端正在存取的記憶體服務設定跨原始來源資源分享 （CORS）。 如需詳細資訊，請參閱 Azure 儲存體服務的跨原始資源共用 (CORS) 支援。
下例程式碼範例顯示如何設定您的 Blob 服務，以讓 JavaScript 在 Contoso 網域中執行，進而存取位於您的 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（找不到）」狀態消息。 當您調查資料表儲存體服務中的資料表時，會看到該服務已依要求刪除該實體。
用戶端中的例外狀況詳細數據包含要求數據表服務指派的要求標識碼 （7e84f12d...）。 您可以使用這項資訊來尋找伺服器端記憶體記錄中的要求詳細數據，方法是在記錄檔中的數據行中 request-id-header 搜尋。 您也可以使用度量，判定此類失敗情況何時發生，然後依據度量記錄此錯誤的時間搜尋記錄檔。 此記錄項目顯示刪除作業失敗，並顯示「HTTP (404) 用戶端其他錯誤」的狀態訊息。 相同的記錄專案也包含客戶端在數據行中 client-request-id 產生的要求標識碼（813ea74f...）。
伺服器端記錄檔也包含另一個具有相同 client-request-id 值 （813ea74f...） 的專案，用於相同實體和相同用戶端的成功刪除作業。 此順利完成的刪除作業會在刪除要求失敗之前很快地發生。
此案例最有可能的原因是客戶端將實體的刪除要求傳送至數據表服務，該服務成功但未收到來自伺服器的通知（可能是因為暫時網路問題所致）。 然後，客戶端會自動重試作業（使用相同的 client-request-id），而且此重試失敗，因為實體已經刪除。
如果這個問題經常發生，您應該調查為何用戶端無法收到來自資料表服務的認可。 如果此問題是間歇性發生，您應該捕捉「HTTP (404) 找不到」錯誤並記錄在用戶端裡，但同時允許用戶端繼續作業。
用戶端收到 HTTP 409 (衝突) 訊息
下表顯示兩個用戶端作業的伺服器端記錄檔中擷取： DeleteIfExists 緊接著 CreateIfNotExists 使用相同的 Blob 容器名稱。 每個用戶端作業都會產生兩個傳送至伺服器的要求，首先要求 GetContainerProperties 來檢查容器是否存在，後面接著 DeleteContainer 或 CreateContainer 要求。
| 時間戳記 | 作業 | 結果 | 容器名稱 | 用戶端要求 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 方法（用戶端要求標識碼 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」 無法在記憶體模擬器中運作。
- 使用記憶體模擬器時，「其中一個 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 流量
在您分析用戶端應用程式與您所使用的 Azure 儲存體服務之間的 HTTP 與 HTTPS 流量時，Fiddler 便能派上用場。
注意
Fiddler 可以譯碼 HTTPS 流量。 您應該仔細閱讀 Fiddler 檔，以瞭解其如何執行這項操作及其安全性影響。
本附錄簡略地概述如何設定 Fiddler 來擷取安裝了 Fiddler 的本機電腦以及 Azure 儲存體服務之間的流量。
Fiddler 一經啟動後，就會開始擷取本機電腦上的 HTTP 與 HTTPS 流量。 以下提供您一些有用的命令，方便您控制 Fiddler：
- 停止與開始擷取流量。 在主功能表上，移至 [ 檔案 ]，然後選取 [ 擷取流量 ] 來切換開啟和關閉擷取。
- 儲存擷取的流量資料。 在主功能表上，移至 [ 檔案]，選取 [儲存]，然後選取 [ 所有會話]。 這可讓您將流量儲存在會話封存盤案中。 您可以稍後重載會話封存以供分析，或要求Microsoft支援時傳送。
若要限制 Fiddler 擷取的流量數量，您可以使用您在 [篩選] 索引標籤中設定的篩選。下列螢幕快照顯示只擷取傳送至contosoemaildist.table.core.windows.net記憶體端點的流量的篩選條件：
附錄 2：使用 Wireshark 擷取流量
Wireshark 是一項網路通訊協定工具，能幫助您針對各式各樣的網路通訊協定檢視詳細的封包資訊。
以下程序說明如何從安裝 Wireshark 的本機電腦，將詳細的流量封包資訊擷取到您的 Azure 儲存體帳戶裡的資料表服務中。
在本機電腦上啟動 Wireshark。
在 [開始] 區段中，選取本機網路介面或是連線至網際網路的介面。
選取 [ 擷取選項]。
在 [擷取篩選器] 文字方塊中，新增一項篩選器。 例如，
host contosoemaildist.table.core.windows.net會將Wireshark設定為只擷取 contosoemaildist 記憶體帳戶中數據表服務端點所傳送或傳回的封包。 請參閱擷取篩選器的完整清單。![顯示如何將篩選新增至 [擷取篩選] 文本框的螢幕快照。](media/storage-monitoring-diagnosing-troubleshooting/interface-list.png)
選取 [開始]。 Wireshark 現在會在本機計算機上使用用戶端應用程式時，擷取傳送至數據表服務端點或從數據表服務端點傳送的所有封包。
完成後，請選取主功能表上的 [擷取>停止]。
若要將擷取的數據儲存在Wireshark擷取檔案中，請選取主功能表上的 [檔案>儲存]。
WireShark 會反白顯示任何存在 packetlist 視窗的錯誤。 您也可以使用 [專家資訊] 視窗 （選取 [分析>專家資訊] 來檢視錯誤和警告的摘要。
![顯示 [專家資訊] 視窗的螢幕快照，您可以在其中檢視錯誤和警告的摘要。](media/storage-monitoring-diagnosing-troubleshooting/wireshark-expert-information.png)
您也可以選擇應用程式層所顯示的 TCP 資料，方法是以滑鼠右鍵按一下 TCP 資料，然後選取 [Follow TCP Stream] \(追蹤 TCP 資料流\)。 當您不使用擷取篩選器而擷取到傾印時，這個方法很有用。 如需詳細資訊，請參閱 追蹤 TCP 串流。
注意
如需有關使用 Wireshark 的詳細資訊，請參閱 Wireshark 使用者指南。
附錄 4：使用 Excel 檢視計量與記錄資料
許多工具都可讓您從 Azure 資料表儲存體中下載使用分隔格式的儲存體度量資料，方便您將資料載入 Excel 以供檢視及分析。 來自 Azure Blob 儲存體的儲存體記錄資料已經使用分隔格式，方便您直接載入 Excel。 不過，您必須根據 儲存體分析 記錄格式和 儲存體分析 計量數據表架構的資訊，新增適當的數據行標題。
若要將您從 Blob 儲存體下載的儲存體記錄資料匯入 Excel：
- 在 [ 數據] 功能表上，選取 [從文字]。
- 流覽至您想要檢視的記錄檔，然後選取 [ 匯入]。
- 在 [文字匯入精靈] 的步驟 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 community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。