Использование Azure Monitor для анализа метрик файлов Azure

Понимание того, как отслеживать производительность общей папки, критически важно для обеспечения максимально эффективной работы приложения. В этой статье показано, как использовать Azure Monitor для анализа метрик файлов Azure, таких как доступность, задержка и использование.

Дополнительные сведения о данных мониторинга, которые можно собирать для файлов Azure и о том, как их использовать, см. в разделе Мониторинг файлов Azure.

Применимо к

Модель управления	Модель выставления счетов	Уровень медиа	Избыточность
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Локальное (LRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Зона (ZRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	Гео (GRS)
Microsoft.Storage	Настроенная версия 2	HDD (стандартный)	GeoZone (GZRS)
Microsoft.Storage	Настроенная версия v1	SSD (премиум)	Локальное (LRS)
Microsoft.Storage	Настроенная версия v1	SSD (премиум)	Зона (ZRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Локальное (LRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Зона (ZRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	Гео (GRS)
Microsoft.Storage	Оплата по мере использования	HDD (стандартный)	GeoZone (GZRS)

Поддерживаемые метрики

Метрики для Azure Files находятся в следующих пространствах имен:

Microsoft.Storage/storageAccounts (хранилища аккаунтов)
Microsoft.Storage/storageAccounts/файловыеСервисы

Для получения списка доступных метрик для Azure Files см. справочник по данным мониторинга Azure Files.

См. статью Поддерживаемые метрики Azure Monitor для получения списка всех поддерживаемых метрик Azure Monitor, включая Azure Files.

Просмотр данных метрик файлов Azure

Метрики файлов Azure можно просматривать с помощью портала Azure, PowerShell, Azure CLI или .NET.

Метрики для службы хранилища Azure можно анализировать с помощью метрик из других служб Azure с помощью обозревателя метрик Azure Monitor. Откройте обозреватель метрик, выбрав метрики в меню Azure Monitor . Дополнительные сведения об использовании этого средства см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.

Для метрик с поддержкой измерений можно выполнить фильтрацию по нужному значению измерения. Полный список измерений, поддерживаемых службой хранилища Azure, см. в разделе Измерения метрик.

Перечислите определение метрики

Вы можете перечислить определения метрик вашей учетной записи хранения или службы Azure Files. Используйте командлет Get-AzMetricDefinition.

В этом примере замените заполнитель <resource-ID> идентификатором ресурса аккаунта хранения целиком или идентификатором ресурса службы файлов Azure. Эти ИД ресурса можно найти на странице свойств учетной записи хранения на портале Azure.

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

Чтение значений метрик

Вы можете считывать значения метрик уровня учетной записи хранения или службы файлов Azure. Используйте командлет Get-AzMetric.

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

Чтение значений метрик по измерениям

Если метрика поддерживает измерения, можно считывать значения метрик и фильтровать их с помощью значений измерений. Используйте командлет 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"

Отображение определения метрик на уровне учетной записи

Вы можете перечислить определения метрик вашей учетной записи хранения или службы Azure Files. Используйте команду az monitor metrics list-definitions.

   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 Monitor предоставляет пакет SDK для .NET для считывания определения и значений метрик. Пример кода демонстрирует использование пакета 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 Monitor можно использовать для анализа рабочих нагрузок, использующих файлы Azure. Выполните следующие действия.

Перейдите к учетной записи хранения в портал Azure.
В меню службы в разделе "Мониторинг" выберите "Метрики".
В пространстве имен метрик выберите "Файл".

Теперь можно выбрать метрику в зависимости от того, что вы хотите отслеживать.

Отслеживание доступности

В Azure Monitor метрика доступности может оказаться полезной, если что-то явно не так с точки зрения приложения или пользователя или при устранении неполадок с оповещениями.

При использовании этой метрики с файлами Azure важно всегда просматривать агрегирование как среднее в отличие от максимального или минимального. Использование Среднее показывает, какой процент ваших запросов содержит ошибки, и находятся ли они в пределах SLA для файлов Azure.

Мониторинг задержки

Двумя наиболее важными показателями задержки являются задержка успешного выполнения от конца до конца и задержка успешного выполнения сервера. Это идеальные метрики для выбора при запуске любого исследования производительности. Среднее — рекомендуемая агрегирование. Как упоминалось ранее, Макс и Мин иногда могут вводить в заблуждение.

На следующих диаграммах синяя линия показывает, сколько времени уходит на общую задержку (задержка успешного выполнения E2E), а розовая линия — время, затраченное только на службу Azure Files (задержка сервера успешного выполнения).

На этой диаграмме показан локальный клиент с монтированной файловой папкой Azure, представляющей, например, типичного пользователя, подключающегося из удаленного места. Физическое расстояние между клиентом и регионом Azure тесно связано с соответствующей задержкой на стороне клиента, которая представляет разницу между задержкой E2E и сервером.

Для сравнения на следующей диаграмме показана ситуация, когда клиент и общая папка Azure находятся в одном регионе. Обратите внимание, что задержка на стороне клиента составляет только 0,17 мс по сравнению с 43,9 мс в первой диаграмме. Это иллюстрирует, почему минимизация задержки на стороне клиента является императивной для достижения оптимальной производительности.

Другим индикатором задержки, на который стоит обратить внимание и который может свидетельствовать о проблеме, является увеличение частоты или появление аномальных пиков в показателях задержки успешного выполнения сервером. Это обычно связано с регулированием из-за превышения предоставленного лимита для предоставленной общей папки (или общего ограничения масштабирования для файловой папки с оплатой по мере использования). Сведения о выставлении счетов за файлы Azure и целевые показатели масштабируемости и производительности для файлов Azure.

Дополнительные сведения см. в разделе "Устранение неполадок с высокой задержкой, низкой пропускной способностью или низким числом операций ввода-вывода в секунду".

Мониторинг использования

Метрики использования, которые измеряют объем передаваемых (пропускной способности) или операций, обслуживаемых (IOPS), часто используются для определения объема операций, выполняемых приложением или рабочей нагрузкой. Метрики транзакций могут определять количество операций или запросов к службе файлов Azure в течение различных периодов детализации.

Если вы используете метрики Egress или Ingress для определения объема исходящих или входящих данных, используйте агрегирование сумм, чтобы определить общий объем данных, передаваемых в файловое хранилище и из него, с детализацией от 1 минуты до 1 дня. Другие агрегации, такие как среднее, максимум и минимум, отображают только значение размер отдельной операции ввода-вывода. Именно поэтому большинство клиентов обычно видят 1 МиБ при использовании агрегирования Max . Хотя это может быть полезно для понимания размера крупнейшего, наименьшего или даже среднего размера ввода-вывода, невозможно отобразить распределение размера ввода-вывода, созданного шаблоном использования рабочей нагрузки.

Вы также можете выбрать применение разделения на типы ответов (успешное выполнение, сбои, ошибки) или операции API (чтение, запись, создание, закрытие), чтобы отобразить дополнительные сведения, как показано на следующей диаграмме.

Чтобы определить среднее число операций ввода-вывода в секунду для рабочей нагрузки, сначала определите общее количество транзакций за минуту, а затем разделите это число на 60 секунд. Например, 120 000 транзакций в 1 минуту / 60 секунд = 2000 средних операций ввода-вывода в секунду.

Чтобы определить среднюю пропускную способность для рабочей нагрузки, возьмите общий объем передаваемых данных, объединяя метрики входящего трафика и исходящего трафика (общая пропускная способность) и разделяя их на 60 секунд. Например, общая пропускная способность 1 ГиБ в течение 1 минуты / 60 секунд = 17 МиБ средней пропускной способности.

Мониторинг использования по максимальному объему операций ввода-вывода в секунду и пропускной способности (только подготовленный)

Подготовленные общие папки предоставляют метрики операций ввода-вывода по Max IOPS и пропускной способности по Max MiB/s для отображения результатов вашей рабочей нагрузки в пиковые периоды. Используя эти метрики для анализа рабочей нагрузки, вы можете понять истинные возможности в масштабе, а также установить базовый уровень, чтобы понять влияние увеличения пропускной способности и количества операций ввода-вывода в секунду для оптимальной настройки вашей общей папки Azure.

На следующей диаграмме показана рабочая нагрузка, создающая 2,63 миллиона транзакций в течение 1 часа. Когда мы делим 2,63 миллиона транзакций на 3600 секунд, мы получаем в среднем 730 операций ввода-вывода в секунду.

Теперь при сравнении среднего числа операций ввода-вывода в секунду с транзакциями по максимальному объему операций ввода-вывода в секунду мы видим, что при пиковой нагрузке мы достигали 1840 операций ввода-вывода в секунду, что является лучшим представлением способности рабочей нагрузки в масштабе.

Выберите "Добавить метрику", чтобы объединить метрикивходящего трафика и исходящего трафика на одном графе. Это показывает, что 76,2 ГиБ (78 028 МиБ) был передан более одного часа, что дает нам среднюю пропускную способность 21,67 МиБ за тот же час.

В сравнении с пропускной способностью по max MiB/с, мы достигли 123 МиБ/с на пике.

Мониторинг использования на основе операций ввода-вывода в секунду метаданных

В общих папках Azure масштабируются до 12K IOPS метаданных. Это означает, что выполнение рабочей нагрузки, насыщенной метаданными, которая включает большой объем операций открытия, закрытия или удаления, повышает вероятность ограничения операций ввода-вывода метаданных. Это ограничение не зависит от общего объема выделенных операций ввода-вывода в секунду.

Так как две рабочие нагрузки с большими метаданными не соответствуют одному и тому же шаблону использования, клиентам может быть сложно заранее отслеживать рабочую нагрузку и задавать точные оповещения.

Для решения этой проблемы мы представили две метрики, относящиеся к метаданным для общих папок Azure:

Успешное выполнение с предупреждением метаданных: Указывает, что количество операций ввода-вывода в секунду метаданных приближается к их ограничению и может регулироваться, если они остаются высокими или продолжают увеличиваться. Увеличение объема или частоты этих предупреждений свидетельствует о увеличении риска регулирования метаданных.
Успешное выполнение ограничения метаданных: Указывает, что количество операций ввода-вывода в секунду метаданных превысило допустимую нагрузку файловой общей папки, что привело к ограничению. Хотя IOPS операции никогда не завершаются ошибкой и в конечном итоге завершаются успешно после повторных попыток, задержка возникает во время ограничения.

Чтобы просмотреть в Azure Monitor, выберите метрику транзакций и примените разделение на типы ответов. Типы ответов метаданных отображаются в выпадающем списке только в том случае, если действие происходит в течение выбранного интервала времени.

Следующая диаграмма иллюстрирует рабочую нагрузку, которая испытала внезапное увеличение операций ввода-вывода в секунду метаданных (транзакций), вызывая успешное выполнение с предупреждениями о метаданных, что указывает на риск дросселирования метаданных. В этом примере рабочая нагрузка впоследствии сократила его объем транзакций, предотвращая регулирование метаданных.

Если рабочая нагрузка сталкивается с успехом с предупреждениями о метаданных или успехом с регулированием метаданных, рассмотрите возможность реализации одной или нескольких следующих рекомендаций:

Для общих папок SSD SMB включите кэширование метаданных.
Распределять рабочую нагрузку (сегментировать) между несколькими общими папками.
Снизьте количество операций ввода-вывода метаданных в секунду.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-06-12