Share via

Resolver problemas com pontos finais em lote

  • Artigo

APLICA-SE A:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (current)

Saiba como solucionar problemas e resolver erros comuns que você pode encontrar ao usar pontos de extremidade em lote para pontuação em lote. Neste artigo você aprende:

Noções básicas sobre logs de um trabalho de pontuação em lote

Obter registos

Depois de invocar um ponto de extremidade em lote usando a CLI ou REST do Azure, o trabalho de pontuação em lote será executado de forma assíncrona. Há duas opções para obter os logs para um trabalho de pontuação em lote.

Opção 1: Transmitir logs para o console local

Você pode executar o seguinte comando para transmitir logs gerados pelo sistema para o console. Somente os azureml-logs logs na pasta são transmitidos.

az ml job stream --name <job_name>

Opção 2: Ver registos no estúdio

Para obter o link para a execução em estúdio, execute:

az ml job show --name <job_name> --query services.Studio.endpoint -o tsv
  1. Abra o trabalho no estúdio usando o valor retornado pelo comando acima.
  2. Escolha a pontuação em lote
  3. Abra a guia Saídas + logs
  4. Escolha um ou mais registos que pretende rever

Compreender a estrutura do log

Há duas pastas azureml-logs de log de nível superior e logs.

O arquivo ~/azureml-logs/70_driver_log.txt contém informações do controlador que inicia o script de pontuação.

Devido à natureza distribuída dos trabalhos de pontuação em lote, há logs de várias fontes diferentes. No entanto, dois arquivos combinados são criados que fornecem informações de alto nível:

  • ~/logs/job_progress_overview.txt: Este arquivo fornece informações de alto nível sobre o número de minilotes (também conhecidos como tarefas) criados até agora e o número de minilotes processados até agora. À medida que os minilotes terminam, o log registra os resultados do trabalho. Se o trabalho falhar, ele mostra a mensagem de erro e onde iniciar a solução de problemas.

  • ~/logs/sys/master_role.txt: Este arquivo fornece a visualização do nó principal (também conhecido como orquestrador) do trabalho em execução. Este log fornece informações sobre a criação de tarefas, monitoramento de progresso, o resultado do trabalho.

Para uma compreensão concisa dos erros em seu script há:

  • ~/logs/user/error.txt: Este arquivo tentará resumir os erros em seu script.

Para obter mais informações sobre erros em seu script, há:

  • ~/logs/user/error/: Este arquivo contém rastreamentos de pilha completa de exceções lançadas durante o carregamento e execução do script de entrada.

Quando você precisar de uma compreensão completa de como cada nó executou o script de pontuação, examine os logs de processo individuais para cada nó. Os logs de sys/node processo podem ser encontrados na pasta, agrupados por nós de trabalho:

  • ~/logs/sys/node/<ip_address>/<process_name>.txt: Este arquivo fornece informações detalhadas sobre cada minilote à medida que é coletado ou concluído por um trabalhador. Para cada minilote, este ficheiro inclui:

    • O endereço IP e o PID do processo de trabalho.
    • O número total de itens, o número de itens processados com êxito e o número de itens com falha.
    • A hora de início, duração, tempo do processo e tempo do método de execução.

Você também pode exibir os resultados de verificações periódicas do uso de recursos para cada nó. Os arquivos de log e os arquivos de instalação estão nesta pasta:

  • ~/logs/perf: Defina --resource_monitor_interval para alterar o intervalo de verificação em segundos. O intervalo padrão é 600, que é de aproximadamente 10 minutos. Para interromper o monitoramento, defina o valor como 0. Cada <ip_address> pasta inclui:

    • os/: Informações sobre todos os processos em execução no nó. Uma verificação executa um comando do sistema operacional e salva o resultado em um arquivo. No Linux, o comando é ps.
      • %Y%m%d%H: O nome da subpasta é o tempo até a hora.
        • processes_%M: O ficheiro termina com o minuto da hora de verificação.
    • node_disk_usage.csv: Uso detalhado do disco do nó.
    • node_resource_usage.csv: Visão geral do uso de recursos do nó.
    • processes_resource_usage.csv: Visão geral do uso de recursos de cada processo.

