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

✔️ Область применения: классические общие папки SMB и NFS, созданные с помощью поставщика ресурсов Microsoft.Storage

✔️ Применяется к: общим файловым ресурсам, созданным с помощью поставщика ресурсов Microsoft.FileShares

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

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

Поддерживаемые метрики для Файлы Azure

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

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

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

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

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

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

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

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

Мониторинг производительности рабочей нагрузки

Используйте Azure Monitor для анализа нагрузок, использующих Файлы Azure. Выполните следующие действия:

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

Снимок экрана, показывающий, как выбрать пространство имен метрик Files.

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

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

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

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

Снимок экрана: доступные метрики транзакций в Azure Monitor.

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

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

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

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

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

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

Снимок экрана: метрики задержки при расположении клиента и общей папки Azure в одном регионе.

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

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

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

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

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

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

Снимок экрана: метрики использования, разделенные по имени API.

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

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

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

Хотя средние IOPS и пропускная способность дают общее представление о рабочей нагрузке, они могут скрывать всплески и пики. Подготовленные файловые ресурсы предоставляют метрики Транзакции по макс. IOPS и Пропускная способность по макс. МиБ/с, чтобы показать, каких показателей достигает ваша рабочая нагрузка при пиковых нагрузках, что позволяет точнее оценить ваши фактические требования к производительности. Использование этих метрик для анализа рабочей нагрузки помогает понять фактическую производительность при масштабировании и определить базовый уровень, чтобы оценить влияние увеличения пропускной способности и числа операций ввода-вывода в секунду (IOPS) и оптимально настроить общий файловый ресурс Azure.

На следующей диаграмме показана рабочая нагрузка, создающая 2,63 миллиона транзакций в течение 1 часа. Если делить 2,63 миллиона транзакций на 3 600 секунд, средний результат составляет 730 IOPS.

Снимок экрана: транзакции, созданные рабочей нагрузкой в течение одного часа.

Сравнение среднего IOPS с транзакциями по максимальной нагрузке показывает, что при пиковой нагрузке нагрузка достигала 1 840 IOPS, что лучше отражает возможности нагрузки в масштабе.

Снимок экрана, показывающий транзакции по максимальному IOPS.

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

Снимок экрана: объединение метрик входящего трафика и исходящего трафика в один граф.

По сравнению с показателем Пропускная способность по макс. МиБ/с пиковое значение нагрузки составило 123 МиБ/с.

Снимок экрана: пропускная способность по максимальному значению MIBS.

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

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

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

Для решения этой проблемы Файлы Azure предоставляет две метаспецифические метрики для файловых ресурсов Azure:

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

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

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

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

Снимок экрана: предупреждения метаданных по типу ответа.

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