Verwenden von Azure Monitor zum Analysieren von Azure Files-Metriken

Es ist wichtig zu verstehen, wie die Leistung von Dateifreigaben überwacht wird, um sicherzustellen, dass Ihre Anwendung so effizient wie möglich ausgeführt wird. Dieser Artikel zeigt Ihnen, wie Sie Azure Monitor verwenden können, um Azure Files-Metriken wie Verfügbarkeit, Latenz und Auslastung zu analysieren.

Details zu den Überwachungsdaten, die Sie für Azure Files sammeln können, sowie zu ihrer Verwendung finden Sie unter Überwachen von Azure Files.

Gilt für:

Verwaltungsmodell	Abrechnungsmodell	Medienebene	Redundanz
Microsoft.Storage	Bereitgestellt v2	HDD (Standard)	Lokal (LRS)
Microsoft.Storage	Bereitgestellt v2	HDD (Standard)	Zone (ZRS)
Microsoft.Storage	Bereitgestellt v2	HDD (Standard)	Geo (GRS)
Microsoft.Storage	Bereitgestellt v2	HDD (Standard)	GeoZone (GZRS)
Microsoft.Storage	Bereitgestellt v1	SSD (Premium)	Lokal (LRS)
Microsoft.Storage	Bereitgestellt v1	SSD (Premium)	Zone (ZRS)
Microsoft.Storage	Nutzungsbasierte Bezahlung	HDD (Standard)	Lokal (LRS)
Microsoft.Storage	Nutzungsbasierte Bezahlung	HDD (Standard)	Zone (ZRS)
Microsoft.Storage	Nutzungsbasierte Bezahlung	HDD (Standard)	Geo (GRS)
Microsoft.Storage	Nutzungsbasierte Bezahlung	HDD (Standard)	GeoZone (GZRS)

Unterstützte Metriken

Metriken für Azure Files befinden sich in diesen Namespaces:

Microsoft.Storage/storageAccounts
Microsoft.Storage/storageAccounts/fileServices

Eine Liste der verfügbaren Metriken für Azure Files finden Sie unter Azure Files-Überwachungsdatenreferenz.

Eine Liste aller unterstützten Azure Monitor-Metriken (einschließlich Azure Files) finden Sie unter Unterstützte Azure Monitor-Metriken.

Anzeigen von Azure Files-Metrikdaten

Die können Azure Files-Metriken mit dem Azure-Portal, PowerShell, der Azure CLI oder .NET anzeigen.

Mit dem Metrik-Explorer in Azure Monitor können Sie Metriken für Azure Storage mit Metriken aus anderen Azure-Diensten analysieren. Öffnen Sie den Metrik-Explorer, indem Sie im Menü Azure Monitor die Option Metriken auswählen. Ausführliche Informationen zur Verwendung dieses Tools finden Sie unter Analysieren von Metriken mit dem Azure Monitor-Metrik-Explorer.

Bei Metriken mit Dimensionsunterstützung können Sie die Metrik nach dem gewünschten Dimensionswert filtern. Eine vollständige Liste der von Azure Storage unterstützten Dimensionen finden Sie unter Metrikdimensionen.

Auflisten der Metrikdefinition

Sie können die Metrikdefinition Ihres Speicherkontos oder des Azure Files-Diensts auflisten. Verwenden Sie das Cmdlet Get-AzMetricDefinition.

Ersetzen Sie in diesem Beispiel den Platzhalter <resource-ID> durch die Ressourcen-ID des gesamten Speicherkontos oder die Ressourcen-ID des Azure Files-Diensts. Sie finden diese Ressourcen-IDs im Azure-Portal auf der jeweiligen Seite Eigenschaften Ihres Speicherkontos.

   $resourceId = "<resource-ID>"
   Get-AzMetricDefinition -ResourceId $resourceId

Lesen von Metrikwerten

Sie können die Metrikwerte auf der Kontoebene Ihres Speicherkontos oder des Azure Files-Diensts lesen. Verwenden Sie das Cmdlet Get-AzMetric.

   $resourceId = "<resource-ID>"
   Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00

Lesen von Metrikwerten mit Dimensionen

Wenn eine Metrik Dimensionen unterstützt, können Sie Metrikwerte lesen und sie mithilfe von Dimensionswerten filtern. Verwenden Sie das Cmdlet Get-AzMetric.

   $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"

Auflisten der Metrikdefinition auf Kontoebene

