了解如何監視檔案共用效能對於確保應用程式盡可能高效地執行至關重要。 本文向您展示如何使用 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 檔案儲存體服務的計量定義。 使用 Get-AzMetricDefinition Cmdlet。
在此範例中,請將 <resource-ID> 預留位置取代為整個儲存體帳戶的資源識別碼或 Azure 檔案儲存體服務的資源識別碼。 您可在 Azure 入口網站中儲存體帳戶的 [屬性] 頁面上找到這些資源識別碼。
$resourceId = "<resource-ID>"
Get-AzMetricDefinition -ResourceId $resourceId
讀取計量值
您可以讀取儲存體帳戶或 Azure 儲存體檔案服務的帳戶層級計量值。 使用 Get-AzMetric Cmdlet。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
使用維度讀取計量值
當計量支援維度時,您可以讀取計量值,並使用維度值進行篩選。 使用 Get-AzMetric Cmdlet。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
$resourceId = "<resource-ID>"
$dimFilter = [String](New-AzMetricFilter -Dimension ApiName -Operator eq -Value "GetFile" 3> $null)
Get-AzMetric -ResourceId $resourceId -MetricName Transactions -TimeGrain 01:00:00 -MetricFilter $dimFilter -AggregationType "Total"
列出帳戶層級的計量定義
您可以列出儲存體帳戶 Azure 檔案儲存體服務的計量定義。 使用 az monitor metrics list-definitions 命令。
在此範例中,請將 <resource-ID> 預留位置取代為整個儲存體帳戶的資源識別碼或 Azure 檔案儲存體服務的資源識別碼。 您可在 Azure 入口網站中儲存體帳戶的 [屬性] 頁面上找到這些資源識別碼。
az monitor metrics list-definitions --resource <resource-ID>
讀取帳戶層級的計量值
您可以讀取儲存體帳戶或 Azure 檔案儲存體服務的計量值。 使用 az monitor metrics list 命令。
az monitor metrics list --resource <resource-ID> --metric "UsedCapacity" --interval PT1H
使用維度讀取計量值
當計量支援維度時,您可以讀取計量值,並使用維度值進行篩選。 使用 az monitor metrics list 命令。
az monitor metrics list --resource <resource-ID> --metric "Transactions" --interval PT1H --filter "ApiName eq 'GetFile' " --aggregation "Total"
Azure 監視器提供 .NET SDK 來讀取計量定義和值。
範例程式碼示範如何使用 SDK 搭配不同的參數。 您必須使用 0.18.0-preview 或更新版本的儲存體計量。
在這些範例中,請將 <resource-ID> 預留位置取代為整個儲存體帳戶或 Azure 檔案儲存體服務的資源識別碼。 您可在 Azure 入口網站中儲存體帳戶的 [屬性] 頁面上找到這些資源識別碼。
將 <subscription-ID> 變數取代為您的訂用帳戶識別碼。 如需有關如何取得 <tenant-ID>、<application-ID> 和 <AccessKey> 值的指引,請參閱使用入口網站來建立可存取資源的 Microsoft Entra 應用程式和服務主體。
列出帳戶層級的計量定義
下列範例說明如何列出帳戶層級的計量定義:
public static async Task ListStorageMetricDefinition()
{
var resourceId = "<resource-ID>";
var subscriptionId = "<subscription-ID>";
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
IEnumerable<MetricDefinition> metricDefinitions = await readOnlyClient.MetricDefinitions.ListAsync(resourceUri: resourceId, cancellationToken: new CancellationToken());
foreach (var metricDefinition in metricDefinitions)
{
// Enumerate metric definition:
// Id
// ResourceId
// Name
// Unit
// MetricAvailabilities
// PrimaryAggregationType
// Dimensions
// IsDimensionRequired
}
}
讀取帳戶層級的計量值
下列範例說明如何讀取帳戶層級的 UsedCapacity 資料:
public static async Task ReadStorageMetricValue()
{
var resourceId = "<resource-ID>";
var subscriptionId = "<subscription-ID>";
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
Microsoft.Azure.Management.Monitor.Models.Response Response;
string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
string endDate = DateTime.Now.ToUniversalTime().ToString("o");
string timeSpan = startDate + "/" + endDate;
Response = await readOnlyClient.Metrics.ListAsync(
resourceUri: resourceId,
timespan: timeSpan,
interval: System.TimeSpan.FromHours(1),
metricnames: "UsedCapacity",
aggregation: "Average",
resultType: ResultType.Data,
cancellationToken: CancellationToken.None);
foreach (var metric in Response.Value)
{
// Enumerate metric value
// Id
// Name
// Type
// Unit
// Timeseries
// - Data
// - Metadatavalues
}
}
讀取多維度計量值
對於多維度的計量,如果您想要讀取特定維度值的計量資料,就必須定義中繼資料篩選條件。
以下範例顯示如何在支援多維度值的度量上讀取度量數據:
public static async Task ReadStorageMetricValueTest()
{
// Resource ID for Azure Files
var resourceId = "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}/fileServices/default";
var subscriptionId = "<subscription-ID}";
// How to identify Tenant ID, Application ID and Access Key: https://azure.microsoft.com/documentation/articles/resource-group-create-service-principal-portal/
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
Microsoft.Azure.Management.Monitor.Models.Response Response;
string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
string endDate = DateTime.Now.ToUniversalTime().ToString("o");
string timeSpan = startDate + "/" + endDate;
// It's applicable to define meta data filter when a metric support dimension
// More conditions can be added with the 'or' and 'and' operators, example: BlobType eq 'BlockBlob' or BlobType eq 'PageBlob'
ODataQuery<MetadataValue> odataFilterMetrics = new ODataQuery<MetadataValue>(
string.Format("BlobType eq '{0}'", "BlockBlob"));
Response = readOnlyClient.Metrics.List(
resourceUri: resourceId,
timespan: timeSpan,
interval: System.TimeSpan.FromHours(1),
metricnames: "BlobCapacity",
odataQuery: odataFilterMetrics,
aggregation: "Average",
resultType: ResultType.Data);
foreach (var metric in Response.Value)
{
//Enumerate metric value
// Id
// Name
// Type
// Unit
// Timeseries
// - Data
// - Metadatavalues
}
}
您可以使用 Azure 監視器來分析使用 Azure 檔案儲存體的工作負載。 請遵循下列步驟。
- 在 Azure 入口網站中瀏覽至您的儲存體帳戶。
- 在服務功能表中的 [監視] 底下,選取 [計量]。
- 在 [計量命名空間] 底下,選取 [檔案]。
現在,您可以根據您想要監視的項目來選取計量。
監視可用性
在 Azure 監視器中,當從應用程式或使用者的角度來看出現明顯錯誤時,或者當對警示進行疑難排解時,[可用性] 計量可能很有用。
使用 Azure 檔案搭配此計量時,請務必將匯總一律視為平均值,而不是最大值或最小值。 使用 Average 會顯示要求發生錯誤的百分比,以及其是否位於 Azure 檔案服務的 SLA 內。
監視延遲
兩個最重要的延遲計量是 [成功 E2E 延遲] 和 [成功伺服器延遲]。 這些是在開始任何效能調查時可選取的理想計量。 [平均] 是建議的彙總。 如前所述,[最大] 和 [最小] 有時會產生誤導。
在以下圖表中,藍線表示總延遲 (成功 E2E 延遲) 所花費的時間,粉線表示僅在 Azure 檔案儲存體服務中花費的時間 (成功伺服器延遲)。
此圖表顯示具有掛接的 Azure 檔案共用的內部部署用戶端,例如從遠端位置連線的典型使用者。 用戶端與 Azure 區域之間的實體距離與對應的客戶端延遲密切相關,這代表 E2E 與伺服器延遲之間的差異。
相比之下,以下圖表顯示了用戶端和 Azure 檔案共用位於同一區域內的情况。 請注意,與第一張圖表中的 43.9ms 相比,用戶端延遲僅為 0.17ms。 這說明了為什麼為了實現最佳效能,最小化用戶端延遲是必不可少的。
另一個需要尋找的延遲計量可能表明存在問題,即 [成功伺服器延遲] 的頻率增長或異常峰值。 這通常是因為超過配置的檔案共用限制而進行限制或減緩(或是按需付費檔案共用的整體規模限制)。 請參閱 瞭解 Azure 檔案記憶體的計費 和 Azure 檔案服務的延展性和效能目標。
如需更多資訊,請參閱高延遲、低輸送量或低 IOPS 疑難排解。
監視使用率
測量正在傳輸之資料量 (輸送量) 或正在服務之作業量 (IOPS) 的使用率計量通常用於確定應用程式或工作負載正在執行的工作量。 交易計量可以確定不同時間細微性上針對 Azure 檔案儲存體服務之作業或要求的數量。
如果使用 [輸出] 或 [輸入] 計量來確定輸入或輸出資料量,請使用 [總和] 彙總來確定在 1 分鐘到 1 天的時間細微性內傳輸至檔案共用和從檔案共用傳輸的資料總量。 其他彙總 (如 [平均]、[最大] 和 [最小]) 僅顯示個別 I/O 大小的值。 這就是為什麼大多數客戶在使用 Max 匯總時通常會看到 1 MiB 的原因。 雖然了解最大、最小甚至平均 I/O 大小可能很有用,但無法顯示由工作負載的使用方式模式產生之 I/O 大小的分佈。
您還可以對回應類型 (成功、失敗、錯誤) 或 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,這更好地反映了工作負載的大規模能力。
選取 [新增計量],將 [輸入] 和 [輸出] 計量合併在一個圖表上。 這顯示在一小時內傳輸了 76.2 GiB (78,028 MiB),這使我們在同一小時內的平均輸送量為 21.67 MIB。
與 [依最大 MiB/s 的頻寬] 相比,我們在尖峰時達到了 123 MiB/s。
Azure 檔案共用的規模可提升至 12K 的元數據 IOPS。 這表示執行大量開啟、關閉或刪除作業的元數據繁重工作負載會增加元數據 IOPS 節流的可能性。 這項限制與檔案共享的整體布建 IOPS 無關。
由於沒有任何兩個元數據繁重的工作負載遵循相同的使用模式,因此客戶可能很難主動監視其工作負載並設定精確的警示。
為了解決此問題,我們引進了兩個 Azure 檔案共用的元數據特定計量:
若要在 Azure 監視器中檢視,請選取 [交易 ] 計量,然後在回應類型上 套用分割 。 只有在選取的時間範圍內發生活動時,元數據回應類型才會出現在下拉式清單中。
下圖說明一個突然元數據 IOPS(交易)增加的工作負載,提示成功設定了元數據警告,這表示可能會出現元數據節流的風險。 在此範例中,工作負載隨後會減少其交易量,以防止發生元數據節流。
如果您的工作負載遇到成功伴隨元數據警告或成功伴隨元數據節流的回應類型,請考慮採取下列一或多項建議。
- 針對 SSD SMB 檔案共享,啟用 元數據快取。
- 將您的工作負載分片並分散到多個檔案共用。
- 減少元數據 IOPS 的負載。
相關內容