Azure Monitor gebruiken om metrische gegevens van Azure Files te analyseren

2025-04-04

Informatie over het bewaken van de prestaties van bestandsshares is essentieel om ervoor te zorgen dat uw toepassing zo efficiënt mogelijk wordt uitgevoerd. In dit artikel leest u hoe u Azure Monitor gebruikt om metrische gegevens van Azure Files te analyseren, zoals beschikbaarheid, latentie en gebruik.

Zie Azure Files bewaken voor meer informatie over de bewakingsgegevens die u kunt verzamelen voor Azure Files en hoe u deze kunt gebruiken.

Van toepassing op

Beheermodel	Factureringsmodel	Mediakader	Redundantie
Microsoft.Opslag	Geconfigureerd v2	HDD (standaard)	Lokaal (LRS)
Microsoft.Opslag	Geconfigureerd v2	HDD (standaard)	Zone (ZRS)
Microsoft.Opslag	Geconfigureerd v2	HDD (standaard)	Aardrijkskunde (GRS)
Microsoft.Opslag	Geconfigureerd v2	HDD (standaard)	GeoZone (GZRS)
Microsoft.Opslag	Geconfigureerd v1	SSD (hoogwaardig)	Lokaal (LRS)
Microsoft.Opslag	Geconfigureerd v1	SSD (hoogwaardig)	Zone (ZRS)
Microsoft.Opslag	Betalen per gebruik	HDD (standaard)	Lokaal (LRS)
Microsoft.Opslag	Betalen per gebruik	HDD (standaard)	Zone (ZRS)
Microsoft.Opslag	Betalen per gebruik	HDD (standaard)	Aardrijkskunde (GRS)
Microsoft.Opslag	Betalen per gebruik	HDD (standaard)	GeoZone (GZRS)

Ondersteunde metrische gegevens

Metrische gegevens voor Azure Files bevinden zich in deze naamruimten:

Microsoft.Storage/storageAccounts (opslagaccounts)
Microsoft.Storage/storageAccounts/fileServices

Zie de naslaginformatie over bewakingsgegevens van Azure Files voor een lijst met beschikbare metrische gegevens voor Azure Files.

Zie ondersteunde metrische gegevens van Azure Monitor voor een lijst met alle ondersteunde metrische gegevens van Azure Monitor, waaronder Azure Files.

Metrische gegevens van Azure Files weergeven

U kunt metrische gegevens van Azure Files weergeven met behulp van Azure Portal, PowerShell, Azure CLI of .NET.

U kunt metrische gegevens voor Azure Storage analyseren met metrische gegevens van andere Azure-services met behulp van Azure Monitor Metrics Explorer. Open Metrics Explorer door Metrische gegevens te kiezen in het Menu van Azure Monitor. Zie Metrische gegevens analyseren met Azure Monitor Metrics Explorer voor meer informatie over het gebruik van dit hulpprogramma.

Voor metrische gegevens die dimensies ondersteunen, kunt u de metrische waarde filteren met de gewenste dimensiewaarde. Zie Metrische dimensies voor een volledige lijst met dimensies die door Azure Storage worden ondersteund.

De definitie van de metrische gegevens weergeven

U kunt de metrische definitie van uw opslagaccount of de Azure Files-service vermelden. Gebruik de cmdlet Get-AzMetricDefinition .

Vervang in dit voorbeeld de <resource-ID> tijdelijke aanduiding door de resource-id van het hele opslagaccount of de resource-id van de Azure Files-service. U vindt deze resource-id's op de eigenschappenpagina's van uw opslagaccount in Azure Portal.

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

Metrische waarden lezen

U kunt metrische waarden op accountniveau van uw opslagaccount of de Azure Files-service lezen. Gebruik de cmdlet Get-AzMetric .

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

Metrische waarden lezen met dimensies

Wanneer een metrische waarde dimensies ondersteunt, kunt u metrische waarden lezen en filteren met behulp van dimensiewaarden. Gebruik de 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"