Sie können die Metrikdefinition Ihres Speicherkontos oder des Azure Files-Diensts auflisten. Verwenden Sie den Befehl az monitor metrics list-definitions.

   az monitor metrics list-definitions --resource <resource-ID>

Lesen der Metrikwerte auf der Kontoebene

Sie können die Metrikwerte Ihres Speicherkontos oder des Azure Files-Diensts lesen. Verwenden Sie den Befehl az monitor metrics list.

   az monitor metrics list --resource <resource-ID> --metric "UsedCapacity" --interval PT1H

Lesen von Metrikwerten mit Dimensionen

Wenn eine Metrik Dimensionen unterstützt, können Sie Metrikwerte lesen und sie mithilfe von Dimensionswerten filtern. Verwenden Sie den Befehl az monitor metrics list.

az monitor metrics list --resource <resource-ID> --metric "Transactions" --interval PT1H --filter "ApiName eq 'GetFile' " --aggregation "Total"

Azure Monitor bietet das .NET SDK zum Lesen von Metrikdefinition und -werten. Die Beispielcode zeigt, wie das SDK mit unterschiedlichen Parametern verwendet wird. Sie benötigen 0.18.0-preview oder eine höhere Version für Speichermetriken.

Ersetzen Sie in diesen Beispielen den Platzhalter <resource-ID> durch die Ressourcen-ID des gesamten Speicherkontos oder des Azure Files-Diensts. Sie finden diese Ressourcen-IDs im Azure-Portal auf der jeweiligen Seite Eigenschaften Ihres Speicherkontos.

Ersetzen Sie die Variable <subscription-ID> durch die ID Ihres Abonnements. Einen Leitfaden zum Abrufen von Werten für <tenant-ID>, <application-ID> und <AccessKey> finden Sie unter Erstellen einer Microsoft Entra-Anwendung und eines Dienstprinzipals mit Ressourcenzugriff über das Portal.

Auflisten der Metrikdefinition auf Kontoebene

Das folgende Beispiel zeigt, wie Sie die Metrikdefinition auf der Kontoebene auflisten:

    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
        }
    }

Lesen von Metrikwerten auf Kontoebene

Das folgende Beispiel zeigt, wie Sie UsedCapacity-Daten auf der Kontoebene lesen:

    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
        }
    }

Lesen von Werten mehrdimensionaler Metriken

Für mehrdimensionale Metriken müssen Sie Metadatenfilter definieren, wenn Metrikdaten für bestimmte Dimensionswerte gelesen werden sollen.

Das folgende Beispiel zeigt, wie Metrikdaten für die Metrik gelesen werden, die mehrdimensionale Werte unterstützen:

    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
        }
    }

Überwachen der Workloadleistung

Sie können Azure Monitor verwenden, um Workloads zu analysieren, die Azure Files verwenden. Führen Sie die folgenden Schritte aus.

Navigieren Sie zum Speicherkonto im Azure-Portal.
Wählen Sie im Dienstmenü unter ÜberwachungMetriken aus.
Wählen Sie unter Metriknamespace die Option Datei aus.

Nun können Sie eine Metrik auswählen, die dem entspricht, was Sie überwachen möchten.

Überwachen der Verfügbarkeit

In Azure Monitor kann die Verfügbarkeitsmetrik nützlich sein, wenn etwas aus Anwendungs- oder Benutzersicht sichtbar nicht stimmt oder Warnungen behandelt werden.

Wenn Sie diese Metrik mit Azure Files verwenden, ist es wichtig, die Aggregation immer als Mittelwert im Gegensatz zu Max oder Min anzuzeigen. Mithilfe des Mittelwerts wird angezeigt, welcher Prozentsatz Ihrer Anforderungen Fehler aufweist und ob sie sich innerhalb der SLA für Azure Files befinden.

Überwachen der Latenz

Die beiden wichtigsten Latenzmetriken sind E2E-Wartezeit bei Erfolg und Serverwartezeit bei Erfolg. Diese Metriken sollten Sie beim Starten einer Leistungsuntersuchung auswählen. Durchschnitt ist die empfohlene Aggregation. Wie bereits erwähnt können „Max“ und „Min“ manchmal irreführend sein.

In den folgenden Diagrammen gibt die blaue Linie an, wie viel Zeit in der Gesamtlatenz (E2E-Wartezeit bei Erfolg) aufgewendet wird, und die rosa Linie gibt die nur im Azure Files-Dienst verbrachte Zeit an (Serverwartezeit bei Erfolg).

