Share via


Solução de problemas de pontos de extremidade em lote

APLICA-SE A:Extensão de ML da CLI do Azure v2 (atual)SDK do Python azure-ai-ml v2 (atual)

Aprenda como solucionar problemas e erros comuns que você pode encontrar ao usar ponto 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 logs

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

Opção 1: transmitir os logs para o console local

Execute o comando a seguir para transmitir os logs gerados pelo sistema para o console. Somente os logs na pasta azureml-logs são transmitidos.

az ml job stream --name <job_name>

Opção 2: ver os logs no estúdio

Para obter o link para a execução no 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 batchscoring
  3. Abra a guia Saídas + logs
  4. Escolha um ou mais registros que deseja revisar

Noções básicas sobre a estrutura do log

Há duas pastas de log de nível superior: azureml-logs 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, são criados dois arquivos combinados que fornecem informações de alto nível:

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

  • ~/logs/sys/master_role.txt: esse arquivo fornece a exibição do nó principal (também conhecido como orquestrador) do trabalho em execução. Esse log fornece informações sobre a criação da tarefa, o monitoramento do progresso e 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 no seu script, há:

  • ~/logs/user/error/: esse arquivo contém rastreamentos de pilha completos de exceções geradas durante o carregamento e a execução do script de entrada.

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

  • ~/logs/sys/node/<ip_address>/<process_name>.txt: esse arquivo fornece informações detalhadas sobre cada minilote à medida que ele é selecionado ou concluído por um trabalho. Para cada mini-lote, esse arquivo 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, a duração, o tempo de processamento e o tempo do método de execução.

Você também pode ver os resultados de verificações periódicas do uso de recursos para cada nó. Os arquivos de log e 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 pasta <ip_address> 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 horário.
        • processes_%M: o arquivo termina com o minuto do horário 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 usar o log no script de pontuação

Use o log do Python no 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 comuns e soluções que podem ser vistas durante o desenvolvimento e o consumo do ponto de extremidade em lote.

Nenhum módulo chamado 'azureml'

Mensagem registrada: No module named 'azureml'.

Motivo: as Implantações em Lote do Azure Machine Learning exigem a instalação do pacote azureml-core.

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

A saída já existe

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

Solução: se você tiver 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 teve tempo limite para [número] vezes

Mensagem registrada: 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 valor timeout que indica o tempo que a implantação deve aguardar o processamento de um só lote. Se a execução do lote levar mais do que esse valor, a tarefa será anulada. As tarefas anuladas podem ser repetidas até um máximo de vezes, que também pode ser configurado. Se o timeout ocorrer em cada repetição, o trabalho de implantação falhará. Essas propriedades podem ser configuradas para cada implantação.

Solução: aumente o valor timemout da implantação atualizando a implantação. Essas propriedades são configuradas no parâmetro retry_settings. Por padrão, timeout=30 e retries=3 são configurados. Ao decidir o valor de 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 considerar mais minilotes de tamanho menor e, portanto, de execução mais rápida.

ScriptExecution.StreamAccess.Authentication

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

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

Soluções: verifique se a identidade associada ao cluster de computação em que sua implantação está sendo executada tem, pelo menos, acesso de Leitor de Dados de Blob de Armazenamento à conta de armazenamento. Somente os proprietários da conta de armazenamento podem alterar seu nível de acesso por meio do portal do Azure.

Falha na inicialização do conjunto de dados

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

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

Soluções: verifique se a identidade associada ao cluster de computação em que sua implantação está sendo executada tem, pelo menos, acesso de Leitor de Dados de Blob de Armazenamento à conta de armazenamento. Somente os proprietários da conta de armazenamento podem alterar seu nível de acesso por meio do portal do Azure.

O nó do conjunto de dados [código] faz referência ao parâmetro dataset_param que não tem um valor especificado ou um valor padrão

Mensagem registrada: o nó do conjunto de dados [código] faz referência ao parâmetro dataset_param que não possui um valor especificado ou um valor padrão.

Motivo: não há suporte para o ativo de dados de entrada fornecido para o ponto de extremidade em lote.

Solução: verifique se você está fornecendo uma entrada de dados com suporte para pontos de extremidade em lote.

Falha no programa de usuário 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: ocorreu um erro ao executar a função init() 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ê verá a mensagem de erro gerada pelo método init() ou run().

ValueError: nenhum objeto a ser concatenado

Mensagem registrada: ValueError: Nenhum objeto a ser concatenado.

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

Solução: Acesse o arquivo logs/usr/stdout/<process-number>/process000.stdout.txt e procure entradas como ERROR:azureml:Error processing input file. Se o tipo de arquivo não for compatível, revise a lista de arquivos compatíveis. 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 do minilote bem-sucedido retornado de run()

Mensagem registrada: não há nenhum item de minilote bem-sucedido retornado de run(). Verifique 'response: run()' em https://aka.ms/batch-inference-documentation.

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

Solução: para entender o que pode estar acontecendo, acesse 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 indica um token emitido para um público/serviço diferente. Os tokens do 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 do Lote, verifique se o parâmetro resource 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 certo 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 em lote (REST).

Nenhuma implantação válida para a qual rotear. 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: certifique-se de que a implantação em lote padrão esteja definida corretamente. Talvez seja necessário atualizar a implantação em lote padrão. Para obter detalhes, confira: Atualizar a implantação em lote padrão

Limitações e cenários sem suporte

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

As seguintes configurações de workspacenão têm suporte:

  • Workspaces configurados com uma funcionalidade habilitada de Registros de Contêiner do Azure com Quarentena.
  • Workspaces com CMK (chaves gerenciadas pelo cliente).

As seguintes configurações de computaçãonão têm suporte:

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

Os seguintes tipos de entradanão têm suporte:

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

Próximas etapas