Como fazer login no script de pontuação

Você pode usar o log Python em seu script de pontuação. Os logs são armazenados no logs/user/stdout/<node_id>/processNNN.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")

Problemas comuns

A seção a seguir contém problemas e soluções comuns que você pode ver durante o desenvolvimento e consumo de pontos finais em lote.

Nenhum módulo chamado 'azureml'

Mensagem registada: No module named 'azureml'.

Motivo: as implantações em lote do Azure Machine Learning exigem que o pacote azureml-core seja instalado.

Solução: Adicione azureml-core ao seu arquivo de dependências conda.

A saída já existe

Motivo: a Implantação em Lote do Azure Machine Learning não pode substituir o predictions.csv arquivo gerado pela saída.

Solução: Se for indicado um local de saída para as previsões, verifique se o caminho leva a um arquivo inexistente.

A função run() no script de entrada tinha tempo limite para [número] vezes

Mensagem registada: No progress update in [number] seconds. No progress update in this check. Wait [number] seconds since last update.

Motivo: as implantações em lote podem ser configuradas com um timeout valor que indica a quantidade de tempo que a implantação deve aguardar que um único lote seja processado. Se a execução do lote demorar mais do que esse valor, a tarefa será anulada. As tarefas anuladas podem ser repetidas até um máximo de vezes que também podem ser configuradas. Se ocorrer em timeout cada nova tentativa, o trabalho de implantação falhará. Essas propriedades podem ser configuradas para cada implantação.

Solução: aumente o timemout valor da implantação atualizando-a. Essas propriedades são configuradas no parâmetro retry_settings. Por padrão, a timeout=30 e retries=3 está configurado. Ao decidir o valor do timeout, leve em consideração o número de arquivos que estão sendo processados em cada lote e o tamanho de cada um desses arquivos. Você também pode diminuí-los para contabilizar mais mini-lotes de tamanho menor e, portanto, mais rápido para executar.

ScriptExecution.StreamAccess.Authentication

Mensagem registrada: ScriptExecutionException foi causada por StreamAccessException. StreamAccessException foi causada por AuthenticationException.

Motivo: o cluster de computação onde a implantação está sendo executada não pode montar o armazenamento onde o ativo de dados está localizado. A identidade gerenciada da computação não tem permissões para executar a montagem.

Soluções: Certifique-se de que a identidade associada ao cluster de computação em que a implantação está sendo executada tenha, pelo menos , acesso ao Leitor de Dados de Blob de Armazenamento à conta de armazenamento. Apenas os proprietários de contas de armazenamento podem alterar o seu nível de acesso através do portal do Azure.

Falha na inicialização do conjunto de dados

Mensagem registrada: Falha na inicialização do conjunto de dados: UserErrorException: Mensagem: Não é possível montar Dataset(id='xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', name='None', version=None). A fonte do conjunto de dados não está acessível ou não contém quaisquer dados.

Motivo: o cluster de computação onde a implantação está sendo executada não pode montar o armazenamento onde o ativo de dados está localizado. A identidade gerenciada da computação não tem permissões para executar a montagem.

Soluções: Certifique-se de que a identidade associada ao cluster de computação em que a implantação está sendo executada tenha, pelo menos , acesso ao Leitor de Dados de Blob de Armazenamento à conta de armazenamento. Apenas os proprietários de contas de armazenamento podem alterar o seu nível de acesso através do portal do Azure.

Data set node [code] referencia parâmetro dataset_param que não tem um valor especificado ou um valor padrão

Mensagem registrada: nó do conjunto de dados [código] referencia parâmetro dataset_param que não tem um valor especificado ou um valor padrão.

Motivo: o ativo de dados de entrada fornecido ao ponto de extremidade em lote não é suportado.

Solução: Certifique-se de que está a fornecer uma entrada de dados suportada para pontos finais em lote.

O programa de usuário falhou com exceção: Falha na execução, verifique os logs para obter detalhes

Mensagem registrada: O programa de usuário falhou com exceção: Falha na execução, verifique os logs para obter detalhes. Você pode verificar logs/readme.txt para o layout dos logs.

Motivo: houve um erro ao executar a init() função ou run() do script de pontuação.