De metrische definitie op accountniveau weergeven

U kunt de metrische definitie van uw opslagaccount of de Azure Files-service vermelden. Gebruik de opdracht az monitor metrics list-definitions.

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

Metrische waarden op accountniveau lezen

U kunt de metrische waarden van uw opslagaccount of de Azure Files-service lezen. Gebruik de az monitor metrics list opdracht.

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

Metrische waarden lezen met dimensies

Wanneer een metrische waarde dimensies ondersteunt, kunt u metrische waarden lezen en filteren met behulp van dimensiewaarden. Gebruik de az monitor metrics list opdracht.

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

Azure Monitor biedt de .NET SDK voor het lezen van metrische definities en waarden. De voorbeeldcode laat zien hoe u de SDK gebruikt met verschillende parameters. U moet 0.18.0-preview of een latere versie gebruiken voor opslagmetriek.

In deze voorbeelden vervangt u de <resource-ID> tijdelijke aanduiding door de resource-id van het hele opslagaccount of de Azure Files-service. U vindt deze resource-id's op de eigenschappenpagina's van uw opslagaccount in Azure Portal.

Vervang de <subscription-ID> variabele door de id van uw abonnement. Gebruik de portal om waarden voor <tenant-ID>, <application-ID> en <AccessKey> te verkrijgen. Raadpleeg De portal gebruiken om een Microsoft Entra-toepassing en service-principal te maken die toegang heeft tot resources voor meer informatie.

De metrische definitie op accountniveau weergeven

In het volgende voorbeeld ziet u hoe u een metrische definitie op accountniveau weergeeft:

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

Metrische waarden op accountniveau lezen

In het volgende voorbeeld ziet u hoe u gegevens op accountniveau kunt lezen 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
        }
    }

Multidimensionale metrische waarden lezen

Voor multidimensionale metrische gegevens moet u metagegevensfilters definiëren als u metrische gegevens wilt lezen over specifieke dimensiewaarden.

In het volgende voorbeeld ziet u hoe u metrische gegevens leest op metrieken die multidimensionale waarden ondersteunen:

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

Prestaties van de werkbelasting bewaken

U kunt Azure Monitor gebruiken om workloads te analyseren die gebruikmaken van Azure Files. Volg deze stappen.

Navigeer naar uw opslagaccount in Azure Portal.
Selecteer in het servicemenu onder Bewaking de optie Metrische gegevens.
Onder metrische naamruimte, selecteer Bestand.

U kunt nu een metrische waarde selecteren, afhankelijk van wat u wilt bewaken.

Beschikbaarheid bewaken

In Azure Monitor kan de metrische gegevens over beschikbaarheid handig zijn wanneer er iets zichtbaar fout is vanuit het perspectief van een toepassing of gebruiker, of wanneer u waarschuwingen oplost.

Wanneer u deze metrische waarde gebruikt met Azure Files, is het belangrijk om de aggregatie altijd te bekijken als Gemiddelde in plaats van Max of Min. Als u Gemiddeld gebruikt, ziet u welk percentage van uw aanvragen fouten ondervindt en of deze zich in de SLA voor Azure Files bevinden.

Latentie bewaken

De twee belangrijkste metrische latentiegegevens zijn Success E2E Latency en Success Server Latency. Dit zijn ideale metrische gegevens die u kunt selecteren bij het starten van een prestatieonderzoek. Het gemiddelde is de aanbevolen aggregatie. Zoals eerder vermeld, kunnen Max en Min soms misleidend zijn.

In de volgende grafieken geeft de blauwe lijn aan hoeveel tijd wordt besteed aan de totale latentie (Success E2E-latentie) en de roze lijn geeft alleen de tijd aan die is besteed in de Azure Files-service (Success Server Latency).

