Usare Monitoraggio di Azure per analizzare le metriche File di Azure

Comprendere come monitorare le prestazioni della condivisione file è fondamentale per garantire che l'applicazione sia in esecuzione il più efficiente possibile. Questo articolo illustra come usare Monitoraggio di Azure per analizzare File di Azure metriche, ad esempio disponibilità, latenza e utilizzo.

Vedere Monitorare File di Azure per informazioni dettagliate sui dati di monitoraggio che è possibile raccogliere per File di Azure e su come usarli.

Si applica a

Modello di gestione	Modello di fatturazione	Livello supporti	Ridondanza	Piccole e Medie Imprese (PMI)	NFS (Network File System)
Microsoft.Storage	Con provisioning v2	HDD (standard)	Locale
Microsoft.Storage	Con provisioning v2	HDD (standard)	Della zona
Microsoft.Storage	Con provisioning v2	HDD (standard)	Geografica
Microsoft.Storage	Con provisioning v2	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	Con provisioning v1	SSD (Premium)	Locale
Microsoft.Storage	Con provisioning v1	SSD (Premium)	Della zona
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Locale
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Della zona
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	Geografica
Microsoft.Storage	Pagamento in base al consumo	HDD (standard)	GeoZone (GZRS)

Metriche supportate

Le metriche per File di Azure si trovano in questi spazi dei nomi:

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

Per un elenco delle metriche disponibili per File di Azure, vedere Informazioni di riferimento per i dati di monitoraggio di File di Azure.

Per un elenco di tutte le metriche supportate da Monitoraggio di Azure, incluso File di Azure, vederemetriche supportate da Monitoraggio di Azure.

Visualizzare i dati delle metriche File di Azure

È possibile visualizzare File di Azure metriche usando le portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o .NET.

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

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

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

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

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

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

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

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

Monitorare le prestazioni del carico di lavoro

È possibile usare Monitoraggio di Azure per analizzare i carichi di lavoro che usano File di Azure. Effettuare i passaggi seguenti.

1. Passare all'account di archiviazione nel portale di Azure.
2. Nel menu del servizio, in Monitoraggio, selezionare Metriche.
3. In Spazio dei nomi Metrica selezionare File.

È ora possibile selezionare una metrica in base a ciò che si vuole monitorare.

Monitorare la disponibilità

In Monitoraggio di Azure la metrica di disponibilità può essere utile quando si verifica un errore da un'applicazione o da un punto di vista dell'utente o quando si risoseguono i problemi degli avvisi.

Quando si usa questa metrica con File di Azure, è importante visualizzare sempre l'aggregazione come Media anziché Max o Min. Usare Average mostra quale percentuale delle tue richieste sta riscontrando errori, e se rientrano nel SLA per Azure Files.

Monitorare la latenza

Le due metriche di latenza più importanti sono Success E2E Latency e Success Server Latency.The two most important latency are Success E2E Latency and Success Server Latency. Si tratta di metriche ideali da selezionare quando si avvia un'analisi delle prestazioni. Average è l'aggregazione consigliata. Come accennato in precedenza, Max e Min possono talvolta essere fuorvianti.

Nei grafici seguenti, la linea blu indica il tempo impiegato nella latenza totale (latenza riuscita E2E) e la riga rosa indica il tempo impiegato solo nel servizio File di Azure (latenza del server riuscito).

Questo grafico mostra un client locale con una condivisione file di Azure montata, che rappresenta, ad esempio, un utente tipico che si connette da una posizione remota. La distanza fisica tra il client e l'area di Azure è strettamente correlata alla latenza lato client corrispondente, che rappresenta la differenza tra la latenza E2E e server.

Il grafico seguente mostra invece una situazione in cui sia il client che la condivisione file di Azure si trovano nella stessa area. Si noti che la latenza lato client è di soli 0,17 ms rispetto a 43,9 ms nel primo grafico. Questo illustra perché ridurre al minimo la latenza lato client è fondamentale per ottenere prestazioni ottimali.

Un altro indicatore di latenza da cercare che potrebbe suggerire un problema è un aumento della frequenza o picchi anomali nella latenza di Success Server. Ciò è in genere dovuto alla limitazione dovuta al superamento del limite di provisioning per una condivisione file di cui è stato effettuato il provisioning (o a un limite di scalabilità complessivo di una condivisione file con pagamento in base al consumo). Vedere Informazioni sulla fatturazione di File di Azure e sugli obiettivi di scalabilità e prestazioni per File di Azure.

Per altre informazioni, vedere Risolvere i problemi relativi a latenza elevata, velocità effettiva bassa o operazioni di I/O al secondo basse.

Monitorare l'utilizzo

Le metriche di utilizzo che misurano la quantità di dati trasmessi (velocità effettiva) o operazioni gestite (operazioni di I/O al secondo) vengono comunemente usate per determinare la quantità di lavoro eseguita dall'applicazione o dal carico di lavoro. Le metriche delle transazioni possono determinare il numero di operazioni o richieste rispetto al servizio File di Azure in vari periodi di granularità.

Se si usano le metriche Egress o Ingress per determinare il volume dei dati in ingresso o in uscita, usare l'aggregazione Sum per determinare la quantità totale di dati trasmessi da e verso la condivisione file in un intervallo di tempo compreso tra 1 minuto e 1 giorno. Altre aggregazioni, ad esempio Average, Max e Min , visualizzano solo il valore delle singole dimensioni di I/O. Ecco perché la maggior parte dei clienti visualizza in genere 1 MiB quando si usa l'aggregazione Max . Anche se può essere utile comprendere le dimensioni delle dimensioni più grandi, più piccole o persino medie di I/O, non è possibile visualizzare la distribuzione delle dimensioni di I/O generate dal modello di utilizzo del carico di lavoro.