Solução: Vá para Saídas + Logs e abra o arquivo em logs > user > error > 10.0.0.X > process000.txt. Você vê a mensagem de init() erro gerada pelo método ou run() .

ValueError: Nenhum objeto para concatenar

Mensagem registrada: ValueError: Nenhum objeto a ser concatenado.

Motivo: Todos os arquivos no minilote gerado são corrompidos ou tipos de arquivo não suportados. Lembre-se de que os modelos MLflow suportam um subconjunto de tipos de arquivo, conforme documentado em Considerações ao implantar na inferência em lote.

Solução: Vá para o arquivo logs/usr/stdout/<process-number>/process000.stdout.txt e procure entradas como ERROR:azureml:Error processing input file. Se o tipo de ficheiro não for suportado, reveja a lista de ficheiros suportados. Talvez seja necessário alterar o tipo de arquivo dos dados de entrada ou personalizar a implantação fornecendo um script de pontuação, conforme indicado em Usando modelos MLflow com um script de pontuação.

Não há nenhum item de mini lote bem-sucedido retornado de run()

Mensagem registrada: Não há nenhum item de mini lote bem-sucedido retornado de run(). Por favor, verifique 'response: run()' em https://aka.ms/batch-inference-documentation.

Motivo: O ponto de extremidade em lote não conseguiu fornecer dados no formato esperado para o run() método. Pode ser devido a arquivos corrompidos sendo lidos ou incompatibilidade dos dados de entrada com a assinatura do modelo (MLflow).

Solução: Para entender o que pode estar acontecendo, vá para Saídas + Logs e abra o arquivo em logs > user > stdout > 10.0.0.X > process000.stdout.txt. Procure entradas de erro como Error processing input file. Você deve encontrar detalhes sobre por que o arquivo de entrada não pode ser lido corretamente.

Audiências no JWT não são permitidas

Contexto: Ao invocar um ponto de extremidade em lote usando suas APIs REST.

Motivo: o token de acesso usado para invocar a API REST para o ponto de extremidade/implantação está indicando um token emitido para um público/serviço diferente. Os tokens Microsoft Entra são emitidos para ações específicas.

Solução: Ao gerar um token de autenticação a ser usado com a API REST do ponto de extremidade em lote, verifique se o resource parâmetro está definido como https://ml.azure.com. Observe que esse recurso é diferente do recurso que você precisa indicar para gerenciar o ponto de extremidade usando a API REST. Todos os recursos do Azure (incluindo pontos de extremidade em lote) usam o recurso https://management.azure.com para gerenciá-los. Certifique-se de usar o URI de recurso correto em cada caso. Observe que, se você quiser usar a API de gerenciamento e a API de invocação de trabalho ao mesmo tempo, precisará de dois tokens. Para obter detalhes, consulte: Autenticação em pontos de extremidade de lote (REST).

Não há implantações válidas para rotas. Verifique se o ponto de extremidade tem pelo menos uma implantação com valores de peso positivos ou use um cabeçalho específico de implantação para rotear.

Motivo: a implantação em lote padrão não está definida corretamente.

Solução: verifique se a implantação em lote padrão está definida corretamente. Talvez seja necessário atualizar a implantação em lote padrão. Para obter detalhes, consulte: Atualizar a implantação em lote padrão

Limitações e cenários não suportados

Ao projetar soluções de aprendizado de máquina que dependem de pontos de extremidade em lote, algumas configurações e cenários podem não ser suportados.

Não há suporte para as seguintes configurações de espaço de trabalho:

  • Espaços de trabalho configurados com um recurso Registros de Contêiner do Azure com o recurso Quarentena habilitado.
  • Espaços de trabalho com chaves gerenciadas pelo cliente (CMK).

As seguintes configurações de computação não são suportadas:

  • Clusters Kubernetes do Azure ARC.
  • Solicitação de recurso granular (memória, vCPU, GPU) para clusters Kubernetes do Azure. Somente a contagem de instâncias pode ser solicitada.

Os seguintes tipos de entrada não são suportados:

  • Conjuntos de dados tabulares (V1).
  • Pastas e conjuntos de dados de arquivos (V1).
  • MLtable (V2).

Próximos passos