In deze grafiek ziet u een on-premises client met een gekoppelde Azure-bestandsshare, die bijvoorbeeld een typische gebruiker vertegenwoordigt die verbinding maakt vanaf een externe locatie. De fysieke afstand tussen de client en de Azure-regio is nauw gecorreleerd aan de bijbehorende latentie aan de clientzijde. Dit vertegenwoordigt het verschil tussen de E2E- en Serverlatentie.

Ter vergelijking: in de volgende grafiek ziet u een situatie waarin zowel de client als de Azure-bestandsshare zich in dezelfde regio bevinden. Houd er rekening mee dat de latentie aan de clientzijde slechts 0,17 ms is vergeleken met 43,9 ms in de eerste grafiek. Dit illustreert waarom het minimaliseren van latentie aan de clientzijde noodzakelijk is om optimale prestaties te bereiken.

Een andere latentie-indicator die kan wijzen op een probleem is een verhoogde frequentie of abnormale pieken in de latentie van de Success Server. Dit wordt meestal veroorzaakt door beperking vanwege het overschrijden van de toegewezen limiet voor een gealloceerde bestandenshare (of een capaciteitslimiet voor een bestandenshare op basis van betalen naar gebruik). Zie Inzicht in Facturering van Azure Files en de schaalbaarheids- en prestatiedoelen voor Azure Files.

Zie Problemen met hoge latentie, lage doorvoer of lage IOPS oplossen voor meer informatie.

Gebruik bewaken

Metrische gegevens over gebruik waarmee wordt gemeten hoeveel gegevens worden verzonden (doorvoer) of bewerkingen die worden verwerkt (IOPS) worden vaak gebruikt om te bepalen hoeveel werk wordt uitgevoerd door de toepassing of workload. Metrische gegevens over transacties kunnen het aantal bewerkingen of aanvragen voor de Azure Files-service bepalen gedurende verschillende tijdgranulariteit.

Als u de Egress of Ingress metrische gegevens gebruikt om het volume van binnenkomende of uitgaande gegevens te bepalen, gebruik dan de Som aggregatie om de totale hoeveelheid gegevens te bepalen die naar en van de bestandsshare wordt verzonden, met een tijdsinterval van een minuut tot een dag. In andere aggregaties, zoals Gemiddelde, Max en Min , wordt alleen de waarde van de afzonderlijke I/O-grootte weergegeven. Daarom zien de meeste klanten doorgaans 1 MiB wanneer ze de aggregatie Max gebruiken. Hoewel het handig kan zijn om inzicht te hebben in de grootte van uw grootste, kleinste of zelfs gemiddelde I/O-grootte, is het niet mogelijk om de verdeling weer te geven van de I/O-grootte die is gegenereerd door het gebruikspatroon van de werkbelasting.

U kunt ook Splitsen toepassen selecteren op antwoordtypen (geslaagd, mislukkingen, fouten) of API-bewerkingen (lezen, schrijven, maken, sluiten) om aanvullende details weer te geven, zoals weergegeven in de volgende grafiek.

Als u de gemiddelde I/O per seconde (IOPS) voor uw workload wilt bepalen, moet u eerst het totale aantal transacties gedurende een minuut bepalen en dat aantal vervolgens met 60 seconden delen. Bijvoorbeeld 120.000 transacties in 1 minuut / 60 seconden = 2000 gemiddelde IOPS.

Als u de gemiddelde doorvoer voor uw workload wilt bepalen, neemt u de totale hoeveelheid verzonden gegevens door de metrische gegevens voor inkomend en uitgaand verkeer (totale doorvoer) te combineren en dit te delen door 60 seconden. Bijvoorbeeld 1 GiB totale doorvoer over 1 minuut / 60 seconden = 17 MiB gemiddelde doorvoer.

Gebruik bewaken op maximale IOPS en bandbreedte (alleen ingericht)