Diese Grafik zeigt einen lokalen Client mit einem bereitgestellten Azure Fileshare, der z. B. einen typischen Benutzer repräsentiert, der eine Verbindung von einem Remotestandort aus herstellt. Der physische Abstand zwischen client- und Azure-Region ist eng mit der entsprechenden clientseitigen Latenz korreliert, was den Unterschied zwischen der E2E- und Serverlatenz darstellt.

Im Vergleich dazu zeigt das folgende Diagramm eine Situation, in der sich der Client und die Azure-Dateifreigabe in derselben Region befinden. Beachten Sie, dass die clientseitige Latenz nur 0,17 ms im Vergleich zu 43,9 ms im ersten Diagramm beträgt. Dies veranschaulicht, warum die Minimierung der clientseitigen Latenz unerlässlich ist, um eine optimale Leistung zu erzielen.

Ein weiterer Latenzindikator, nach dem gesucht werden sollte, da er auf ein Problem hindeuten kann, ist eine erhöhte Häufigkeit oder ungewöhnliche Spitzen bei der Serverwartezeit bei Erfolg. Dies liegt in der Regel an Drosselung, da der bereitgestellte Grenzwert für eine bereitgestellte Dateifreigabe überschritten wurde (oder aufgrund eines allgemeinen Skalierungsgrenzwerts für eine Freigabe mit nutzungsbasierter Bezahlung). Informationen zur Abrechnung von Azure Files und den Skalierbarkeits- und Leistungszielen für Azure Files finden Sie unter "Grundlegendes zu Azure Files".

Weitere Informationen finden Sie unter Problembehandlung bei hoher Latenz, geringem Durchsatz oder niedrigen IOPS.

Überwachen der Auslastung

Auslastungsmetriken, die die Menge der übertragenen Daten (Durchsatz) oder der zu verarbeitenden Vorgänge (IOPS) messen, werden häufig verwendet, um zu bestimmen, wie viel Arbeit von der Anwendung oder Workload ausgeführt wird. Transaktionsmetriken können die Anzahl der Vorgänge oder Anforderungen für den Azure Files-Dienst mit verschiedenen Zeitgranularitäten bestimmen.

Wenn Sie die Ausgangs- oder Eingangsmetriken verwenden, um die Menge eingehender oder ausgehender Daten zu bestimmen, verwenden Sie die Summenaggregation, um die Gesamtmenge der Daten zu bestimmen, die an die und von der Dateifreigabe für eine Granularität von „1 Minute“ bis „1 Tag“ übertragen werden. Andere Aggregationen wie Durchschnitt, Max und Min zeigen nur den Wert der einzelnen E/A-Größe an. Aus diesem Grund sehen die meisten Kunden in der Regel 1 MiB bei Verwendung der Max-Aggregation . Es kann zwar nützlich sein, die größte, kleinste oder sogar durchschnittliche E/A-Größe zu kennen, aber es ist nicht möglich, die Verteilung der E/A-Größe anzuzeigen, die durch das Nutzungsmuster der Workload generiert wird.

Sie können auch Splitting auf Antworttypen (Erfolg, Fehler, Fehler) anwenden oder API-Vorgänge (Lesen, Schreiben, Erstellen, Schließen) auswählen, um zusätzliche Details anzuzeigen, wie im folgenden Diagramm dargestellt.

Um die durchschnittliche E/A pro Sekunde (IOPS) für Ihre Workload zu bestimmen, bestimmen Sie zunächst die Gesamtzahl der Transaktionen über eine Minute und dividieren diese Anzahl dann durch 60 Sekunden. Beispiel: 120.000 Transaktionen in 1 Minute ÷ 60 Sekunden = 2.000 durchschnittliche IOPS.

Um den durchschnittlichen Durchsatz für Ihre Workload zu ermitteln, verwenden Sie die Gesamtmenge der übertragenen Daten, indem Sie die Eingangs- und Ausgangsmetriken (Gesamtdurchsatz) kombinieren und diesen durch 60 Sekunden dividieren. Beispiel: 1 GiB Gesamtdurchsatz über 1 Minute ÷ 60 Sekunden = 17 MiB durchschnittlicher Durchsatz.

Überwachen der Auslastung durch maximale IOPS und Bandbreite (nur bereitgestellt)

