共用方式為


使用 Azure 監視器分析 Azure 檔案儲存體 計量

了解如何監視檔案共用效能對於確保應用程式盡可能高效地執行至關重要。 本文向您展示如何使用 Azure 監視器來分析 Azure 檔案儲存體的計量,如可用性、延遲和使用率。

如需可以為 Azure 檔案儲存體收集的監視資料以及如何使用這些資料之詳細資訊,請參閱監視 Azure 檔案儲存體

適用於

管理模型 計費模型 媒體分層 冗餘性 中小企業 (SMB) 網路檔案系統 (NFS)
Microsoft 儲存服務 已佈建的 v2 HDD (標準) 本地 (LRS) 是 否
Microsoft 儲存服務 已佈建的 v2 HDD (標準) 區域 (ZRS) 是 否
Microsoft 儲存服務 已佈建的 v2 HDD (標準) 異地 (GRS) 是 否
Microsoft 儲存服務 已佈建的 v2 HDD (標準) GeoZone (GZRS) 是 否
Microsoft 儲存服務 已佈建的 v1 SSD (進階版) 本地 (LRS) 是 是
Microsoft 儲存服務 已佈建的 v1 SSD (進階版) 區域 (ZRS) 是 是
Microsoft 儲存服務 隨用隨付 HDD (標準) 本地 (LRS) 是 否
Microsoft 儲存服務 隨用隨付 HDD (標準) 區域 (ZRS) 是 否
Microsoft 儲存服務 隨用隨付 HDD (標準) 異地 (GRS) 是 否
Microsoft 儲存服務 隨用隨付 HDD (標準) GeoZone (GZRS) 是 否

支援的計量

Azure 檔案儲存體的計量位於下列命名空間:

  • Microsoft.Storage/storageAccounts 儲存帳戶
  • Microsoft.Storage 儲存帳戶 檔案服務

如需 Azure 檔案儲存體可用計量的清單,請參閱 Azure 檔案儲存體監視資料參考

如需包含 Azure 檔案儲存體的所有 Azure 監視器支援計量清單,請參閱 Azure 監視器支援的計量

檢視 Azure 檔案儲存體計量資料

您可以使用 Azure 入口網站、PowerShell、Azure CLI 或 .NET 來檢視 Azure 檔案儲存體計量。

您可使用 Azure 監視器計量瀏覽器,利用其他 Azure 服務的計量來分析 Azure 儲存體的計量。 從 [Azure 監視器] 功能表中選擇 [計量],以開啟計量瀏覽器。 如需此工具使用方法的詳細資料,請參閱使用 Azure 監視器計量瀏覽器分析計量

針對支援維度的計量,您可使用所需的維度值來篩選計量。 如需 Azure 儲存體支援的完整維度清單,請參閱計量維度

監視工作負載效能

您可以使用 Azure 監視器來分析使用 Azure 檔案儲存體的工作負載。 請遵循下列步驟。

  1. Azure 入口網站中瀏覽至您的儲存體帳戶。
  2. 在服務功能表中的 [監視] 底下,選取 [計量]。
  3. 在 [計量命名空間] 底下,選取 [檔案]。

顯示如何選取 [檔案] 計量命名空間的螢幕快照。

現在,您可以根據您想要監視的項目來選取計量。

監視可用性

在 Azure 監視器中,當從應用程式或使用者的角度來看出現明顯錯誤時,或者當對警示進行疑難排解時,[可用性] 計量可能很有用。

使用 Azure 檔案搭配此計量時,請務必將匯總一律視為平均值,而不是最大值或最小值。 使用 Average 會顯示要求發生錯誤的百分比,以及其是否位於 Azure 檔案服務的 SLA 內。

顯示 Azure 監視器中可用交易計量的螢幕快照。

監視延遲

兩個最重要的延遲計量是 [成功 E2E 延遲] 和 [成功伺服器延遲]。 這些是在開始任何效能調查時可選取的理想計量。 [平均] 是建議的彙總。 如前所述,[最大] 和 [最小] 有時會產生誤導。

在以下圖表中,藍線表示總延遲 (成功 E2E 延遲) 所花費的時間,粉線表示僅在 Azure 檔案儲存體服務中花費的時間 (成功伺服器延遲)。

此圖表顯示具有掛接的 Azure 檔案共用的內部部署用戶端,例如從遠端位置連線的典型使用者。 用戶端與 Azure 區域之間的實體距離與對應的客戶端延遲密切相關,這代表 E2E 與伺服器延遲之間的差異。

顯示連線至 Azure 檔案共用之遠端使用者的延遲計量螢幕快照。

相比之下,以下圖表顯示了用戶端和 Azure 檔案共用位於同一區域內的情况。 請注意,與第一張圖表中的 43.9ms 相比,用戶端延遲僅為 0.17ms。 這說明了為什麼為了實現最佳效能,最小化用戶端延遲是必不可少的。

此螢幕快照顯示用戶端和 Azure 檔案共用位於相同區域中時的延遲計量。

另一個需要尋找的延遲計量可能表明存在問題,即 [成功伺服器延遲] 的頻率增長或異常峰值。 這通常是因為超過配置的檔案共用限制而進行限制或減緩(或是按需付費檔案共用的整體規模限制)。 請參閱 瞭解 Azure 檔案記憶體的計費Azure 檔案服務的延展性和效能目標