Ingerichte bestandsshares bieden transacties per maximaal aantal IOPS en bandbreedte per maximaal MiB/s als metriek om weer te geven wat uw workload op piekmomenten bereikt. Door deze metrische gegevens te gebruiken om uw workload te analyseren, krijgt u inzicht in echte mogelijkheden op schaal en kunt u een basislijn instellen om inzicht te verkrijgen in de impact van meer doorvoer en IOPS, zodat u uw Azure-bestandsshare optimaal kunt inrichten.

In de volgende grafiek ziet u een workload die gedurende 1 uur 2,63 miljoen transacties heeft gegenereerd. Wanneer 2,63 miljoen transacties worden gedeeld door 3.600 seconden, krijgen we gemiddeld 730 IOPS.

Wanneer we nu de gemiddelde IOPS vergelijken met de transacties per maximale IOPS, zien we dat we onder piekbelasting 1840 IOPS hebben bereikt. Dit is een betere weergave van de capaciteit van de workload op schaal.

Selecteer Metrische gegevens toevoegen om de metrische gegevens voor inkomend en uitgaand verkeer in één grafiek te combineren. Dit geeft aan dat 76,2 GiB (78.028 MiB) meer dan één uur is overgedragen, wat ons een gemiddelde doorvoer van 21,67 MiB over hetzelfde uur geeft.

Vergeleken met de bandbreedte volgens Max MiB/s, bereikten we 123 MiB/s op piekniveau.

Gebruik bewaken met IOPS voor metagegevens

Met Azure-bestandsshares kunnen de metagegevensprestaties opgeschaald worden tot maximaal 12.000 IOPS. Dit betekent dat het uitvoeren van een metagegevensintensieve workload met een groot aantal open-, sluit- of verwijderbewerkingen de kans op een beperking van metadata IOPS verhoogt. Deze beperking is onafhankelijk van de algemene ingerichte IOPS van de bestandsshare.

Omdat geen twee werkbelastingen met metagegevens hetzelfde gebruikspatroon volgen, kan het lastig zijn voor klanten om proactief hun workload te bewaken en nauwkeurige waarschuwingen in te stellen.

Hiervoor hebben we twee metrische metagegevens geïntroduceerd voor Azure-bestandsshares:

Geslaagd met waarschuwing voor metagegevens: Geeft aan dat IOPS voor metagegevens hun limiet nadert en mogelijk wordt beperkt als deze hoog blijven of toenemen. Een toename van het volume of de frequentie van deze waarschuwingen duidt op een toenemend risico op throttling van metagegevens.
Succes met het beperken van metadata: Geeft aan dat de metadata-IOPS de capaciteit van de bestandsshare hebben overschreden, waardoor begrenzing van het gebruik is toegepast. Hoewel IOPS-bewerkingen nooit mislukken en uiteindelijk slagen na herhaalde pogingen, wordt de latentie beïnvloed tijdens het afremmen.

Als u wilt weergeven in Azure Monitor, selecteert u de metrische gegevens voor transacties en past u splitsingen toe op antwoordtypen. De antwoordtypen voor metagegevens worden alleen weergegeven in de vervolgkeuzelijst als de activiteit plaatsvindt binnen de geselecteerde periode.

In de volgende grafiek ziet u een workload die een plotselinge toename van IOPS (transacties) van metagegevens heeft ondervonden, wat een toestand van "Succes met metagegevenswaarschuwingen" activeert. Dit duidt op een risico van vertraging bij het verwerken van metagegevens. In dit voorbeeld heeft de workload vervolgens het transactievolume verminderd, waardoor metadata-beperkingen niet optreden.

Als uw workload succes met waarschuwingen voor metagegevens of succes met metagegevensbeperking tegenkomt, kunt u een of meer van de volgende aanbevelingen implementeren.

Voor SSD SMB-bestandsshares schakelt u Caching van metagegevens in.
Distribueer uw workload (shard) over meerdere bestandsshares.
Verminder het aantal IOPS voor metagegevens.

Feedback

Is deze pagina nuttig?