Solução de problemas de implantação e pontuação de endpoints on-line
APLICA-SE A:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (current)
Saiba como resolver problemas comuns na implantação e pontuação de pontos de extremidade online do Azure Machine Learning.
Este documento está estruturado da forma como deve abordar a resolução de problemas:
- Utilize a implementação local para testar e depurar os modelos localmente antes de os implementar na cloud.
- Utilize registos dos contentores para ajudar a depurar os problemas.
- Compreenda os erros de implementação comuns que podem surgir e como corrigi-los.
A seção Códigos de status HTTP explica como os erros de invocação e previsão são mapeados para códigos de status HTTP ao marcar pontos de extremidade com solicitações REST.
Pré-requisitos
- Uma subscrição do Azure. Experimente a versão gratuita ou paga do Azure Machine Learning.
- CLI do Azure.
- Para a CLI v2 do Azure Machine Learning, veja Instalar, configurar e utilizar a CLI (v2).
- Para o SDK Python do Azure Machine Learning v2, veja Instalar o SDK do Azure Machine Learning v2 para Python.
Implementar localmente
A implementação local está a implementar um modelo num ambiente do Docker local. A implantação local é útil para testar e depurar antes da implantação na nuvem.
Gorjeta
Você também pode usar o pacote Python do servidor HTTP de inferência do Azure Machine Learning para depurar seu script de pontuação localmente. A depuração com o servidor de inferência ajuda você a depurar o script de pontuação antes de implantar em pontos de extremidade locais para que você possa depurar sem ser afetado pelas configurações do contêiner de implantação.
A implementação local suporta a criação, a atualização e a eliminação de pontos finais locais. Também permite invocar e obter registos do ponto final.
Para usar a implantação local, adicione --local
ao comando apropriado da CLI:
az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local
Como parte da implantação local, as seguintes etapas ocorrem:
- O Docker cria uma nova imagem de contêiner ou extrai uma imagem existente do cache local do Docker. Uma imagem existente é usada se houver uma que corresponda à parte do ambiente do arquivo de especificação.
- O Docker inicia um novo contêiner com artefatos locais montados, como arquivos de modelo e código.
Para saber mais, consulte Implantar localmente em Implantar e pontuar um modelo de aprendizado de máquina.
Gorjeta
Utilize o Visual Studio Code para testar e depurar os pontos finais localmente. Para obter mais informações, consulte Depurar pontos de extremidade online localmente no Visual Studio Code.
Instalação Conda
Geralmente, os problemas com a implantação do MLflow decorrem de problemas com a instalação do ambiente do usuário especificado no conda.yaml
arquivo.
Para depurar problemas de instalação do conda, tente as seguintes etapas:
Verifique os logs para a instalação do conda. Se o contêiner travou ou demorou muito para iniciar, é provável que a atualização do ambiente conda não tenha sido resolvida corretamente.
Instale o arquivo mlflow conda localmente com o comando
conda env create -n userenv -f <CONDA_ENV_FILENAME>
.Se houver erros localmente, tente resolver o ambiente conda e criar um funcional antes de reimplantar.
Se o contêiner falhar, mesmo que seja resolvido localmente, o tamanho da SKU usado para implantação pode ser muito pequeno.
- A instalação do pacote Conda ocorre em tempo de execução, portanto, se o tamanho da SKU for muito pequeno para acomodar todos os pacotes detalhados no
conda.yaml
arquivo de ambiente, o contêiner poderá falhar. - Uma VM Standard_F4s_v2 é um bom tamanho de SKU inicial, mas podem ser necessárias outras maiores, dependendo de quais dependências são especificadas no arquivo conda.
- Para o ponto de extremidade online do Kubernetes, o cluster do Kubernetes deve ter no mínimo 4 núcleos vCPU e 8 GB de memória.
- A instalação do pacote Conda ocorre em tempo de execução, portanto, se o tamanho da SKU for muito pequeno para acomodar todos os pacotes detalhados no
Obter registos dos contentores
Não pode obter acesso direto à VM onde o modelo está implementado. No entanto, pode obter registos de alguns dos contentores que estão em execução na VM. A quantidade de informações que você obtém depende do status de provisionamento da implantação. Se o contêiner especificado estiver em execução, você verá a saída do console; caso contrário, você receberá uma mensagem para tentar novamente mais tarde.
Há dois tipos de contêineres dos quais você pode obter os logs:
- Servidor de inferência: Os logs incluem o log do console (do servidor de inferência) que contém a saída das funções de impressão/registro do seu script de pontuação (
score.py
código). - Inicializador de armazenamento: os logs contêm informações sobre se os dados de código e modelo foram baixados com êxito para o contêiner. O contêiner é executado antes que o contêiner do servidor de inferência comece a ser executado.
Para ver a saída de log de um contêiner, use o seguinte comando da CLI:
az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100
ou
az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100
Adicione --resource-group
e --workspace-name
a esses comandos se você ainda não tiver definido esses parâmetros via az configure
.
Para ver informações sobre como definir esses parâmetros, e se você tiver valores definidos no momento, execute:
az ml online-deployment get-logs -h
Por padrão, os logs são extraídos do servidor de inferência.
Nota
Se você usar o log em Python, certifique-se de usar a ordem correta do nível de log para que as mensagens sejam publicadas nos logs. Por exemplo, INFO.
Você também pode obter logs do contêiner do inicializador de armazenamento passando –-container storage-initializer
.
Adicione --help
e/ou --debug
aos comandos para ver mais informações.
Para o ponto de extremidade online do Kubernetes, os administradores podem acessar diretamente o cluster onde você implanta o modelo, o que é mais flexível para eles verificarem o log no Kubernetes. Por exemplo:
kubectl -n <compute-namespace> logs <container-name>
Rastreamento de solicitações
Há dois cabeçalhos de rastreamento suportados:
x-request-id
está reservado para rastreamento de servidores. Substituímos esse cabeçalho para garantir que seja um GUID válido.Nota
Ao criar um tíquete de suporte para uma solicitação com falha, anexe a ID da solicitação com falha para agilizar a investigação. Como alternativa, forneça o nome da região e o nome do ponto de extremidade.
x-ms-client-request-id
está disponível para cenários de rastreamento de cliente. Este cabeçalho é limpo para aceitar apenas caracteres alfanuméricos, hífenes e sublinhados, e é truncado até um máximo de 40 caracteres.
Erros de implementação comuns
A lista a seguir é de erros comuns de implantação que são relatados como parte do status da operação de implantação:
- ImageBuildFailure
- OutOfQuota
- BadArgument
- Comum ao endpoint online gerenciado e ao endpoint online do Kubernetes
- A subscrição não existe
- A tarefa de arranque falhou devido a um erro de autorização
- A tarefa de arranque falhou devido a atribuições de funções incorretas no recurso
- Especificação de função de modelo inválida
- Não é possível transferir a imagem de contentor do utilizador
- Não é possível transferir o modelo de utilizador
- Erros limitados ao ponto de extremidade online do Kubernetes
- Comum ao endpoint online gerenciado e ao endpoint online do Kubernetes
- ResourceNotReady
- ResourceNotFound
- WorkspaceManagedNetworkNotReady
- OperationCanceled
- SecretsInjectionError
- InternalServerError
Se você estiver criando ou atualizando uma implantação online do Kubernetes, poderá ver Erros comuns específicos para implantações do Kubernetes.
ERRO: ImageBuildFailure
Este erro é retornado quando o ambiente (imagem docker) está sendo criado. Você pode verificar o log de compilação para obter mais informações sobre a(s) falha(s). O log de compilação está localizado no armazenamento padrão para seu espaço de trabalho do Azure Machine Learning. O local exato pode ser retornado como parte do erro. Por exemplo, "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'"
.
A lista a seguir contém cenários comuns de falha de compilação de imagem:
- Falha de autorização do Azure Container Registry (ACR)
- Computação de compilação de imagem não definida em um espaço de trabalho privado com VNet
- Falha genérica ou desconhecida
Também recomendamos revisar as configurações de teste padrão se você tiver tempos limite do ImageBuild.
Falha de autorização do registro de contêiner
Se a mensagem de "container registry authorization failure"
erro mencionar, isso significa que você não pode acessar o registro de contêiner com as credenciais atuais.
A dessincronização das chaves de um recurso de espaço de trabalho pode causar esse erro e leva algum tempo para sincronizar automaticamente.
No entanto, você pode chamar manualmente uma sincronização de chaves, o que pode resolver a falha de autorização.
Os registros de contêiner que estão atrás de uma rede virtual também podem encontrar esse erro se configurados incorretamente. Você deve verificar se a rede virtual está configurada corretamente.
Computação de compilação de imagem não definida em um espaço de trabalho privado com VNet
Se a mensagem de "failed to communicate with the workspace's container registry"
erro mencionar e você estiver usando redes virtuais e o Registro de Contêiner do Azure do espaço de trabalho for privado e configurado com um ponto de extremidade privado, você precisará habilitar o Registro de Contêiner do Azure para permitir a criação de imagens na rede virtual.
Tempo limite de construção de imagem
Os tempos limite de construção da imagem geralmente se devem ao fato de uma imagem se tornar muito grande para poder concluir a construção dentro do período de criação da implantação. Para verificar se esse é o seu problema, verifique os logs de compilação da imagem no local que o erro pode especificar. Os logs são cortados no ponto em que a compilação da imagem expirou.
Para resolver isso, crie sua imagem separadamente para que a imagem só precise ser puxada durante a criação da implantação.
Falha na compilação de imagem genérica
Como dito anteriormente, você pode verificar o log de compilação para obter mais informações sobre a falha.
Se nenhum erro óbvio for encontrado no log de compilação e a última linha for Installing pip dependencies: ...working...
, então uma dependência pode causar o erro. Fixar dependências de versão em seu arquivo conda pode corrigir esse problema.
Também recomendamos implantar localmente para testar e depurar seus modelos localmente antes de implantar na nuvem.
ERRO: OutOfQuota
A lista a seguir é de recursos comuns que podem ficar sem cota ao usar os serviços do Azure:
- Processador
- Cluster
- Disk
- Memória
- Atribuições de funções
- Parâmetros de avaliação
- Capacidade de VM em toda a região
- Outro
Além disso, a lista a seguir é de recursos comuns que podem ficar sem cota apenas para o ponto de extremidade online do Kubernetes:
CPU Quota
Antes de implantar um modelo, você precisa ter cota de computação suficiente. Essa cota define quantos núcleos virtuais estão disponíveis por assinatura, por espaço de trabalho, por SKU e por região. Cada implantação subtrai da cota disponível e a adiciona de volta após a exclusão, com base no tipo de SKU.
Uma atenuação possível é verificar se há implantações não utilizadas que você pode excluir. Ou pode apresentar um pedido de aumento de quota.
Cota de cluster
Esse problema ocorre quando você não tem cota de cluster de computação do Azure Machine Learning suficiente. Essa cota define o número total de clusters que podem estar em uso de uma só vez por assinatura para implantar nós de CPU ou GPU na Nuvem do Azure.
Uma atenuação possível é verificar se há implantações não utilizadas que você pode excluir. Ou pode apresentar um pedido de aumento de quota. Certifique-se de selecionar Machine Learning Service: Cluster Quota
como o tipo de cota para essa solicitação de aumento de cota.
Quota de disco
Esse problema acontece quando o tamanho do modelo é maior do que o espaço em disco disponível e o modelo não pode ser baixado. Experimente uma SKU com mais espaço em disco ou reduzindo o tamanho da imagem e do modelo.
Quota de memória
Esse problema acontece quando o espaço ocupado pela memória do modelo é maior do que a memória disponível. Experimente um SKU com mais memória.
Quota de atribuição de funções
Quando você está criando um ponto de extremidade online gerenciado, a atribuição de função é necessária para que a identidade gerenciada acesse os recursos do espaço de trabalho. Se o limite de atribuição de função for atingido, tente excluir algumas atribuições de função não utilizadas nesta assinatura. Você pode verificar todas as atribuições de função no portal do Azure navegando até o menu Controle de Acesso.
Cota de ponto final
Tente eliminar alguns pontos finais não utilizados nesta subscrição. Se todos os seus endpoints estiverem ativamente em uso, você pode tentar solicitar um aumento do limite de endpoint. Para saber mais sobre o limite de pontos de extremidade, consulte Quota de pontos de extremidade com pontos de extremidade online e pontos de extremidade em lote do Azure Machine Learning.
Cota do Kubernetes
Esse problema acontece quando a CPU ou memória solicitada não pode ser fornecida devido aos nós não serem escalonáveis para essa implantação. Por exemplo, os nós podem estar isolados ou indisponíveis.
A mensagem de erro normalmente indica que o recurso é insuficiente no cluster, por exemplo, OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...
o que significa que há muitos pods no cluster e recursos insuficientes para implantar o novo modelo com base na sua solicitação.
Você pode tentar a seguinte atenuação para resolver esse problema:
- Para operações de TI que mantêm o cluster do Kubernetes, você pode tentar adicionar mais nós ou limpar alguns pods não utilizados no cluster para liberar alguns recursos.
- Para engenheiros de aprendizado de máquina que implantam modelos, você pode tentar reduzir a solicitação de recursos de sua implantação:
- Se você definir diretamente a solicitação de recurso na seção de configuração de implantação via recurso, poderá tentar reduzir a solicitação de recurso.
- Se você usar
instance type
para definir recurso para implantação de modelo, poderá entrar em contato com as operações de TI para ajustar a configuração de recurso do tipo de instância, mais detalhes você pode consultar Como gerenciar o tipo de instância do Kubernetes.
Capacidade de VM em toda a região
Devido à falta de capacidade do Azure Machine Learning na região, o serviço não conseguiu provisionar o tamanho de VM especificado. Tente novamente mais tarde ou tente implantar em uma região diferente.
Outras quotas
Para executar o score.py
fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários score.py
e executa o script de pontuação nesse contêiner.
Se o seu contêiner não pôde começar, isso significa que a pontuação não poderia acontecer. Pode ser que o contêiner esteja solicitando mais recursos do que o que instance_type
pode suportar. Em caso afirmativo, considere atualizar a instance_type
implantação on-line.
Para obter o motivo exato de um erro, execute:
az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100
ERRO: BadArgument
A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao usar o endpoint online gerenciado ou o endpoint online do Kubernetes:
- A subscrição não existe
- A tarefa de arranque falhou devido a um erro de autorização
- A tarefa de arranque falhou devido a atribuições de funções incorretas no recurso
- Especificação de função de modelo inválida
- Não é possível transferir a imagem de contentor do utilizador
- Não é possível transferir o modelo de utilizador
- O formato de modelo MLFlow com rede privada não é suportado
A lista a seguir é uma das razões pelas quais você pode encontrar esse erro somente ao usar o ponto de extremidade online do Kubernetes:
- O pedido de recurso sfoi superior aos limites
- O ponto de extremidade online Azureml-FE for Kubernetes não está pronto
A subscrição não existe
A assinatura do Azure inserida deve existir. Este erro ocorre quando não conseguimos encontrar a subscrição do Azure que foi referenciada. Este erro é provavelmente devido a um erro de digitação no ID da assinatura. Verifique se o ID da assinatura foi digitado corretamente e se está ativo no momento.
Para obter mais informações sobre assinaturas do Azure, você pode ver a seção de pré-requisitos.
Erro de autorização
Depois de provisionar o recurso de computação (ao criar uma implantação), o Azure tenta extrair a imagem do contêiner do usuário do espaço de trabalho Azure Container Registry (ACR). Ele tenta montar o modelo de usuário e codificar artefatos no contêiner do usuário a partir da conta de armazenamento do espaço de trabalho.
Para executar essas ações, o Azure usa identidades gerenciadas para acessar a conta de armazenamento e o registro de contêiner.
Se você criou o ponto de extremidade associado com a Identidade Atribuída ao Sistema, a permissão RBAC (controle de acesso baseado em função) do Azure será concedida automaticamente e nenhuma outra permissão será necessária.
Se você criou o ponto de extremidade associado com a Identidade Atribuída pelo Usuário, a identidade gerenciada do usuário deve ter permissão de leitor de dados de blob de armazenamento na conta de armazenamento para o espaço de trabalho e permissão AcrPull no Registro de Contêiner do Azure (ACR) para o espaço de trabalho. Certifique-se de que a sua Identidade Atribuída ao Utilizador tem a permissão certa.
Para obter mais informações, consulte Erro de autorização do registro de contêiner.
Especificação de função de modelo inválida
Este erro ocorre quando uma função de modelo foi especificada incorretamente. Corrija a política ou remova a atribuição de política a ser desbloqueada. A mensagem de erro pode incluir o nome da atribuição de política e a definição de política para ajudá-lo a depurar esse erro e o artigo da estrutura de definição de política do Azure, que discute dicas para evitar falhas de modelo.
Não é possível transferir a imagem de contentor do utilizador
É possível que o contêiner do usuário não tenha sido encontrado. Verifique os logs de contêiner para obter mais detalhes.
Verifique se a imagem do contêiner está disponível no ACR do espaço de trabalho.
Por exemplo, se a imagem estiver testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest
verificando o repositório com az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table
.
Não é possível transferir o modelo de utilizador
É possível que o modelo do usuário não possa ser encontrado. Verifique os logs de contêiner para obter mais detalhes.
Certifique-se de ter registrado o modelo no mesmo espaço de trabalho da implantação. Para mostrar detalhes de um modelo em um espaço de trabalho:
az ml model show --name <model-name> --version <version>
Aviso
Você deve especificar a versão ou o rótulo para obter as informações do modelo.
Você também pode verificar se os blobs estão presentes na conta de armazenamento do espaço de trabalho.
Por exemplo, se o blob for
https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl
, você pode usar este comando para verificar se ele existe:az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
Se o blob estiver presente, você poderá usar este comando para obter os logs do inicializador de armazenamento:
az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`
O formato de modelo MLFlow com rede privada não é suportado
Esse erro acontece quando você tenta implantar um modelo MLflow com uma abordagem de implantação sem código em conjunto com o método de isolamento de rede herdado para pontos de extremidade online gerenciados. Esse recurso de rede privada não pode ser usado em conjunto com um formato de modelo MLFlow se você estiver usando o método de isolamento de rede herdado . Se você precisar implantar um modelo MLflow com a abordagem de implantação sem código, tente usar a VNet gerenciada pelo espaço de trabalho.
Solicitações de recursos maiores que os limites
Os pedidos de recursos devem ser inferiores ou iguais a limites. Se você não definir limites, definiremos valores padrão quando você anexar sua computação a um espaço de trabalho do Azure Machine Learning. Você pode verificar os limites no portal do Azure ou usando o az ml compute show
comando.
azureml-fe não está pronto
O componente front-end (azureml-fe) que roteia solicitações de inferência de entrada para serviços implantados é dimensionado automaticamente conforme necessário. É instalado durante a instalação da extensão k8s.
Esse componente deve estar íntegro no cluster, pelo menos uma réplica íntegra. Você recebe essa mensagem de erro se ela não estiver disponível quando você acionar o ponto de extremidade online do kubernetes e a solicitação de criação/atualização de implantação.
Verifique o status e os logs do pod Para corrigir esse problema, você também pode tentar atualizar a extensão k8s instalada no cluster.
ERRO: ResourceNotReady
Para executar o score.py
fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários score.py
e executa o script de pontuação nesse contêiner. O erro nesse cenário é que esse contêiner está falhando durante a execução, o que significa que a pontuação não pode acontecer. Este erro acontece quando:
- Há um erro no
score.py
. Useget-logs
para diagnosticar problemas comuns:- Um pacote que
score.py
tenta importar não está incluído no ambiente conda. - Um erro de sintaxe.
- Uma falha no
init()
método.
- Um pacote que
- Se
get-logs
não estiver produzindo logs, isso geralmente significa que o contêiner falhou ao iniciar. Para depurar esse problema, tente implantar localmente . - As sondas de prontidão ou vivacidade não estão configuradas corretamente.
- A inicialização do contêiner está demorando muito para que a sonda de prontidão ou vivacidade falhe além do limite de falha. Nesse caso, ajuste as configurações da sonda para permitir mais tempo para inicializar o contêiner. Ou tente uma SKU de VM maior entre as SKUs de VM suportadas, o que acelera a inicialização.
- Há um erro na configuração do ambiente do contêiner, como uma dependência ausente.
- Quando receber o
TypeError: register() takes 3 positional arguments but 4 were given
erro, verifique a dependência entre o frasco v2 eazureml-inference-server-http
o . Para obter mais informações, consulte Perguntas frequentes sobre o servidor HTTP de inferência.
ERRO: ResourceNotFound
A lista a seguir mostra os motivos pelos quais você pode se deparar com esse erro somente ao usar o endpoint online gerenciado ou o endpoint online do Kubernetes:
- O Azure Resource Manager não consegue encontrar um recurso necessário
- O Azure Container Registry é privado ou não está acessível
O Resource Manager não consegue encontrar um recurso
Este erro ocorre quando o Azure Resource Manager não consegue encontrar um recurso necessário. Por exemplo, você pode receber esse erro se uma conta de armazenamento foi referida, mas não pode ser encontrada no caminho no qual ela foi especificada. Certifique-se de verificar novamente os recursos que podem ter sido fornecidos pelo caminho exato ou pela ortografia de seus nomes.
Para obter mais informações, consulte Resolver erros de recurso não encontrado.
Erro de autorização do registro de contêiner
Este erro ocorre quando uma imagem pertencente a um registro de contêiner privado ou inacessível foi fornecida para implantação. No momento, nossas APIs não podem aceitar credenciais de registro privadas.
Para atenuar esse erro, verifique se o registro de contêiner não é particular ou siga as seguintes etapas:
- Conceda a função do
acrPull
seu registo privado à identidade do sistema do seu ponto de extremidade online. - Na definição do seu ambiente, especifique o endereço da sua imagem privada e a instrução para não modificar (construir) a imagem.
Se a mitigação for bem-sucedida, a imagem não requer construção e o endereço final da imagem é o endereço da imagem fornecido. No momento da implantação, a identidade do sistema do ponto de extremidade online extrai a imagem do registro privado.
Para obter mais informações de diagnóstico, consulte Como usar a API de diagnóstico do espaço de trabalho.
ERRO: WorkspaceManagedNetworkNotReady
Este erro ocorre quando você tentou criar uma implantação online no espaço de trabalho que habilitou a VNet gerenciada do espaço de trabalho, mas a VNet gerenciada ainda não foi provisionada. A VNet gerenciada pelo espaço de trabalho deve ser provisionada antes de criar uma implantação online. Siga as instruções Provisione manualmente a VNet gerenciada pelo espaço de trabalho para provisionar manualmente a VNet gerenciada pelo espaço de trabalho. Depois de concluído, você pode começar a criar implantações online. Para obter mais informações, consulte Isolamento de rede com ponto de extremidade online gerenciado e Proteger seus pontos de extremidade online gerenciados com isolamento de rede.
ERRO: OperationCanceled
A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao usar o endpoint online gerenciado ou o endpoint online do Kubernetes:
- A operação foi cancelada por outra operação que tem uma prioridade superior
- A operação foi cancelada devido a uma operação anterior a aguardar confirmação de bloqueio
Operação cancelada por outra operação de prioridade mais alta
As operações do Azure têm um determinado nível de prioridade e são executadas do mais alto para o mais baixo. Este erro acontece quando a operação foi substituída por outra operação que tem uma prioridade mais alta.
Repetir a operação pode permitir que ela seja executada sem cancelamento.
Operação cancelada aguardando confirmação de bloqueio
As operações do Azure têm um breve período de espera após serem enviadas, durante o qual recuperam um bloqueio para garantir que não nos deparamos com condições de corrida. Este erro acontece quando a operação enviada é igual a outra operação. A outra operação aguarda a confirmação de que recebeu o bloqueio para prosseguir. Isso pode indicar que você enviou uma solicitação semelhante muito cedo após a solicitação inicial.
Repetir a operação depois de esperar vários segundos até um minuto pode permitir que ela seja executada sem cancelamento.
ERRO: SecretsInjectionError
A recuperação e injeção de segredos durante a criação da implantação online usa a identidade associada ao ponto de extremidade online para recuperar segredos das conexões do espaço de trabalho e/ou cofres de chaves. Este erro acontece quando:
- A identidade do ponto de extremidade não tem a permissão do RBAC do Azure para ler os segredos das conexões de espaço de trabalho e/ou cofres de chave, mesmo que os segredos tenham sido especificados pela definição de implantação como referências (mapeados para variáveis de ambiente). Lembre-se de que a atribuição de função pode levar algum tempo para que as alterações entrem em vigor.
- O formato das referências secretas é inválido ou os segredos especificados não existem nas conexões do espaço de trabalho e/ou cofres de chaves.
Para obter mais informações, consulte Injeção secreta em pontos de extremidade online (visualização) e Acessar segredos da implantação online usando injeção secreta (visualização).
ERRO: InternalServerError
Embora façamos o nosso melhor para fornecer um serviço estável e confiável, às vezes as coisas não saem conforme o planejado. Se você receber esse erro, isso significa que algo não está bem do nosso lado, e precisamos corrigi-lo. Envie um ticket de suporte ao cliente com todas as informações relacionadas e podemos resolver o problema.
Erros comuns específicos para implantações do Kubernetes
Erros relativos à identidade e autenticação:
- ACRSecretError
- TokenRefreshFailed
- GetAADTokenFailed
- ACRAuthenticationChallengeFailed
- ACRTokenExchangeFailed
- KubernetesInacessível
Erros relativos ao crashloopbackoff:
Erros em relação ao script de pontuação:
Outros:
- NamespaceNotFound
- EndpointAlreadyExists
- ScoringFeUnhealthy
- ValidateScoringFailed
- InvalidDeploymentSpec
- PodUnschedulable
- PodOutOfMemory
- InferencingClientCallFailed
ERRO: ACRSecretError
A lista a seguir mostra os motivos pelos quais você pode se deparar com esse erro ao criar/atualizar as implantações online do Kubernetes:
- A atribuição de função não foi concluída. Nesse caso, aguarde alguns segundos e tente novamente mais tarde.
- O Azure ARC (Para cluster do Azure Arc Kubernetes) ou a extensão do Azure Machine Learning (Para AKS) não está instalada ou configurada corretamente. Tente verificar a configuração e o status da extensão Azure ARC ou Azure Machine Learning.
- O cluster Kubernetes tem configuração de rede incorreta, verifique o proxy, a diretiva de rede ou o certificado.
- Se você estiver usando um cluster AKS privado, é necessário configurar pontos de extremidade privados para ACR, conta de armazenamento, espaço de trabalho na vnet AKS.
- Verifique se a versão da extensão do Azure Machine Learning é maior que a v1.1.25.
ERRO: TokenRefreshFailed
Esse erro ocorre porque a extensão não pode obter a credencial principal do Azure porque a identidade do cluster do Kubernetes não está definida corretamente. Reinstale a extensão do Azure Machine Learning e tente novamente.
ERRO: GetAADTokenFailed
Este erro ocorre porque o token do Azure AD de solicitação de cluster do Kubernetes falhou ou expirou, verifique a acessibilidade da rede e tente novamente.
- Você pode seguir a opção Configurar o tráfego de rede necessário para verificar o proxy de saída, certifique-se de que o cluster possa se conectar ao espaço de trabalho.
- A URL do ponto de extremidade do espaço de trabalho pode ser encontrada no CRD do ponto de extremidade online no cluster.
Se o seu espaço de trabalho for um espaço de trabalho privado, que desativou o acesso à rede pública, o cluster do Kubernetes só deverá se comunicar com esse espaço de trabalho privado por meio do link privado.
- Você pode verificar se o acesso ao espaço de trabalho permite acesso público, não importa se um cluster AKS em si é público ou privado, ele não pode acessar o espaço de trabalho privado.
- Para obter mais informações, consulte Secure Azure Kubernetes Service inferencing environment
ERRO: ACRAuthenticationChallengeFailed
Esse erro ocorre porque o cluster do Kubernetes não pode acessar o serviço ACR do espaço de trabalho para fazer o desafio de autenticação. Verifique a sua rede, especialmente o acesso à rede pública ACR, e tente novamente.
Você pode seguir as etapas de solução de problemas em GetAADTokenFailed ao verificar a rede.
ERRO: ACRTokenExchangeFailed
Este erro ocorre porque o token ACR da troca de cluster do Kubernetes falhou porque o token do Azure AD ainda não está autorizado. Como a atribuição de função leva algum tempo, você pode esperar um momento e tentar novamente.
Esta falha também pode ser devido a muitas solicitações para o serviço ACR naquele momento, deve ser um erro transitório, você pode tentar novamente mais tarde.
ERRO: KubernetesUnaccessible
Você pode obter o seguinte erro durante as implantações do modelo Kubernetes:
{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}
Para atenuar esse erro, você pode:
- Gire o certificado AKS para o cluster. Para obter mais informações, consulte Rotação de certificados no Serviço Kubernetes do Azure (AKS).
- O novo certificado deve ser atualizado após 5 horas, para que você possa aguardar 5 horas e reimplantá-lo.
ERRO: ImagePullLoopBackOff
A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque não é possível baixar as imagens do registro do contêiner, resultando na falha de pull de imagens.
Nesse caso, você pode verificar a diretiva de rede do cluster e o registro do contêiner do espaço de trabalho se o cluster puder extrair a imagem do registro do contêiner.
ERRO: DeploymentCrashLoopBackOff
A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é que o contêiner do usuário falhou ao inicializar. Há duas razões possíveis para esse erro:
- O script
score.py
de usuário tem erro de sintaxe ou erro de importação e, em seguida, gere exceções na inicialização. - Ou o pod de implantação precisa de mais memória do que seu limite.
Para atenuar esse erro, primeiro você pode verificar os logs de implantação para quaisquer exceções nos scripts de usuário. Se o erro persistir, tente estender o limite de memória do tipo de instância/recursos.
ERRO: KubernetesCrashLoopBackOff
A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao criar/atualizar os endpoints/implantações online do Kubernetes:
- Um ou mais pods presos no status CrashLoopBackoff, você pode verificar se o log de implantação existe e verificar se há mensagens de erro no log.
- Há um erro e
score.py
o contêiner travou ao iniciar seu código de pontuação, você pode seguir ERROR: ResourceNotReady part. - Seu processo de pontuação precisa de mais memória que seu limite de configuração de implantação é insuficiente, você pode tentar atualizar a implantação com um limite de memória maior.
ERRO: NamespaceNotFound
A razão pela qual você pode encontrar esse erro ao criar/atualizar os pontos de extremidade online do Kubernetes é porque o namespace usado pelo Kubernetes não está disponível no cluster.
Você pode verificar a computação do Kubernetes no portal do espaço de trabalho e verificar o namespace no cluster do Kubernetes. Se o namespace não estiver disponível, você poderá desanexar a computação herdada e anexá-la novamente para criar uma nova, especificando um namespace que já existe no cluster.
ERRO: UserScriptInitFailed
A razão pela qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque a função init no arquivo carregado score.py
gerou exceção.
Você pode verificar os logs de implantação para ver a mensagem de exceção em detalhes e corrigir a exceção.
ERRO: UserScriptImportError
A razão pela qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque o score.py
arquivo carregado importou pacotes indisponíveis.
Você pode verificar os logs de implantação para ver a mensagem de exceção em detalhes e corrigir a exceção.
ERRO: UserScriptFunctionNotFound
A razão pela qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque o score.py
arquivo carregado não tem uma função chamada init()
ou run()
. Você pode verificar seu código e adicionar a função.
ERRO: EndpointNotFound
A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque o sistema não consegue encontrar o recurso de ponto de extremidade para a implantação no cluster. Você deve criar a implantação em um ponto de extremidade existente ou criar esse ponto de extremidade primeiro em seu cluster.
ERRO: EndpointAlreadyExists
A razão pela qual você pode encontrar esse erro ao criar um ponto de extremidade online do Kubernetes é porque o ponto de extremidade de criação já existe no cluster.
O nome do ponto de extremidade deve ser exclusivo por espaço de trabalho e por cluster, portanto, nesse caso, você deve criar o ponto de extremidade com outro nome.
ERRO: ScoringFeUnhealthy
A razão pela qual você pode encontrar esse erro ao criar/atualizar um ponto de extremidade/implantação online do Kubernetes é porque o Azureml-fe que é o serviço do sistema em execução no cluster não foi encontrado ou não está íntegro.
Para solucionar esse problema, você pode reinstalar ou atualizar a extensão do Azure Machine Learning em seu cluster.
ERRO: ValidateScoringFailed
A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque a validação da URL da solicitação de pontuação falhou ao processar a implantação do modelo.
Nesse caso, você pode primeiro verificar a URL do ponto de extremidade e, em seguida, tentar reimplantar a implantação.
ERRO: InvalidDeploymentSpec
A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque a especificação de implantação é inválida.
Nesse caso, você pode verificar a mensagem de erro.
- Certifique-se de que o
instance count
é válido. - Se tiver ativado o dimensionamento automático, certifique-se de que ambos são
minimum instance count
maximum instance count
válidos.
ERRO: PodUnschedulable
A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao criar/atualizar os endpoints/implantações online do Kubernetes:
- Não é possível agendar pod para nós, devido a recursos insuficientes em seu cluster.
- Nenhuma afinidade/seletor de nó corresponde ao nó.
Para atenuar esse erro, você pode seguir estas etapas:
- Verifique a definição do que você usou e
node label
anode selector
instance type
configuração dos nós do cluster. - Verifique
instance type
o tamanho da SKU do nó para o cluster AKS ou o recurso do nó para o cluster Arc-Kubernetes.- Se o cluster tiver poucos recursos, você poderá reduzir o requisito de recurso de tipo de instância ou usar outro tipo de instância com recurso menor necessário.
- Se o cluster não tiver mais recursos para atender ao requisito da implantação, exclua algumas implantações para liberar recursos.
ERRO: PodOutOfMemory
A razão pela qual você pode encontrar esse erro ao criar/atualizar a implantação online é que o limite de memória fornecido para a implantação é insuficiente. Você pode definir o limite de memória para um valor maior ou usar um tipo de instância maior para atenuar esse erro.
ERRO: InferencingClientCallFailed
A razão pela qual você pode encontrar esse erro ao criar/atualizar endpoints/implantações online do Kubernetes é porque a extensão k8s do cluster do Kubernetes não é conectável.
Nesse caso, você pode desanexar e, em seguida, anexar novamente sua computação.
Nota
Para solucionar erros reanexando, garanta reanexar com a mesma configuração da computação desanexada anteriormente, como o mesmo nome de computação e namespace, caso contrário, você poderá encontrar outros erros.
Se ainda não estiver funcionando, você pode pedir ao administrador que pode acessar o cluster para usar kubectl get po -n azureml
para verificar se os pods do servidor de retransmissão estão em execução.
Problemas de dimensionamento automático
Se estiver a ter problemas com o dimensionamento automático, consulte Resolução de problemas de dimensionamento automático do Azure.
Para o ponto de extremidade online do Kubernetes, há o roteador de inferência do Azure Machine Learning, que é um componente front-end para lidar com o dimensionamento automático para todas as implantações de modelo no cluster Kubernetes, você pode encontrar mais informações em Autoscaling of Kubernetes inference routing
Erros comuns de consumo do modelo
A lista a seguir é de erros comuns de consumo de modelo resultantes do status da operação do ponto final invoke
.
Problemas de limite de largura de banda
Os endpoints online gerenciados têm limites de largura de banda para cada ponto de extremidade. Você encontra a configuração de limite em limites para pontos de extremidade online. Se o uso da largura de banda exceder o limite, sua solicitação será atrasada. Para monitorar o atraso de largura de banda:
- Use a métrica "Bytes de rede" para entender o uso atual da largura de banda. Para obter mais informações, consulte Monitorar pontos de extremidade online gerenciados.
- Há dois trailers de resposta retornados se o limite de largura de banda for aplicado:
ms-azureml-bandwidth-request-delay-ms
: tempo de atraso em milissegundos que levou para a transferência de fluxo de solicitação.ms-azureml-bandwidth-response-delay-ms
: tempo de atraso em milissegundos que levou para a transferência do fluxo de resposta.
Códigos de estado HTTP
Quando você acessa pontos de extremidade online com solicitações REST, os códigos de status retornados aderem aos padrões para códigos de status HTTP. Estes são detalhes sobre como os erros de invocação e previsão de ponto de extremidade são mapeados para códigos de status HTTP.
Códigos de erro comuns para pontos de extremidade online gerenciados
A tabela a seguir contém códigos de erro comuns ao consumir pontos de extremidade online gerenciados com solicitações REST:
Código de estado | Frase da razão | Por que esse código pode ser retornado |
---|---|---|
200 | OK | Seu modelo foi executado com sucesso, dentro do limite de latência. |
401 | Não autorizado | Você não tem permissão para executar a ação solicitada, como pontuação, ou seu token expirou ou no formato errado. Para obter mais informações, consulte Conceito de autenticação de ponto de extremidade e como autenticar para ponto de extremidade. |
404 | Não encontrado | O ponto de extremidade não tem nenhuma implantação válida com peso positivo. |
408 | Tempo limite do pedido | A execução do modelo levou mais tempo do que o tempo limite fornecido na request_timeout_ms request_settings configuração de implantação do modelo. |
424 | Erro de modelo | Se o contêiner modelo retornar uma resposta diferente de 200, o Azure retornará uma resposta 424. Verifique a Model Status Code dimensão sob a Requests Per Minute métrica no Azure Monitor Metric Explorer do seu ponto de extremidade. Ou verifique os cabeçalhos de ms-azureml-model-error-statuscode resposta e ms-azureml-model-error-reason para obter mais informações. Se o 424 vier com falha na sonda de vivacidade ou prontidão, considere ajustar as configurações da sonda para permitir mais tempo para a vida da sonda ou a prontidão do contêiner. |
429 | Demasiados pedidos pendentes | Atualmente, seu modelo está recebendo mais solicitações do que pode lidar. O Azure Machine Learning implementou um sistema que permite que um máximo de 2 * max_concurrent_requests_per_instance * instance_count requests processos sejam processados em paralelo a qualquer momento para garantir um bom funcionamento. Outros pedidos que excedam este limite são rejeitados. Você pode revisar a configuração de implantação do modelo nas seções request_settings e scale_settings para verificar e ajustar essas configurações. Além disso, conforme descrito na definição YAML para RequestSettings, é importante garantir que a variável WORKER_COUNT de ambiente seja passada corretamente. Se você estiver usando o dimensionamento automático e receber esse erro, isso significa que seu modelo está recebendo solicitações mais rapidamente do que o sistema pode escalar. Nessa situação, considere reenviar solicitações com um backoff exponencial para dar ao sistema o tempo necessário para ajustar. Você também pode aumentar o número de instâncias usando código para calcular a contagem de instâncias. Essas etapas, combinadas com a configuração do dimensionamento automático, ajudam a garantir que seu modelo esteja pronto para lidar com o fluxo de solicitações. |
429 | Taxa limitada | O número de solicitações por segundo atingiu os limites dos endpoints online gerenciados. |
500 | Erro interno do servidor | A infraestrutura provisionada do Azure Machine Learning está falhando. |
Códigos de erro comuns para pontos de extremidade online do kubernetes
A tabela a seguir contém códigos de erro comuns ao consumir pontos de extremidade online do Kubernetes com solicitações REST:
Código de estado | Frase da razão | Por que esse código pode ser retornado |
---|---|---|
409 | Erro de conflito | Quando uma operação já está em andamento, qualquer nova operação nesse mesmo ponto de extremidade online responde com erro de conflito 409. Por exemplo, se a operação de criação ou atualização de ponto de extremidade online estiver em andamento e se você acionar uma nova operação Excluir, ela gerará um erro. |
502 | Lançou uma exceção ou falhou no run() método do arquivo score.py |
Quando há um erro no score.py , por exemplo, um pacote importado não existe no ambiente conda, um erro de sintaxe ou uma falha no init() método. Você pode seguir aqui para depurar o arquivo. |
503 | Receba grandes picos de solicitações por segundo | O autoscaler é projetado para lidar com mudanças graduais na carga. Se você receber grandes picos de solicitações por segundo, os clientes poderão receber um código de status HTTP 503. Embora o autoscaler reaja rapidamente, o AKS leva uma quantidade significativa de tempo para criar mais contêineres. Você pode seguir aqui para evitar códigos de status 503. |
504 | O tempo limite do pedido expirou | Um código de status 504 indica que a solicitação expirou. A configuração de tempo limite padrão é de 5 segundos. Você pode aumentar o tempo limite ou tentar acelerar o ponto de extremidade modificando o score.py para remover chamadas desnecessárias. Se essas ações não corrigirem o problema, você pode seguir aqui para depurar o arquivo score.py. O código pode estar em um estado sem resposta ou em um loop infinito. |
500 | Erro interno do servidor | A infraestrutura provisionada do Azure Machine Learning está falhando. |
Como impedir códigos de estado 503
As implantações online do Kubernetes dão suporte ao dimensionamento automático, que permite que réplicas sejam adicionadas para dar suporte a carga extra, mais informações que você pode encontrar no roteador de inferência do Azure Machine Learning. As decisões de aumentar/reduzir a escala baseiam-se na utilização das réplicas de contêiner atuais.
Há duas coisas que podem ajudar a evitar códigos de status 503:
Gorjeta
Estas duas abordagens podem ser utilizadas individualmente ou em combinação.
Altere o nível de utilização no qual o dimensionamento automático cria novas réplicas. Você pode ajustar a meta de utilização definindo o
autoscale_target_utilization
para um valor mais baixo.Importante
Essa alteração não faz com que as réplicas sejam criadas mais rapidamente. Em vez disso, eles são criados em um limite de utilização mais baixo. Em vez de esperar até que o serviço seja 70% utilizado, alterar o valor para 30% faz com que réplicas sejam criadas quando ocorre uma utilização de 30%.
Se o ponto de extremidade online do Kubernetes já estiver usando as réplicas máximas atuais e você ainda estiver vendo 503 códigos de status, aumente o
autoscale_max_replicas
valor para aumentar o número máximo de réplicas.Altere o número mínimo de réplicas. Aumentar as réplicas mínimas fornece um pool maior para lidar com os picos de entrada.
Para aumentar o número de instâncias, você pode calcular as réplicas necessárias seguindo esses códigos.
from math import ceil # target requests per second target_rps = 20 # time to process the request (in seconds, choose appropriate percentile) request_process_time = 10 # Maximum concurrent requests per instance max_concurrent_requests_per_instance = 1 # The target CPU usage of the model container. 70% in this example target_utilization = .7 concurrent_requests = target_rps * request_process_time / target_utilization # Number of instance count instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)
Nota
Se você receber picos de solicitação maiores do que as novas réplicas mínimas podem lidar, poderá receber 503 novamente. Por exemplo, à medida que o tráfego para seu endpoint aumenta, talvez seja necessário aumentar o mínimo de réplicas.
Como calcular a contagem de instâncias
Para aumentar o número de instâncias, você pode calcular as réplicas necessárias usando o seguinte código:
from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7
concurrent_requests = target_rps * request_process_time / target_utilization
# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)
Bloqueado pela política CORS
Atualmente, os pontos de extremidade online (v2) não suportam o CORS (Cross-Origin Resource Sharing ) nativamente. Se o seu aplicativo Web tentar invocar o ponto de extremidade sem o tratamento adequado das solicitações de comprovação do CORS, você poderá ver a seguinte mensagem de erro:
Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.
Recomendamos que você use o Azure Functions, o Gateway de Aplicativo do Azure ou qualquer serviço como uma camada provisória para lidar com solicitações de comprovação CORS.
Problemas comuns de isolamento de rede
A criação de pontos finais online falha com a mensagem V1LegacyMode == true
O espaço de trabalho do Azure Machine Learning pode ser configurado para v1_legacy_mode
, o que desativa as APIs v2. Os pontos de extremidade online gerenciados são um recurso da plataforma de API v2 e não funcionarão se v1_legacy_mode
estiverem habilitados para o espaço de trabalho.
Importante
Consulte a sua equipa de segurança de rede antes de desativar o v1_legacy_mode
. Ele pode ter sido habilitado pela sua equipe de segurança de rede por um motivo.
Para obter informações sobre como desativar v1_legacy_mode
o , consulte Isolamento de rede com v2.
Falha na criação de pontos finais online com a autenticação baseada em chaves
Use o comando a seguir para listar as regras de rede do Cofre da Chave do Azure para seu espaço de trabalho. Substitua <keyvault-name>
pelo nome do cofre de chaves:
az keyvault network-rule list -n <keyvault-name>
A resposta para este comando é semelhante ao seguinte documento JSON:
{
"bypass": "AzureServices",
"defaultAction": "Deny",
"ipRules": [],
"virtualNetworkRules": []
}
Se o valor de não AzureServices
for , use as orientações em Configurar configurações de rede do cofre de bypass
chaves para defini-lo como AzureServices
.
As implementações online falham com um erro de transferência de imagem
Nota
Esse problema se aplica quando você usa o método de isolamento de rede herdado para pontos de extremidade online gerenciados, no qual o Aprendizado de Máquina do Azure cria uma rede virtual gerenciada para cada implantação sob um ponto de extremidade.
Verifique se o
egress-public-network-access
sinalizador está desativado para a implantação. Se esse sinalizador estiver habilitado e a visibilidade do registro de contêiner for privada, essa falha será esperada.Use o comando a seguir para verificar o status da conexão de ponto de extremidade privado. Substitua
<registry-name>
pelo nome do Registro de Contêiner do Azure para seu espaço de trabalho:az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"
No documento de resposta, verifique se o
status
campo está definido comoApproved
. Se não for aprovado, use o seguinte comando para aprová-lo. Substitua<private-endpoint-name>
pelo nome retornado do comando anterior:az network private-endpoint-connection approve -n <private-endpoint-name>
Não é possível resolver o ponto final de classificação
Verifique se o cliente que emite a solicitação de pontuação é uma rede virtual que pode acessar o espaço de trabalho do Azure Machine Learning.
Use o
nslookup
comando no nome do host do ponto de extremidade para recuperar as informações do endereço IP:nslookup endpointname.westcentralus.inference.ml.azure.com
A resposta contém um endereço. Este endereço deve estar no intervalo fornecido pela rede virtual
Nota
Para o ponto de extremidade online do Kubernetes, o nome do host do ponto de extremidade deve ser o CName (nome de domínio) que foi especificado no cluster do Kubernetes. Se for um ponto de extremidade HTTP, o endereço IP estará contido no URI do ponto de extremidade que você pode obter diretamente na interface do usuário do Studio. Mais maneiras de obter o endereço IP do ponto de extremidade podem ser encontradas em Secure Kubernetes online endpoint.
Se o nome do
nslookup
host não for resolvido pelo comando:Para o endpoint online gerenciado,
Verifique se existe um registo A na zona DNS privada da rede virtual.
Para verificar os registros, use o seguinte comando:
az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name
Os resultados devem conter uma entrada semelhante a
*.<GUID>.inference.<region>
.Se nenhum valor de inferência for retornado, exclua o ponto de extremidade privado do espaço de trabalho e recrie-o. Para obter mais informações, consulte Como configurar um ponto de extremidade privado.
Se o espaço de trabalho com um ponto de extremidade privado estiver configurado usando um DNS personalizado Como usar seu espaço de trabalho com um servidor DNS personalizado, use o seguinte comando para verificar se a resolução funciona corretamente a partir do DNS personalizado.
dig endpointname.westcentralus.inference.ml.azure.com
Para o ponto de extremidade online do Kubernetes,
Verifique a configuração de DNS no cluster Kubernetes.
Além disso, você pode verificar se o azureml-fe funciona conforme o esperado, use o seguinte comando:
kubectl exec -it deploy/azureml-fe -- /bin/bash (Run in azureml-fe pod) curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json "Swagger not found"
Para HTTP, use
curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json "Swagger not found"
Se curl HTTPs falhar (por exemplo, tempo limite), mas HTTP funcionar, verifique se o certificado é válido.
Se isso não resolver para um registro, verifique se a resolução funciona a partir do DNS do Azure (168.63.129.16).
dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com
Se isso for bem-sucedido, você poderá solucionar problemas do encaminhador condicional para link privado no DNS personalizado.
As implementações online não podem ser classificadas
Use o seguinte comando para ver se a implantação foi implantada com êxito:
az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'
Se a implantação for concluída com êxito, o valor de
state
seráSucceeded
.Se a implantação foi bem-sucedida, use o seguinte comando para verificar se o tráfego está atribuído à implantação. Substitua
<endpointname>
pelo nome do seu ponto de extremidade:az ml online-endpoint show -n <endpointname> --query traffic
Gorjeta
Esta etapa não é necessária se você estiver usando o
azureml-model-deployment
cabeçalho em sua solicitação para direcionar essa implantação.A resposta desse comando deve listar a porcentagem de tráfego atribuída às implantações.
Se as atribuições de tráfego (ou cabeçalho de implantação) estiverem definidas corretamente, use o seguinte comando para obter os logs para o ponto de extremidade. Substitua
<endpointname>
pelo nome do ponto de extremidade e<deploymentname>
pela implantação:az ml online-deployment get-logs -e <endpointname> -n <deploymentname>
Examine os logs para ver se há um problema ao executar o código de pontuação quando você envia uma solicitação para a implantação.
Solucionar problemas do servidor de inferência
Nesta seção, fornecemos dicas básicas de solução de problemas para o servidor HTTP de inferência do Azure Machine Learning.
Verifique os pacotes instalados
Siga estas etapas para resolver problemas com pacotes instalados:
Reúna informações sobre pacotes instalados e versões para seu ambiente Python.
Confirme se a versão do
azureml-inference-server-http
pacote Python especificada no arquivo de ambiente corresponde à versão do servidor HTTP de inferência do Azure Machine Learning exibida no log de inicialização.Em alguns casos, o resolvedor de dependência pip instala versões de pacote inesperadas.
Talvez seja necessário executar
pip
para corrigir os pacotes e versões instalados.
Se você especificar o Flask ou suas dependências em seu ambiente, remova esses itens.
Os pacotes dependentes incluem
flask
,jinja2
,itsdangerous
,werkzeug
,markupsafe
eclick
.flask
está listado como uma dependência no pacote do servidor. A melhor abordagem é permitir que o servidor de inferência instale oflask
pacote.Quando o servidor de inferência é configurado para suportar novas versões do Flask, o servidor recebe automaticamente as atualizações do pacote à medida que ficam disponíveis.
Verificar a versão do servidor
O azureml-inference-server-http
pacote do servidor é publicado no PyPI. O changelog e todas as versões anteriores estão listados na página PyPI.
Se você usar uma versão anterior do pacote, a recomendação é atualizar sua configuração para a versão mais recente .
A tabela a seguir resume versões estáveis, problemas comuns e ajustes recomendados:
Versão de pacote | Description | Problema | Resolução |
---|---|---|---|
0.4.x | Incluído em imagens de treinamento datadas 20220601 ou anteriores e azureml-defaults versões .1.34 de pacote através do 1.43 . Última versão estável é 0.4.13. |
Para versões de servidor anteriores à 0.4.11, você pode encontrar problemas de dependência do Flask, como "não é possível importar marcação de nome do jinja2". | Atualize para a versão 0.4.13 ou 0.8.x (a versão mais recente), se possível. |
0,6.x | Pré-instalado na inferência de imagens datadas 20220516 e anteriores. Última versão estável é 0.6.1. |
N/A | N/A |
0,7.x | Suporta Flask 2. Última versão estável é 0.7.7. | N/A | N/A |
0.8.x | Formato de log alterado. O suporte ao Python 3.6 terminou. | N/A | N/A |
Verificar dependências do pacote
Os pacotes dependentes mais relevantes para o pacote de azureml-inference-server-http
servidor incluem:
flask
opencensus-ext-azure
inference-schema
Se você especificou o azureml-defaults
pacote em seu ambiente Python, o azureml-inference-server-http
pacote é um pacote dependente. A dependência é instalada automaticamente.
Gorjeta
Se você usar o Python SDK v1 e não especificar explicitamente o azureml-defaults
pacote em seu ambiente Python, o SDK poderá adicionar automaticamente o pacote. No entanto, a versão do empacotador está bloqueada em relação à versão do SDK. Por exemplo, se a versão do SDK for 1.38.0
, a azureml-defaults==1.38.0
entrada será adicionada aos requisitos de pip do ambiente.
Perguntas mais frequentes
As seções a seguir descrevem possíveis resoluções para perguntas frequentes sobre o servidor HTTP de inferência do Azure Machine Learning.
TypeError durante a inicialização do servidor
Você pode encontrar um TypeError durante a inicialização do servidor, da seguinte maneira:
TypeError: register() takes 3 positional arguments but 4 were given
File "/var/azureml-server/aml_blueprint.py", line 251, in register
super(AMLBlueprint, self).register(app, options, first_registration)
TypeError: register() takes 3 positional arguments but 4 were given
Este erro ocorre quando você tem o Flask 2 instalado em seu ambiente Python, mas sua azureml-inference-server-http
versão do pacote não suporta o Flask 2. O suporte para o Flask 2 está disponível na versão do pacote 0.7.0 e posterior, e azureml-defaults
na azureml-inference-server-http
versão do pacote 1.44 e posterior.
Se você não usar o pacote Flask 2 em uma imagem docker do Azure Machine Learning, use a versão mais recente do
azureml-inference-server-http
pacote ouazureml-defaults
Se você usar o pacote Flask 2 em uma imagem docker do Azure Machine Learning, confirme se a versão de compilação da imagem é julho de 2022 ou posterior.
Você pode encontrar a versão da imagem nos logs do contêiner:
2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information 2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ############################################### 2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2 2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |
A data de compilação da imagem aparece após a
Materialization Build
notação. No exemplo, a versão da imagem é20220708
ou 8 de julho de 2022. Neste exemplo, a imagem é compatível com o Flask 2.Se você não vir uma mensagem semelhante no log do contêiner, sua imagem está desatualizada e deve ser atualizada. Se você usar uma imagem CUDA (Compute Unified Device Architecture) e não conseguir encontrar uma imagem mais recente, verifique se a imagem foi preterida no AzureML-Containers. Você pode encontrar substitutos designados para imagens obsoletas.
Se você usar o servidor com um ponto de extremidade online, também poderá encontrar os logs em "Logs de implantação" na página de ponto de extremidade online no estúdio do Azure Machine Learning.
- Se você implantar com o SDK v1 e não especificar explicitamente uma imagem em sua configuração de implantação, o servidor aplicará o pacote com uma versão que corresponda ao
openmpi4.1.0-ubuntu20.04
conjunto de ferramentas SDK local. No entanto, a versão instalada pode não ser a versão mais recente disponível da imagem. Para o SDK versão 1.43, o servidor instala a versão do pacote por padrão, mas essa versão do pacote não é compatível com oopenmpi4.1.0-ubuntu20.04:20220616
SDK 1.43. Certifique-se de usar o SDK mais recente para sua implantação.
- Se você implantar com o SDK v1 e não especificar explicitamente uma imagem em sua configuração de implantação, o servidor aplicará o pacote com uma versão que corresponda ao
Se não for possível atualizar a imagem, você poderá evitar temporariamente o problema fixando as
azureml-defaults==1.43
entradas ouazureml-inference-server-http~=0.4.13
no arquivo de ambiente. Essas entradas direcionam o servidor para instalar a versão mais antiga comflask 1.0.x
o .
ImportError ou ModuleNotFoundError durante a inicialização do servidor
Você pode encontrar um ImportError
ou ModuleNotFoundError
em módulos específicos durante a inicialização do servidor, como opencensus
, jinja2
, markupsafe
ou click
. Eis um exemplo da mensagem de erro:
ImportError: cannot import name 'Markup' from 'jinja2'
Os erros de importação e módulo ocorrem quando você usa versões mais antigas do servidor (versão 0.4.10 e anterior) que não fixam a dependência do Flask em uma versão compatível.
Para evitar o problema, instale uma versão posterior do servidor.