Mit bereitgestellten Dateifreigaben können Sie die Metriken Transaktionen nach max. IOPS und Bandbreite nach max. MiB/s verwenden, um anzuzeigen, was Ihre Workload zu Spitzenzeiten erreicht. Wenn Sie diese Metriken verwenden, um Ihre Workload zu analysieren, können Sie echte Funktionen im großen Maßstab verstehen und einen Basisplan einrichten, um die Auswirkungen von mehr Durchsatz und IOPS zu verstehen, damit Sie Ihre Azure-Dateifreigabe optimal bereitstellen können.

Das folgende Diagramm zeigt eine Workload, die über eine Stunde 2,63 Millionen Transaktionen generiert hat. Wenn 2,63 Millionen Transaktionen durch 3.600 Sekunden geteilt werden, erhalten wir einen Durchschnitt von 730 IOPS.

Wenn wir nun die durchschnittlichen IOPS mit den Transaktionen nach max. IOPS vergleichen, sehen wir, dass wir unter Spitzenauslastung 1.840 IOPS erreicht haben, was eine bessere Darstellung der Leistungsfähigkeit der Workload je nach Situation darstellt.

Wählen Sie Metrik hinzufügen aus, um die Eingangs- und Ausgangsmetriken in einem einzelnen Diagramm zu kombinieren. Sie sehen, dass 76,2 GiB (78.028 MiB) über eine Stunde übertragen wurden, was uns einen durchschnittlichen Durchsatz von 21,67 MiB in dieser Stunde ergibt.

Im Vergleich zur Bandbreite nach max. MiB/s wurde ein Spitzenwert von 123 MiB/s erreicht.

Überwachen der Auslastung durch Metadaten-IOPS

Auf Azure-Dateifreigaben können die IOPS auf bis zu 12.000 Metadaten hochskaliert werden. Dies bedeutet, dass das Ausführen einer metadatenlastigen Workload mit hohem Volumen von Vorgängen zum Öffnen, Schließen oder Löschen die Wahrscheinlichkeit der Drosselung von Metadaten-IOPS erhöht. Diese Einschränkung ist unabhängig von den insgesamt bereitgestellten IOPS der Dateifreigabe.

Da keine zwei Metadatenlasten demselben Verwendungsmuster entsprechen, kann es für Kunden schwierig sein, ihre Arbeitsauslastung proaktiv zu überwachen und genaue Warnungen festzulegen.

Um dies zu beheben, haben wir zwei metadatenspezifische Metriken für Azure-Dateifreigaben eingeführt:

Erfolg mit Metadatenwarnung: Gibt an, dass Metadaten-IOPS ihren Grenzwert nähern und möglicherweise gedrosselt werden, wenn sie hoch bleiben oder weiter steigen. Ein Anstieg der Menge oder Häufigkeit dieser Warnungen deutet auf ein zunehmendes Risiko der Drosselung von Metadaten hin.
Erfolg bei der Metadatendrosselung: Gibt an, dass die Metadaten-IOPS die Kapazität der Dateifreigabe überschritten und damit eine Drosselung verursacht haben. Während IOPS-Vorgänge nie fehlschlagen und nach erneuten Versuchen schließlich erfolgreich sind, wird die Latenz während der Drosselung beeinträchtigt.

Wählen Sie zum Anzeigen in Azure Monitor die Metrik "Transaktionen " aus, und wenden Sie die Aufteilung auf Antworttypen an. Die Metadatenantworttypen werden nur in der Dropdownliste angezeigt, wenn die Aktivität innerhalb des ausgewählten Zeitrahmens auftritt.

Das folgende Diagramm zeigt eine Workload mit einem plötzlichen Anstieg der Metadaten-IOPS (Transaktionen), die einen „Erfolg mit Metadatenwarnungen“ ausgelöst hat, der auf ein Risiko für Metadatendrosselung hinweist. In diesem Beispiel reduzierte die Arbeitsauslastung anschließend das Transaktionsvolumen, was eine Drosselung der Metadaten verhinderte.

Wenn für Ihre Workload Erfolg mit Metadatenwarnungen oder Erfolg mit Metadatendrosselung angezeigt wird, sollten Sie eine oder mehrere der folgenden Empfehlungen implementieren:

Aktivieren Sie für SSD-SMB-Dateifreigaben das Zwischenspeichern von Metadaten.
Verteilen (Sharding) Sie Ihre Workload auf mehrere Dateifreigaben.
Verringern Sie das Volumen der Metadaten-IOPS.

Feedback

War diese Seite hilfreich?

Last updated on 2025-06-16