Azure Blob 儲存體 會將資料分散到各個分區，以提供可擴展的效能。 當流量集中在單一分割區時，該分割區可能成為瓶頸，這種情況稱為 熱分割區。 本文說明什麼是熱分割區，如何透過 Azure 監視器 指標和資源日誌辨識它們，以及你可以採取哪些步驟來更平均分配負載並減少限速錯誤。
了解熱點分區
Azure Blob 儲存體 會自動將資料分配到各個分割區，以擴展效能與吞吐量。 當單一分割區接收到明顯多於其他分割區的流量時，該分割區會成為 熱分割區。 熱分割區發生在大量讀取、寫入或更新請求同時傳送到同一分割區時，限制了服務有效平衡工作負載的能力。 因此，請求會經歷延遲增加、限速及逾時錯誤，直到工作負載重新分配或存取模式被優化。 將流量集中於一小部分資料，而非分散要求於多個分區的分割或命名結構描述，常會導致熱點分區。
熱分區的症狀與影響
當儲存分割區變得過熱時，它就無法再有效率地處理請求。 隨著分割區接近可擴展性極限，Azure 儲存體 開始限速請求，以保護服務並維持其他工作負載的可靠性。 用戶端應用程式會經歷延遲增加、吞吐量降低及暫時性請求失敗。
熱隔間常見的症狀包括：
- HTTP 503（伺服器忙碌）回應表示分割區暫時無法處理更多請求。
- 當請求因分割區負載過重而延遲完成時，HTTP 500（操作逾時）會回應。
- 請求延遲增加，即使是最終成功的請求也是如此。
- 自動重試，若多個客戶端同時重試，可能會進一步增加流量並延長效能問題。
- 吞吐量降低，即應用程式每秒處理的運算次數低於預期，儘管整體儲存帳號容量充足。
熱分割區通常是因為存取模式將流量集中在單一分割區所造成。 常見範例包括循序 Blob 名稱、僅附加的工作負載，以及會將不成比例的大量流量導向單一分區的分區鍵設計。 當工作負載分配不均時，受影響的分割區會先於儲存帳號的其他部分達到限制，造成瓶頸，影響應用程式效能。
對許多應用而言，熱分割區的第一個徵兆是延遲上升、重試率增加，以及在高需求期間 503 或 500 錯誤數量增加的綜合結果。
透過使用 Azure 監視器 指標和資源日誌偵測限速錯誤
當工作負載超過儲存帳號或分割區的擴展性目標時，Azure 儲存體 會限制請求。 你通常會觀察到節流現象表現為 HTTP 503（伺服器忙碌） 或 500（操作逾時） 回應。 Azure 儲存體 用戶端函式庫經常會自動重試被限速的請求，因此監控對於偵測限速在嚴重影響應用程式效能前至關重要。
使用 Azure 監視器 指標來識別限速錯誤
若要偵測節流，請分析 Azure 監視器 中儲存體帳戶的計量。 交易指標結合回應類型維度，能讓你看到儲存請求的結果，並協助你辨識與限速相關的失敗。
辨識限速的指標
下列 Azure 監視器 指標在調查節流問題時非常有用：
| Metric | Purpose |
|---|---|
| 交易 | 衡量儲存服務處理的請求數量。 使用 ResponseType 維度來識別被限速的請求。 |
| 可用性 | 顯示成功申請的百分比。 可用性下降可能顯示發生了節流或其他請求失敗情況。 |
| 成功 E2E 延遲 | 衡量端對端請求延遲，包括網路及用戶端處理。 增加可能表示因節流而導致的重試。 |
| 成功伺服器延遲 | 衡量儲存服務處理請求所需的時間。 將此指標與端對端延遲（E2E）延遲比較，有助於區分服務端延遲與用戶端重試。 |
常見的節流模式是延遲增加，並伴隨與節流相關的回應類型增加以及可用性下降。
使用 ResponseType 維度來識別節流
ResponseType 維度是識別 Azure 監視器 指標中限速條件的主要工具。 相關價值包括：
| ResponseType 的值 | Description |
|---|---|
| ServerBusyError | 儲存服務回傳 HTTP 503，因為超出擴展性目標。 |
| ClientThrottlingError | 要求在觸達儲存體服務前，就已受到節流限制。 |
| ClientAccountRequestThrottlingError | 帳戶層級的請求速率限制被超越。 |
| ClientAccountBandwidthThrottlingError | 帳號頻寬被超標。 |
| SuccessWithThrottling | 要求最初受到節流，但經過多次重試後最終成功。 |
追蹤這些數值隨時間變化，有助於你辨識短暫的限速尖峰以及持續的擴展性問題。
利用維度精準找出節流的來源
Azure 監視器 的度量維度能幫助隔離導致限速的工作負載：
| Dimension | Purpose |
|---|---|
| ResponseType | 找出特定節流或錯誤狀況。 |
| ApiName | 找出發生節流的作業，例如PutBlob、GetBlob或ListBlobs。 |
| GeoType | 區分地理冗餘儲存帳戶中主要與次要端點的流量。 |
| 驗證 | 協助判斷限速是否與特定認證方式相關。 |
例如，如果節流主要發生於 PutBlob 作業，則該工作負載可能屬於寫入密集型。 如果某個特定 API 操作顯示出較高的限速率，優化工作可以聚焦於該操作，而非整個應用程式。
分析 Azure 監視器 資源記錄
雖然指標能識別限速的存在，但 Azure 監視器 的資源日誌則提供請求層級的細節，有助於診斷根本原因。 資源日誌會記錄成功與失敗的請求，包括限速、逾時、授權及網路相關錯誤。
對於 Azure Blob 儲存體，記錄會在資源日誌傳送至 Log Analytics 工作區後，在 StorageBlobLogs 表格中取得。
查詢節流事件中的資源記錄
在執行這些查詢前，請確保資源日誌已送入 Log Analytics 工作空間。
使用 Kusto 查詢語言 (KQL) 來找出傳回常見與節流相關之狀態碼的要求：
StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc
透過依操作、認證類型、呼叫者 IP 位址或應用程式身份分組結果，擴展此查詢，以識別產生限速請求的工作負載。 資源日誌特別有助於判斷限速是否集中在特定應用程式、操作或時間段內。
節流的警示條件
為下列項目建立 Azure 監視器 警示：
- ServerBusyError交易的持續發生。
- 與限速相關的 ResponseType 值增加。
- 可用性指標降至可接受門檻以下。
- 與節流事件相互關聯的延遲增加。
- 請求量突然增加，接近儲存擴充性極限。
建議的監控工作流程
- 監控 交易 指標，並依 回應類型（ResponseType）分割結果。
- 留意與節流相關的回應類型是否增加，例如 ServerBusyError 和 ClientThrottlingError。
- 使用 ApiName 維度來識別受影響的操作。
- 將限速事件與 可用性變化、 成功端對端延遲及 成功伺服器延遲的變化相關聯。
- 使用 Azure 監視器 資源日誌來判斷哪些請求、操作或應用程式產生了限速流量。
- 設定警示，讓限速問題在影響使用者之前被偵測到。
結合 Azure 監視器 的指標、維度與資源日誌，您可以快速偵測限速狀況，找出需求過剩的根源，並在應用程式效能下降前採取矯正措施。
緩解熱點分區問題
為避免出現熱分割區，請將要求平均分散到各個分割區，並確保應用程式在發生節流時能妥善回應。
使用高效的分割與命名方案
設計分割鍵、blob 名稱及其他識別碼，使請求分布於多個分割區。 避免將大多數要求導向同一分區的循序或僅附加命名模式。 請參見 優化 blob 分割與命名方案。
重試時使用指數退避策略
若請求被限速並回傳 503（伺服器忙碌） 或 500（操作逾時） 錯誤，請使用指數退場策略重試請求。 此方法減輕受影響分割區的壓力，並給予 Azure 儲存體 時間重新平衡負載或從暫時需求激增中恢復。
指數退換重試行為對於透過使用 Azure 儲存體 用戶端函式庫、SDK 或 REST API 存取 Azure 儲存體 的自訂應用程式最為相關。 許多 Microsoft 服務、受控應用程式和第三方用戶端都已實作適當的重試邏輯，因此您可能不需要進行任何額外設定。 如果你正在開發自訂應用程式，請確保重試政策已啟用並依照 Azure 儲存體 最佳實務設定。 請參閱下列文章：
避免請求量突然激增
在引入新工作負載、執行效能測試或處理大量資料時，應逐步提升請求速率，而非立即產生峰值流量。 Azure 儲存體 會隨著需求變化自動負載平衡分割區，但突如其來的流量激增可能會暫時壓垮分割區，導致限速，直到服務有機會調整。
下一步
詳細實作指引請參見：