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

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

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

Применяется к

Тип общей папки SMB NFS
Стандартные общие папки (GPv2), LRS/ZRS Да Нет
Стандартные общие папки (GPv2), GRS/GZRS Да Нет
Общие папки уровня "Премиум" (FileStorage), LRS/ZRS Да Да

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: выбор пространства имен метрик файлов.

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

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

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

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

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

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

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

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

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

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

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

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

Другой индикатор задержки, чтобы искать, что может предложить проблему является увеличение частоты или аномальных пиков в задержке сервера успешного выполнения. Обычно это связано с регулированием из-за превышения ограничений масштабирования Файлы Azure для стандартных файловых ресурсов или недостаточно подготовленного Файлы Azure premium Share.

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

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

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

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

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

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

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

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

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

Так как общие папки Azure Premium выставляются в подготовленной модели, в которой каждый ГиБ емкости хранилища, которую вы подготавливаете, дает вам больше операций ввода-вывода в секунду и пропускную способность, часто полезно определить максимальное количество операций ввода-вывода в секунду и пропускную способность. В то время как пропускная способность измеряет фактический объем передаваемых данных, пропускная способность относится к максимальной скорости передачи данных.

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

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

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

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

Снимок экрана: транзакции по максимальному объему операций ввода-вывода в секунду.

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

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

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

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