Устранение неполадок с пакетными конечными точками
ОБЛАСТЬ ПРИМЕНЕНИЯ:Расширение машинного обучения Azure CLI версии 2 (current)Python SDK azure-ai-ml версии 2 (current)
В этой статье приводятся рекомендации по устранению распространенных ошибок при использовании конечных точек пакетной службы для оценки пакетной службы в Машинное обучение Azure. В следующих разделах описывается анализ журналов пакетной оценки для выявления возможных проблем и неподдерживаемых сценариев. Вы также можете просмотреть рекомендуемые решения для устранения распространенных ошибок.
Получение журналов для заданий пакетной оценки
После вызова конечной точки пакетной службы с помощью Azure CLI или REST API задание пакетной оценки выполняется асинхронно. Существует два варианта получения журналов для задания пакетной оценки:
Вариант 1. Потоковая передача журналов заданий в локальную консоль. Поток передаются только журналы в папке azureml-logs .
Выполните следующую команду, чтобы передавать журналы, созданные системой, в консоль. Замените
<job_name>
параметр именем задания пакетной оценки:az ml job stream --name <job_name>
Вариант 2. Просмотр журналов заданий в Студия машинного обучения Azure.
Выполните следующую команду, чтобы получить ссылку на задание для использования в студии. Замените
<job_name>
параметр именем задания пакетной оценки:az ml job show --name <job_name> --query services.Studio.endpoint -o tsv
Откройте ссылку на задание в студии.
В графе задания выберите шаг пакетной обработки.
На вкладке "Выходные данные и журналы" выберите один или несколько журналов для проверки.
Просмотр файлов журнала
Машинное обучение Azure предоставляет несколько типов файлов журналов и других файлов данных, которые можно использовать для устранения неполадок задания пакетной оценки.
Две папки верхнего уровня для журналов пакетной оценки — это журналы и журналы azureml. Сведения из контроллера, запускающего скрипт оценки, хранятся в файле ~/azureml-logs/70_driver_log.txt .
Изучение высокоуровневых сведений
Распределенный характер заданий пакетной оценки приводит к журналам из разных источников, но два объединенных файла предоставляют высокоуровневую информацию:
Файл | Description |
---|---|
~/logs/job_progress_overview.txt | Предоставляет высокоуровневую информацию о текущем количестве мини-пакетов (также известных как задачи) и текущем количестве обработанных мини-пакетов. Так как обработка мини-пакетов завершается, журнал записывает результаты задания. Если задание завершается сбоем, в журнале отображается сообщение об ошибке и где начать устранение неполадок. |
~/logs/sys/master_role.txt | Предоставляет основной узел (также известный как оркестратор) выполняемого задания. Этот журнал содержит сведения о создании задачи, мониторинге хода выполнения и результатах задания. |
Проверка данных трассировки стека для ошибок
Другие файлы предоставляют сведения о возможных ошибках в скрипте:
Файл | Description |
---|---|
~/logs/user/error.txt | Содержит сводку ошибок в скрипте. |
~/logs/user/error/* | Предоставляет полные трассировки исключений, создаваемых при загрузке и запуске скрипта записи. |
Проверка журналов процессов на узел
Для полного понимания того, как каждый узел выполняет скрипт оценки, изучите отдельные журналы процессов для каждого узла. Журналы процессов хранятся в папке ~/logs/sys/node и группируются по рабочим узлам.
Папка содержит вложенную <папку ip_address/, содержащую <файл process_name>>.txt с подробными сведениями о каждом мини-пакете. Содержимое папки обновляется при выборе рабочей роли или завершении мини-пакета. Для каждого мини-пакета файл журнала включает:
- IP-адрес и идентификатор процесса (PID) рабочего процесса.
- Общее число элементов, число успешно обработанных элементов и число элементов, для которых возник сбой.
- Время начала, продолжительность, время обработки и время запуска метода.
Проверка периодических проверок на узел
Вы также можете просмотреть результаты периодических проверок использования ресурсов для каждого узла. Файлы журнала и файлы установки хранятся в папке ~/logs/perf .
--resource_monitor_interval
Используйте параметр для изменения интервала проверки в секундах:
- Используется по умолчанию: интервал по умолчанию составляет 600 секунд (приблизительно 10 минут).
- Остановить проверки: задайте значение 0, чтобы остановить выполнение проверок на узле.
Папка содержит вложенную папку <ip_address>/ вложенную папку для каждого мини-пакета. Содержимое папки обновляется при выборе рабочей роли или завершении мини-пакета. Для каждого мини-пакета папка содержит следующие элементы:
Файл или папка | Description |
---|---|
ОС/ | Хранит сведения обо всех выполняемых процессах в узле. Одна проверка запускает команду операционной системы и сохраняет результат в файл. В системе Linux используется команда ps . Папка содержит следующие элементы: - %Y%m%d%H: вложенная папка, содержащая один или несколько файлов проверки процесса. Имя вложенной папки — это дата создания и время проверки (год, месяц, день, час). processes_%M: файл в подпапке. В файле отображаются сведения о проверке процесса. Имя файла заканчивается временем проверки (минута) относительно времени создания проверки. |
node_disk_usage.csv | Показывает подробное использование диска узла. |
node_resource_usage.csv | Предоставляет обзор использования ресурсов узла. |
processes_resource_usage.csv | Предоставляет обзор использования ресурсов для каждого процесса. |
Добавление ведения журнала в скрипт оценки
В скрипте оценки можно использовать средства ведение журналов Python. Эти журналы хранятся в файле logs/user/stdout/<node_id>/process<>.stdout.txt.
В следующем коде показано, как добавить ведение журнала в скрипт:
import argparse
import logging
# Get logging_level
arg_parser = argparse.ArgumentParser(description="Argument parser.")
arg_parser.add_argument("--logging_level", type=str, help="logging level")
args, unknown_args = arg_parser.parse_known_args()
print(args.logging_level)
# Initialize Python logger
logger = logging.getLogger(__name__)
logger.setLevel(args.logging_level.upper())
logger.info("Info log statement")
logger.debug("Debug log statement")
Устранение распространенных ошибок
В следующих разделах описываются распространенные ошибки, которые могут возникать во время разработки и потребления пакетной конечной точки, а также действия по разрешению.
Нет модуля с именем Azureml
Машинное обучение Azure пакетное развертывание требует пакета azureml-core в установке.
Сообщение в журнале: "Без модуля с именем azureml
".
Причина: azureml-core
пакет, как представляется, отсутствует в установке.
Решение. Добавьте пакет в azureml-core
файл зависимостей conda.
Нет выходных данных в файле прогнозов
Пакетное развертывание ожидает, что пустая папка будет хранить файл predictions.csv . Когда развертывание обнаруживает существующий файл в указанной папке, процесс не заменяет содержимое файла новым выходным данным или создает новый файл с результатами.
Сообщение зарегистрировано: нет определенного сообщения в журнале.
Причина. Пакетное развертывание не может перезаписать существующий файл predictions.csv .
Решение. Если процесс указывает расположение выходной папки для прогнозов, убедитесь, что папка не содержит существующий файл predictions.csv .
Время ожидания пакетного процесса
Пакетное timeout
развертывание использует значение, чтобы определить, сколько времени должно ожидать завершения каждого пакетного процесса. Если выполнение пакета превышает указанное время ожидания, пакетное развертывание прерывает процесс.
Прерванные процессы извлекаются до максимального числа попыток, указанных в значении max_retries
. Если ошибка времени ожидания возникает при каждой попытке повторных попыток, задание развертывания завершается сбоем.
Вы можете настроить timeout
и max_retries
свойства для каждого развертывания с retry_settings
помощью параметра.
Сообщение в журнале: "Обновление хода выполнения не выполняется в [число] секундах. Обновление хода выполнения в этой проверке не выполняется. Подождите [число] секунд с момента последнего обновления".
Причина. Выполнение пакетной службы превышает указанное время ожидания и максимальное количество попыток повторных попыток. Это действие соответствует сбою run()
функции в скрипте записи.
Решение. Увеличьте timeout
значение развертывания. По умолчанию значение равно 30, timeout
а max_retries
значение равно 3. Чтобы определить подходящее timeout
значение для развертывания, рассмотрите количество файлов для обработки каждого пакета и размеров файлов. Вы можете уменьшить количество файлов для обработки и создания мини-пакетов меньшего размера. Такой подход приводит к более быстрому выполнению.
Исключение в ScriptExecution.StreamAccess.Authentication
Для успешного пакетного развертывания управляемое удостоверение для вычислительного кластера должно иметь разрешение на подключение хранилища ресурсов данных. Если управляемое удостоверение имеет недостаточно разрешений, скрипт вызывает исключение. Эта ошибка также может привести к тому, что хранилище ресурсов данных не подключается.
Сообщение зарегистрировано: "ScriptExecutionException было вызвано StreamAccessException. StreamAccessException была вызвана AuthenticationException".
Причина. Вычислительный кластер, в котором выполняется развертывание, не может подключить хранилище, где находится ресурс данных. Управляемое удостоверение вычислительных ресурсов не имеет разрешений на подключение.
Решение. Убедитесь, что управляемое удостоверение, связанное с вычислительным кластером, в котором выполняется развертывание, имеет по крайней мере доступ к средству чтения данных BLOB-объектов хранилища к учетной записи хранения. Только владельцы учетных записей служба хранилища Azure могут изменить уровень доступа в портал Azure.
Сбой инициализации набора данных, не удается подключить набор данных
Для процесса пакетного развертывания требуется подключенное хранилище для ресурса данных. Если хранилище не подключается, набор данных не может быть инициализирован.
Сообщение зарегистрировано: "Сбой инициализации набора данных: UserErrorException: Сообщение: не удается подключить набор данных(ID='xxxxx-xxxx-xxxxx-xxxx', name='None', version=None). Источник набора данных либо недоступен, либо не содержит никаких данных».
Причина. Вычислительный кластер, в котором выполняется развертывание, не может подключить хранилище, где находится ресурс данных. Управляемое удостоверение вычислительных ресурсов не имеет разрешений на подключение.
Решение. Убедитесь, что управляемое удостоверение, связанное с вычислительным кластером, в котором выполняется развертывание, имеет по крайней мере доступ к средству чтения данных BLOB-объектов хранилища к учетной записи хранения. Только владельцы учетных записей служба хранилища Azure могут изменить уровень доступа в портал Azure.
dataset_param не имеет указанного значения или значения по умолчанию
Во время пакетного развертывания узел набора данных ссылается на dataset_param
параметр. Для продолжения развертывания параметр должен иметь назначенное значение или указанное значение по умолчанию.
Сообщение в журнале: "Узел набора данных [код] ссылается на параметр dataset_param
, который не имеет указанного значения или значения по умолчанию".
Причина. Входной ресурс данных, предоставленный пакетной конечной точке, не поддерживается.
Решение. Убедитесь, что скрипт развертывания предоставляет входные данные, поддерживаемые для конечных точек пакетной службы.
Сбой пользовательской программы, выполнение завершается ошибкой
Во время выполнения скрипта для пакетного развертывания, если init()
ошибка или run()
функция возникает, пользовательская программа или запуск могут завершиться ошибкой. Сведения об ошибке можно просмотреть в созданном файле журнала.
Сообщение в журнале: "Сбой пользовательской программы с исключением: сбой выполнения. Дополнительные сведения см. в журналах. Вы можете проверить журналы/readme.txt для макета журналов".
Причина: или init()
run()
функция создает ошибку во время выполнения скрипта оценки.
Решение. Выполните следующие действия, чтобы найти сведения о сбоях функций:
В Студия машинного обучения Azure перейдите на сбой выполнения задания пакетного развертывания и перейдите на вкладку "Выходные данные + журналы".
Откройте файл журналов>ошибок><пользователя>node_identifier>>номер> процесса<.txt.
Найдите сообщение об ошибке, созданное или
run()
функциейinit()
.
ValueError: нет объектов для объединения
Для успешного выполнения пакетного развертывания каждый файл в мини-пакете должен быть допустимым и реализовать поддерживаемый тип файла. Помните, что модели MLflow поддерживают только подмножество типов файлов. Дополнительные сведения см. в разделе "Рекомендации" при развертывании в пакетном выводе.
Сообщение зарегистрировано: "ValueError: нет объектов для объединения".
Причина. Все файлы в созданном мини-пакете повреждены или неподдерживаемые типы файлов.
Решение. Выполните следующие действия, чтобы найти сведения о неудачных файлах:
В Студия машинного обучения Azure перейдите на сбой выполнения задания пакетного развертывания и перейдите на вкладку "Выходные данные + журналы".
Откройте журналы пользователей >>stdout><node_identifier>>номер> процесса<.txt.
Найдите записи, описывающие сбой ввода файла, например ERROR:azureml:Error processing input file.
Если тип файла не поддерживается, просмотрите список поддерживаемых файлов. Возможно, потребуется изменить тип файла входных данных или настроить развертывание, предоставив скрипт оценки. Дополнительные сведения см. в разделе Использование моделей MLflow со скриптом оценки.
Не удалось мини-пакет
Для процесса развертывания пакетной службы требуется пакетная конечная точка для предоставления данных в формате, ожидаемом функцией run()
. Если входные файлы повреждены или несовместимы с сигнатурой модели, run()
функция не возвращает успешный мини-пакет.
Сообщение в журнале: "Не удалось получить мини-пакетный элемент, возвращенный из run(). Проверьте "ответ: run()" в https://aka.ms/batch-inference-documentation
."
Причина. Конечная точка пакетной службы не смогла предоставить данные в ожидаемом формате run()
функции. Эта проблема может привести к считываемым или несовместимости входных данных с сигнатурой модели (MLflow).
Решение. Выполните следующие действия, чтобы найти сведения о неудачном мини-пакете:
В Студия машинного обучения Azure перейдите на сбой выполнения задания пакетного развертывания и перейдите на вкладку "Выходные данные + журналы".
Откройте журналы пользователей >>stdout><node_identifier>>номер> процесса<.txt.
Найдите записи, описывающие сбой входного файла для мини-пакета, например "Ошибка обработки входного файла". Сведения должны описать, почему входной файл не может быть правильно прочитан.
Аудитория или служба не разрешены
Токены Microsoft Entra выдаются для определенных действий, определяющих разрешенных пользователей (аудиторию), службу и ресурсы. Маркер проверки подлинности для REST API пакетной конечной точки должен иметь resource
значение параметра https://ml.azure.com
.
Сообщение зарегистрировано: нет определенного сообщения в журнале.
Причина. Вы пытаетесь вызвать REST API для конечной точки пакетной службы и развертывания с маркером, выданным для другой аудитории или службы.
Решение. Выполните следующие действия, чтобы устранить эту проблему проверки подлинности:
При создании маркера проверки подлинности для REST API пакетной конечной точки задайте
resource
для параметра значениеhttps://ml.azure.com
.Обратите внимание, что этот ресурс отличается от ресурса, используемого для управления конечной точкой из REST API. Все ресурсы Azure (включая конечные точки пакетной службы) используют ресурс
https://management.azure.com
для управления.При вызове REST API для пакетной конечной точки и развертывания будьте осторожны, чтобы использовать маркер, выданный для REST API пакетной конечной точки, а не маркер, выданный для другой аудитории или службы. В каждом случае убедитесь, что вы используете правильный URI ресурса.
Если вы хотите использовать API управления и API вызова заданий одновременно, вам потребуется два маркера. Дополнительные сведения см. в разделе "Проверка подлинности" в конечных точках пакетной службы (REST).
Нет допустимых развертываний для маршрутизации
Для успешного развертывания пакетной службы конечная точка пакетной службы должна иметь по крайней мере один допустимый маршрут развертывания. Стандартный метод — определить пакетное развертывание по умолчанию с помощью defaults.deployment_name
параметра.
Сообщение занеслось в журнал: "Допустимые развертывания для маршрутизации не будут выполняться. Убедитесь, что конечная точка имеет по крайней мере одно развертывание с положительными значениями веса или использует определенный заголовок развертывания для маршрутизации".
Причина. Стандартное пакетное развертывание не задано правильно.
Решение. Используйте один из следующих методов для устранения проблемы маршрутизации:
Подтвердите, что
defaults.deployment_name
параметр определяет правильное пакетное развертывание по умолчанию. Дополнительные сведения см. в разделе "Обновление пакетного развертывания по умолчанию".Определите маршрут с заголовком для конкретного развертывания.
Ограничения и неподдерживаемые сценарии
При разработке решений для развертывания машинного обучения, использующих конечные точки пакетной службы, помните, что некоторые конфигурации и сценарии не поддерживаются. В следующих разделах определены неподдерживаемые рабочие области и вычислительные ресурсы, а также недопустимые типы входных файлов.
Неподдерживаемые конфигурации рабочей области
Следующие конфигурации рабочей области не поддерживаются для пакетного развертывания:
- Рабочие области, настроенные с помощью реестров контейнеров Azure с включенной функцией карантина
- Рабочие области с ключами, управляемыми клиентом
Неподдерживаемые конфигурации вычислений
Следующие конфигурации вычислений не поддерживаются для пакетного развертывания.
- Кластеры Azure ARC Kubernetes
- Подробный запрос ресурсов (память, виртуальный ЦП, GPU) для кластеров Azure Kubernetes (можно запросить только количество экземпляров).
Неподдерживаемые типы входных файлов
Для пакетного развертывания не поддерживаются следующие типы входных файлов:
- Табличные наборы данных (V1)
- Папки и наборы данных файлов (версия 1)
- MLtable (версия 2)