È anche possibile selezionare Applica suddivisione ai tipi di risposta (operazione riuscita, errori, errori) o operazioni API (lettura, scrittura, creazione, chiusura) per visualizzare dettagli aggiuntivi, come illustrato nel grafico seguente.

Per determinare la media di I/O al secondo (IOPS) per il carico di lavoro, determinare prima il numero totale di transazioni in un minuto e quindi dividere il numero per 60 secondi. Ad esempio, 120.000 transazioni in 1 minuto / 60 secondi = 2.000 operazioni di I/O al secondo medie.

Per determinare la velocità effettiva media per il carico di lavoro, prendere la quantità totale di dati trasmessi combinando le metriche Ingress e Egress (velocità effettiva totale) e dividerla per 60 secondi. Ad esempio, 1 GiB velocità effettiva totale su 1 minuto / 60 secondi = 17 velocità effettiva media MiB.

Monitorare l'utilizzo massimo di IOPS e larghezza di banda (solo per l'approvisionamento)

Le condivisioni file sottoposte a provisioning forniscono transazioni per operazioni di IOPS massime e larghezza di banda per numero massimo di MiB/s per visualizzare ciò che il carico di lavoro raggiunge nei momenti di picco. Usando queste metriche per analizzare il carico di lavoro, è possibile comprendere la vera funzionalità su larga scala, nonché stabilire una baseline per comprendere l'impatto di una maggiore velocità effettiva e operazioni di I/O al secondo in modo da poter effettuare il provisioning ottimale della condivisione file di Azure.

Il grafico seguente mostra un carico di lavoro che ha generato 2,63 milioni di transazioni in un'ora. Quando 2,63 milioni di transazioni è diviso per 3.600 secondi, si ottiene una media di 730 operazioni di I/O al secondo.

Ora, quando si confrontano le operazioni di I/O al secondo medie rispetto alle transazioni in base al numero massimo di operazioni di I/O al secondo, si noterà che il carico di lavoro è inferiore a 1.840 operazioni di I/O al secondo, che rappresenta meglio la capacità del carico di lavoro su larga scala.

Selezionare Aggiungi metrica per combinare le metriche in ingresso e uscita in un singolo grafico. Ciò indica che 76,2 GiB (78.028 MiB) è stato trasferito in un'ora, che offre una velocità effettiva media di 21,67 MiB in quella stessa ora.

Rispetto alla larghezza di banda di Max MiB/s, abbiamo raggiunto 123 MiB/s al picco.

Monitorare l'utilizzo basato sugli IOPS dei metadati

Le condivisioni file di Azure sono in grado di scalare fino a 12K IOPS per i metadati. Ciò significa che l'esecuzione di un carico di lavoro pesante sui metadati, con un volume elevato di operazioni di apertura, chiusura o eliminazione, aumenta la probabilità che le operazioni di I/O al secondo dei metadati vengano limitate. Questa limitazione è indipendente dal numero complessivo di operazioni di I/O al secondo della condivisione file.

Poiché nessun carico di lavoro con molti metadati segue lo stesso modello di utilizzo, può risultare difficile per i clienti monitorare proattivamente il loro carico di lavoro e impostare avvisi accurati.

Per risolvere questo problema, sono state introdotte due metriche specifiche dei metadati per le condivisioni file di Azure:

• Successo con avviso metadati: Indica che gli IOPS dei metadati stanno raggiungendo il loro limite e potrebbero essere limitati se rimangono elevati o continuano ad aumentare. Un aumento del volume o della frequenza di questi avvisi indica un rischio crescente di strozzatura dei metadati.

• Operazione riuscita con la limitazione dei metadati: Indica che le operazioni di I/O al secondo dei metadati hanno superato la capacità della condivisione file, con conseguente limitazione. Anche se le operazioni di I/O al secondo non falliscono mai e alla fine hanno successo dopo i tentativi, la latenza viene influenzata durante il throttling.

Per visualizzare in Monitoraggio di Azure, selezionare la metrica Transazioni e Applica suddivisione per i tipi di risposta. I tipi di risposta metadati vengono visualizzati nell'elenco a discesa solo se l'attività si verifica entro l'intervallo di tempo selezionato.

Il grafico seguente illustra un carico di lavoro che ha subito un aumento improvviso delle IOPS dei metadati (transazioni), attivando operazioni riuscite con avvisi sui metadati, il che indica un rischio di strozzamento dei metadati. In questo esempio il carico di lavoro ha successivamente ridotto il volume delle transazioni, impedendo l'esecuzione della limitazione dei metadati.

Se il carico di lavoro incontra Successo con Avvisi sui Metadati o Successo con Limitazioni dei Metadati, è consigliabile implementare una o più delle seguenti raccomandazioni:

• Per le condivisioni file SMB SSD: abilitare la memorizzazione dei metadati nella cache.
• Suddividere il carico di lavoro tra più condivisioni di file.
• Ridurre il volume di IOPS dei metadati.

Contenuto correlato

• Monitorare File di Azure
• File di Azure riferimento ai dati di monitoraggio
• Creare avvisi di monitoraggio per File di Azure
• Monitorare le risorse di Azure con Monitoraggio di Azure
• Informazioni sulle prestazioni di File di Azure
• Risolvere i problemi di ClientOtherErrors