如需更多資訊,請參閱高延遲、低輸送量或低 IOPS 疑難排解

監視使用率

測量正在傳輸之資料量 (輸送量) 或正在服務之作業量 (IOPS) 的使用率計量通常用於確定應用程式或工作負載正在執行的工作量。 交易計量可以確定不同時間細微性上針對 Azure 檔案儲存體服務之作業或要求的數量。

如果使用 [輸出] 或 [輸入] 計量來確定輸入或輸出資料量,請使用 [總和] 彙總來確定在 1 分鐘到 1 天的時間細微性內傳輸至檔案共用和從檔案共用傳輸的資料總量。 其他彙總 (如 [平均]、[最大] 和 [最小]) 僅顯示個別 I/O 大小的值。 這就是為什麼大多數客戶在使用 Max 匯總時通常會看到 1 MiB 的原因。 雖然了解最大、最小甚至平均 I/O 大小可能很有用,但無法顯示由工作負載的使用方式模式產生之 I/O 大小的分佈。

您還可以對回應類型 (成功、失敗、錯誤) 或 API 作業 (讀取、寫入、建立、關閉) 選取 [套用分割],以顯示以下圖表所示的其他詳細資料。

顯示依 API 名稱分割使用率計量的螢幕快照。

若要確定工作負載的平均每秒 I/O (IOPS),請首先確定一分鐘內的交易總數,然後將該數字除以 60 秒。 例如,1 分鐘 /60 秒內的 120,000 個交易 = 2,000 個平均 IOPS。

若要確定工作負載的平均輸送量,請透過合併 [輸入] 和 [輸出] 計量 (總輸送量) 來取得傳輸的資料總量,然後除以 60 秒。 例如,1 分鐘 /60 秒內的 1 GiB 總輸送量 = 17 MiB 平均輸送量。

依最大 IOPS 和頻寬監視使用率(僅限配置)

布建檔案共享提供的計量包括依最大 IOPS 計算的交易數依最大 MiB/秒計算的頻寬,以顯示您的工作負載在尖峰時間的表現。 使用這些計量來分析您的工作負載,可協助您瞭解大規模的真實功能,以及建立基準,以瞭解更多輸送量和 IOPS 的影響,以便以最佳方式布建 Azure 檔案共用。

以下圖表顯示了在 1 小時內產生 263 萬個交易的工作負載。 當 263 萬個交易除以 3600 秒時,我們得到的平均 IOPS 為 730。

此螢幕快照顯示工作負載在一個多小時內產生的交易。

現在,當我們將平均 IOPS 與 [依最大 IOPS 的交易] 進行比較時,我們發現在尖峰負載下,我們實現了 1,840 IOPS,這更好地反映了工作負載的大規模能力。

顯示最大 IOPS 交易的螢幕快照。

選取 [新增計量],將 [輸入] 和 [輸出] 計量合併在一個圖表上。 這顯示在一小時內傳輸了 76.2 GiB (78,028 MiB),這使我們在同一小時內的平均輸送量為 21.67 MIB。

顯示如何將輸入和輸出計量合併成單一圖表的螢幕快照。

與 [依最大 MiB/s 的頻寬] 相比,我們在尖峰時達到了 123 MiB/s。

顯示最大 MIBS 頻寬的螢幕快照。

透過中介資料 IOPS 監控使用率

Azure 檔案共用的規模可提升至 12K 的元數據 IOPS。 這表示執行大量開啟、關閉或刪除作業的元數據繁重工作負載會增加元數據 IOPS 節流的可能性。 這項限制與檔案共享的整體布建 IOPS 無關。

由於沒有任何兩個元數據繁重的工作負載遵循相同的使用模式,因此客戶可能很難主動監視其工作負載並設定精確的警示。

為了解決此問題,我們引進了兩個 Azure 檔案共用的元數據特定計量:

  • 元數據警告成功: 表示元數據 IOPS 接近其限制,如果元數據 IOPS 保持高或持續增加,可能會進行節流。 這些警告的數量或頻率增加,表示元數據節流的風險增加。

  • 元數據節流成功: 表示元數據 IOPS 已超過檔案共用的容量,導致節流。 雖然 IOPS 作業永遠不會失敗,而且最終會在重試之後成功,但延遲會在節流期間受到影響。

若要在 Azure 監視器中檢視,請選取 [交易 ] 計量,然後在回應類型上 套用分割 。 只有在選取的時間範圍內發生活動時,元數據回應類型才會出現在下拉式清單中。

下圖說明一個突然元數據 IOPS(交易)增加的工作負載,提示成功設定了元數據警告,這表示可能會出現元數據節流的風險。 在此範例中,工作負載隨後會減少其交易量,以防止發生元數據節流。

顯示依回應類型顯示元數據警告的螢幕快照。

如果您的工作負載遇到成功伴隨元數據警告成功伴隨元數據節流的回應類型,請考慮採取下列一或多項建議。

  • 針對 SSD SMB 檔案共享,啟用 元數據快取
  • 將您的工作負載分片並分散到多個檔案共用。
  • 減少元數據 IOPS 的負載。