Partager via

Résoudre des problèmes de déploiement et de scoring de points de terminaison en ligne

  • Article

S’APPLIQUE À :Extension Azure CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)

Cet article décrit comment résoudre des problèmes courants de déploiement et de scoring de points de terminaison en ligne Azure Machine Learning.

La structure de document reflète la façon dont vous devez approcher la résolution des problèmes :

  1. Utilisez un déploiement local pour tester et déboguer vos modèles localement avant le déploiement dans le cloud.
  2. Utilisez des journaux de conteneur pour déboguer les problèmes plus facilement.
  3. Appréhendez les erreurs de déploiement courantes et la façon de les résoudre.

La section Codes d’état HTTP explique comment les erreurs d’appel et de prédiction sont mappées aux codes d’état HTTP quand vous attribuez un score aux points de terminaison avec des requêtes REST.

Prérequis

Suivi des requêtes

Il existe deux en-têtes de suivi pris en charge :

  • x-request-id est réservé au suivi du serveur. Azure Machine Learning remplace cet en-tête vous veiller à ce qu’il soit un identificateur global unique (GUID) valide. Lorsque vous créez un ticket de support pour une demande ayant échoué, attachez l’ID de la demande ayant échoué pour accélérer l’enquête. Vous pouvez également fournir le nom de la région et le nom du point de terminaison.

  • x-ms-client-request-id est disponible pour les scénarios de suivi client. Cet en-tête accepte uniquement les caractères alphanumériques, les traits d’union et les traits de soulignement, et est tronqué à un maximum de 40 caractères.

Déploiement local

Le déploiement local est un moyen pour déployer un modèle dans un environnement Docker local. Les déploiements locaux prennent en charge la création, la mise à jour et la suppression d’un point de terminaison local et vous permettent d’appeler et d’obtenir des journaux d’activité à partir du point de terminaison. Le déploiement local est utile pour le test et le débogage avant le déploiement dans le cloud.

Conseil

Vous pouvez également utiliser le package Python du serveur HTTP d’inférence Azure Machine Learning pour déboguer votre script de scoring localement. Le débogage avec le serveur d’inférence vous aide à déboguer le script de scoring avant le déploiement sur des points de terminaison locaux afin de pouvoir déboguer sans être affecté par les configurations de conteneur de déploiement.

Vous pouvez déployer localement avec l’interface Azure CLI ou le Kit de développement logiciel (SDK) Python. Azure Machine Learning studio ne prend pas en charge les déploiements locaux ou les points de terminaison locaux.

Pour utiliser un déploiement local, ajoutez --local à la commande appropriée.

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

Les étapes suivantes se produisent lors d’un déploiement local :

  1. Docker génère une nouvelle image conteneur ou tire (pull) une image existante du cache Docker local. Docker utilise une image existante si elle correspond à la partie de l’environnement du fichier de spécification.
  2. Docker démarre le nouveau conteneur avec les artefacts locaux montés comme des fichiers de code et un modèle.

Pour obtenir plus d’informations, consultez Déployer et déboguer localement à l’aide d’un point de terminaison local.

Conseil

Vous pouvez utiliser Visual Studio Code pour tester et déboguer vos points de terminaison localement. Pour découvrir plus d’informations, consultez Déboguer les points de terminaison en ligne localement dans Visual Studio Code.

Obtenir les journaux de conteneur

Vous ne pouvez pas accéder directement à une machine virtuelle où un modèle se déploie, mais vous pouvez obtenir des journaux d’activité à partir de certains des conteneurs qui s’exécutent sur la machine virtuelle. La quantité d’informations que vous obtenez dépend de l’état de provisionnement du déploiement. Si le conteneur spécifié est opérationnel, sa sortie de console s’affiche. Sinon, vous obtenez un message vous invitant à réessayer plus tard.

Vous pouvez obtenir des journaux d’activité à partir des types de conteneur suivants :

  • Le journal de console du serveur d’inférence contient la sortie des fonctions d’impression/de journalisation de votre code score.py de script de scoring.
  • Les journaux d’initialiseur de stockage contiennent des informations sur la réussite du téléchargement des données de code et de modèle sur le conteneur. Le conteneur s’exécute avant que le conteneur du serveur d’inférence ne commence à s’exécuter.

Pour les points de terminaison en ligne Kubernetes, les administrateurs peuvent accéder directement au cluster où vous déployez le modèle et vérifier les journaux d’activité dans Kubernetes. Par exemple :

kubectl -n <compute-namespace> logs <container-name>

Remarque

Si vous utilisez la journalisation Python, veillez à utiliser le niveau de journalisation approprié, comme INFO, pour les messages à publier dans les journaux d’activité.

Consulter une sortie de journal à partir de conteneurs

Pour voir la sortie de journal d’un conteneur, utilisez la commande suivante :

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

Or

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Par défaut, les journaux sont extraits du serveur d’inférence. Vous pouvez obtenir des journaux d’activité à partir du conteneur de l’initialiseur de stockage en passant –-container storage-initializer.

Ajoutez --resource-group et --workspace-name aux commandes si vous n’avez pas encore défini ces paramètres via az configure. Pour afficher des informations sur la définition de ces paramètres ou si vous avez actuellement défini des valeurs, exécutez la commande suivante :

az ml online-deployment get-logs -h

Ajoutez --help ou --debug aux commandes pour consulter plus d’informations.

Erreurs de déploiement courantes

L’état de l’opération de déploiement peut signaler les erreurs de déploiement suivantes :

Si vous créez ou mettez à jour un déploiement Kubernetes en ligne, consultez également Erreurs courantes spécifiques aux déploiements Kubernetes.

ERREUR : ImageBuildFailure

Cette erreur est retournée lorsque l’environnement d’image Docker est généré. Vous pouvez vérifier le journal de génération pour découvrir plus d’informations sur la défaillance. Le journal de génération se trouve dans le stockage par défaut de votre espace de travail Azure Machine Learning.

Il est possible que l’emplacement exact soit renvoyé dans le cadre de l’erreur, par exemple "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Les sections suivantes décrivent les scénarios courants de défaillance de la génération d’images :

Échec de l’autorisation Azure Container Registry

Un message d’erreur mentionne "container registry authorization failure" lorsque vous ne pouvez pas accéder au registre de conteneurs avec les informations d’identification actuelles. La désynchronisation des clés d’une ressource d’espace de travail peut provoquer cette erreur et un certain temps est nécessaire pour la synchronisation automatique. Cependant, vous pouvez appeler manuellement une synchronisation de clés avec az ml workspace sync-keys qui peut résoudre l’échec d’autorisation.

Il est possible que les registres de conteneurs qui se trouvent derrière un réseau virtuel rencontrent également cette erreur s’ils sont configurés de manière incorrecte. Vérifiez que le réseau virtuel est correctement configuré.

Le calcul de génération d’image n’est pas défini dans un espace de travail privé avec un réseau virtuel

Si le message d’erreur mentionne "failed to communicate with the workspace's container registry", que vous utilisez un réseau virtuel et que le registre de conteneurs de l’espace de travail est privé et configuré avec un point de terminaison privé, vous devez autoriser Azure Container Registry à générer des images dans le réseau virtuel.

Délai d’expiration de la build de l’image

Les délais d’expiration de génération d’images sont souvent dus à une image trop grande ne permettant pas d’effectuer la création dans le délai de création du déploiement. Consultez les journaux d’activité de votre génération d’image dans l’emplacement spécifié par l’erreur. Les journaux d’activité sont interrompus au point d’expiration de la génération de l’image.

Pour résoudre ce problème, générez votre image séparément afin que l’image ne doive être extraite que lors de la création du déploiement. Passez également en revue les paramètres de sonde d’intégrité par défaut en cas d’expiration du délai d’attente d’ImageBuild.

Échec de génération d’une image générique

Consultez le journal de génération pour découvrir plus d’informations sur la défaillance. Si aucune erreur évidente n’est trouvée dans le journal de génération et que la dernière ligne est Installing pip dependencies: ...working..., il est possible qu’une dépendance entraîne l’erreur. L’épinglage des dépendances de version dans votre fichier conda peut résoudre ce problème.

Essayez de déployer localement pour tester et déboguer vos modèles avant de déployer dans le cloud.

ERREUR : OutOfQuota

Il est possible que les ressources courantes dépassent le quota lors de l’utilisation des services Azure :

Pour les points de terminaison Kubernetes en ligne uniquement, le quota de la ressource Kubernetes pourrait également être insuffisant.

Quota de processeur

Vous devez disposer d’un quota de calcul suffisant pour déployer un modèle. Le quota du processeur définit le nombre de cœurs virtuels disponibles par abonnement, par espace de travail, par référence SKU et par région. Chaque déploiement puise dans le quota disponible (qu’il rétablit après la suppression) en fonction du type de référence SKU.

Vous pouvez vérifier s’il existe des déploiements inutilisés susceptibles d’être annulés ou vous pouvez envoyer une demande d’augmentation de quota.

Quota de cluster

L’erreur OutOfQuota survient lorsque votre quota de cluster de capacité de calcul Azure Machine Learning est insuffisant. Ce quota définit le nombre total de clusters par abonnement que vous pouvez utiliser en même temps pour déployer des nœuds d’UC ou de GPU dans le cloud Azure.

Quota de disque

L’erreur OutOfQuota se produit lorsque la taille du modèle est supérieure à l’espace disque disponible et que le modèle ne peut pas être téléchargé. Essayez d’utiliser une référence SKU dotée de plus de d’espace disque ou de réduire la taille de l’image et du modèle.

Quota de mémoire

L’erreur OutOfQuota se produit lorsque l’empreinte mémoire du modèle est supérieure à la mémoire disponible. Essayez une référence SKU dotée de plus de mémoire.

Quota d’attribution de rôle

Lorsque vous créez un point de terminaison en ligne managé, l’attribution de rôle est requise pour que l’identité managée accède aux ressources d’espace de travail. Si vous atteignez la limite d’attribution de rôle, essayez de supprimer certaines attributions de rôle inutilisées dans cet abonnement. Vous pouvez consulter toutes les attributions de rôle en sélectionnant Contrôle d’accès pour votre abonnement Azure dans le Portail Azure.

Quota de point de terminaison

Essayez de supprimer les points de terminaison non utilisés dans cet abonnement. Si tous vos points de terminaison sont activement utilisés, essayez de demander une augmentation de la limite de point de terminaison. Pour en savoir plus sur la limite de point de terminaison, consultez quota de points de terminaison avec des points de terminaison en ligne Azure Machine Learning et des points de terminaison de lots.

Quota Kubernetes

L’erreur OutOfQuota se produit lorsque la fourniture demandée en mémoire ou processeur n’est pas possible en raison de nœuds non planifiables pour ce déploiement. Par exemple, il est possible que les nœuds délimités ou à défaut indisponibles.

Le message d’erreur indique généralement une insuffisance de la ressource dans le cluster, par exemple OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Ce message signifie qu’il existe trop de pods dans le cluster et pas assez de ressources pour déployer le nouveau modèle en fonction de votre requête.

Essayez les atténuations suivantes pour résoudre ce problème :

  • Les opérateurs informatiques gérant le cluster Kubernetes peuvent essayer d’ajouter d’autres nœuds ou d’effacer certains pods inutilisés dans le cluster pour libérer des ressources.

  • Les ingénieurs Machine Learning qui déploient des modèles peuvent essayer de réduire la demande de ressources du déploiement.

    • Si vous définissez directement la demande de ressources dans la configuration du déploiement via la section des ressources, essayez de réduire la demande de ressources.
    • Si vous utilisez instance_type pour définir la ressource pour le modèle de déploiement, contactez l’opérateur informatique pour qu’il ajuste la configuration de la ressource de type d’instance. Pour découvrir plus d’informations, consultez Créer et gérer des types d’instance.

Capacité des machines virtuelles à l’échelle de la région

En raison d’un manque de capacité Azure Machine Learning dans la région, le service n’a pas pu provisionner la taille de machine virtuelle spécifiée. Réessayez ultérieurement ou essayez d’effectuer le déploiement dans une autre région.

Autre quota

Pour exécuter le fichier score.py que vous fournissez dans le cadre du déploiement, Azure crée un conteneur qui comprend toutes les ressources nécessaires à score.py. Azure Machine Learning exécute ensuite le script de scoring sur ce conteneur. Si votre conteneur ne démarre pas, le scoring ne peut pas se produire. Il est possible que le conteneur demande une quantité de ressources supérieure à celle prise en charge par instance_type. Envisagez de mettre à jour le instance_type du déploiement en ligne.

Pour obtenir la raison exacte de l’erreur, prenez la mesure suivante.

Exécutez la commande suivante :

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ERREUR : BadArgument

Vous risquez de recevoir cette erreur quand vous utilisez des points de terminaison en ligne managés ou des points de terminaison en ligne Kubernetes pour les raisons suivantes :

Vous risquez de recevoir cette erreur lors de l’utilisation unique de points de terminaison en ligne Kubernetes pour les raisons suivantes :

L’abonnement n'existe pas

L’abonnement Azure référencé doit être existant et actif. Cette erreur se produit quand Azure ne peut pas trouver l’ID d’abonnement entré. L’erreur est peut-être due à une faute de frappe dans l’ID d’abonnement. Revérifiez que l’ID d’abonnement a été correctement saisi et qu’il est actuellement actif.

Erreur d’autorisation

Après avoir approvisionné la ressource de calcul lors de la création d’un déploiement, Azure essaie d’extraire l’image conteneur de l’utilisateur du registre de conteneurs de l’espace de travail, puis monte les artefacts de code et de modèle utilisateur dans le conteneur utilisateur à partir du compte de stockage de l’espace de travail. Azure utilise des identités managées pour accéder au compte de stockage et au registre de conteneurs.

Si vous créez le point de terminaison associé à une identité affectée par l’utilisateur, l’identité managée par l’utilisateur doit disposer de l’autorisation Lecteur de données blob de stockage sur le compte de stockage de l’espace de travail et de l’autorisation AcrPull sur le registre de conteneurs de l’espace de travail. Vérifiez que votre identité affectée par l’utilisateur dispose des autorisations appropriées.

Si vous créez le point de terminaison associé à une identité affectée par le système, l’autorisation de contrôle d’accès en fonction du rôle (RBAC) Azure est accordée automatiquement et aucune autre autorisation n’est nécessaire. Pour découvrir plus d’informations, consultez Erreur d’autorisation du registre de conteneurs.

Spécification de la fonction de modèle non valide

Cette erreur se produit lorsqu’une fonction de modèle a été spécifiée de manière incorrecte. Corrigez la stratégie ou supprimez l’affectation de stratégie pour débloquer. Il est possible que le message d’erreur inclue le nom d’attribution et la définition de la stratégie pour vous aider à déboguer l’erreur. Consultez la Structure de définition Azure Policy pour obtenir des conseils afin d’éviter des échecs de modèle.

Impossible de télécharger l’image conteneur utilisateur

Le conteneur utilisateur est susceptible d’être introuvable. Consultez les journaux d’activité des conteneurs pour obtenir plus de détails.

Vérifiez que l’image conteneur est disponible dans le registre de conteneurs de l’espace de travail. Par exemple, si l’image est testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, vous pouvez utiliser la commande suivante pour vérifier le référentiel :

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

Impossible de télécharger le modèle utilisateur

Le modèle utilisateur est susceptible d’être introuvable. Consultez les journaux d’activité des conteneurs pour obtenir plus de détails. Vérifiez que le modèle est inscrit auprès du même espace de travail que le déploiement.

Pour afficher les détails d’un modèle dans un espace de travail, prenez la mesure suivante. Vous devez spécifier la version ou l’étiquette pour obtenir les informations du modèle.

Exécutez la commande suivante :

az ml model show --name <model-name> --version <version>

Vérifiez également les blobs sont présents dans le compte de stockage de l’espace de travail. Par exemple, si le blob est https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, vous pouvez utiliser la commande suivante pour vérifier qu’il existe :

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>

Si le blob est présent, vous pouvez utiliser la commande suivante pour obtenir les journaux d’activité à partir de l’initialiseur de stockage :

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

Le format du modèle MLflow avec un réseau privé n’est pas pris en charge

Vous ne pouvez pas utiliser la fonctionnalité de réseau privé avec un format de modèle MLflow si vous utilisez la méthode d’isolement réseau héritée pour des points de terminaison en ligne managés. Si vous devez déployer un modèle MLflow avec l’approche de déploiement sans code, essayez d’utiliser un réseau virtuel managé par l’espace de travail.

Demandes de ressource supérieures aux limites

Les demandes de ressources doivent être inférieures ou égales aux limites. Si vous ne définissez aucune limite, nous définissons les valeurs par défaut lorsque Azure Machine Learning vous associez votre calcul à un espace de travail. Vous pouvez vérifier les limites dans le Portail Azure ou en utilisant la commande az ml compute show.

Azureml-fe non prêt

Le composant azureml-fe front-end acheminant les requêtes d’inférence entrantes vers les services déployés s’installe pendant l’installation de k8s-extension et se met à l’échelle automatiquement selon les besoins. Ce composant doit avoir au moins un réplica sain sur le cluster.

Vous obtenez cette erreur si le composant n’est pas valide lorsque vous déclenchez un point de terminaison en ligne Kubernetes ou une demande de création/mise à jour du déploiement. Vérifiez les journaux d’activité et l’état du pod pour corriger ce problème. Vous pouvez également essayer de mettre à jour k8s-extension installée sur le cluster.

ERREUR : ResourceNotReady

Pour exécuter le fichierscore-py que vous fournissez dans le cadre du déploiement, Azure crée un conteneur qui comprend toutes les ressources nécessaires à score.py, puis exécute le script de scoring sur ce conteneur. Dans ce scénario, l’erreur est que ce conteneur se bloque à l’exécution et que le scoring ne peut donc pas être effectué. Cette erreur peut se produire sous l’une des raisons suivantes :

  • Il y a une erreur dans score.py. Utilisez get-logs pour diagnostiquer des problèmes courants, tels que :

    • Un package que score.py tente d’importer n’est pas inclus dans l’environnement Conda
    • Une erreur de syntaxe
    • Un échec dans la méthode init()

    Si get-logs ne produit aucun journal, cela signifie généralement que le conteneur n’a pas pu démarrer. Pour déboguer ce problème, essayez de déployer localement.

  • Les probes readiness ou liveness ne sont pas configurées correctement.

  • L’initialisation du conteneur prend trop de temps si bien que la sonde probe readiness ou probe liveness échoue au-delà du seuil d’échec. Dans ce cas, ajustez les paramètres de probe pour laisser plus de temps à l’initialisation du conteneur. Vous pouvez également essayer une référence SKU prise en charge, ce qui accélère l’initialisation.

  • Il y a une erreur dans la configuration de l’environnement du conteneur, par exemple, une dépendance manquante.

    Lorsque vous recevez l’erreur TypeError: register() takes 3 positional arguments but 4 were given, vérifiez la dépendance entre Flask v2 et azureml-inference-server-http. Pour découvrir plus d’informations, consultez Résoudre des problèmes de serveur HTTP.

ERREUR : ResourceNotFound

Vous risquez de recevoir cette erreur quand vous utilisez un point de terminaison en ligne managé ou un point de terminaison en ligne Kubernetes pour les raisons suivantes :

Resource Manager ne parvient pas à trouver une ressource

Cette erreur se produit quand Azure Resource Manager ne trouve pas une ressource nécessaire. Par exemple, vous pouvez recevoir cette erreur si un compte de stockage est introuvable sur le chemin d’accès spécifié. Revérifiez l’exactitude et l’orthographe des spécifications du nom ou du chemin d’accès. Pour découvrir plus d’informations, consultez Résoudre les erreurs liées aux ressources introuvables.

Erreur d’autorisation du registre de conteneurs

Cette erreur se produit quand une image appartenant à un registre de conteneurs privé ou inaccessible est fournie pour le déploiement. Les API Azure Machine Learning ne peuvent pas accepter d’informations d’identification de registre privé.

Pour atténuer cette erreur, vérifiez que le registre de conteneurs n’est pas privé ou effectuez les étapes suivantes :

  1. Accordez le rôle acrPull de votre registre privé à l’identité système de votre point de terminaison en ligne.
  2. Dans la définition de votre environnement, spécifiez l’adresse de votre image privée ainsi que l’instruction de ne pas modifier ou générer l’image.

En cas de réussite de l’atténuation, l’image ne nécessite pas de génération et l’adresse de l’image finale est l’adresse d’image donnée. Au moment du déploiement, l’identité système de votre point de terminaison en ligne extrait l’image du registre privé.

Pour découvrir plus d’informations de diagnostic, consultez Comment utiliser les diagnostics de l’espace de travail.

ERREUR : WorkspaceManagedNetworkNotReady

Cette erreur se produit si vous tentez de créer un déploiement en ligne qui active un réseau virtuel managé par l’espace de travail alors que le réseau virtuel managé n’est pas encore approvisionné. Approvisionnez le réseau virtuel managé par l’espace de travail avant de créer un déploiement en ligne.

Pour approvisionner le réseau virtuel managé par l’espace de travail, suivez les instructions sur Provisionner manuellement un réseau virtuel managé. Vous pouvez ensuite commencer à créer des déploiements en ligne. Pour plus d’informations, consultez Isolation réseau avec point de terminaison en ligne managé et Sécuriser vos points de terminaison en ligne gérés avec isolation réseau.

ERROR: OperationCanceled

Vous risquez de recevoir cette erreur quand vous utilisez un point de terminaison en ligne managé ou un point de terminaison en ligne Kubernetes pour les raisons suivantes :

Opération annulée par une autre opération de priorité supérieure

Les opérations Azure disposent d’un certain niveau de priorité. Elles s’exécutent dans l’ordre de la priorité la plus élevée à la plus faible. Cette erreur se produit quand une autre opération disposant d’une priorité plus élevée remplace votre opération. Il est possible qu’une nouvelle tentative de l’opération permette de l’exécuter sans annulation.

Opération annulée en attente de confirmation du verrouillage

Les opérations Azure ont une courte période d’attente, après avoir été envoyées, pendant laquelle elles récupèrent un verrou pour veiller à ce qu’elles ne rencontrent pas de conditions de concurrence. Cette erreur se produit lorsque l’opération que vous avez envoyée est identique à une autre opération. L’autre opération attend actuellement la confirmation de réception du verrou avant de continuer.

Vous avez peut-être envoyé une demande similaire trop tôt après la demande initiale. Si vous effectuez une nouvelle tentative de l’opération après avoir attendu une minute, cela peut permettre de l’exécuter sans l’annuler.

ERREUR : SecretsInjectionError

La récupération et l’injection de secrets lors de la création d’un déploiement en ligne utilisent l’identité associée au point de terminaison en ligne pour récupérer les secrets des connexions de l’espace de travail ou des coffres de clés. Cette erreur se produit pour l’une des raisons suivantes :

  • L’identité du point de terminaison n’a pas l’autorisation Azure RBAC de lire les secrets des connexions de l’espace de travail ou des coffres de clés, même si les secrets ont été spécifiés par la définition du déploiement en tant que références mappées à des variables d’environnement. Il est possible que la prise d’effet des modifications apportées à l’attribution de rôle prenne un certain temps.

  • Le format des références de secret n’est pas valide ou les secrets spécifiés n’existent pas dans les connexions de l’espace de travail ou les coffres de clés.

Pour plus d’informations, consultez Injection de secrets dans les points de terminaison en ligne (préversion) et Accéder aux secrets à partir du déploiement en ligne à l’aide de l’injection de secrets (préversion).

ERREUR : InternalServerError

Cette erreur signifie qu’il existe un problème avec l’instance Azure Machine Learning service que vous devez corriger. Envoyez un ticket de support client avec toutes les informations nécessaires pour résoudre le problème.

Erreurs courantes spécifiques aux déploiements Kubernetes

Erreurs d’identité et d’authentification :

Erreurs CrashLoopBackoff :

Erreurs de script de scoring :

Autres erreurs :

ERREUR : ACRSecretError

Lorsque vous créez ou mettez à jour des déploiements en ligne Kubernetes, il est possible que vous obteniez cette erreur pour l’une des raisons suivantes :

  • L’attribution de rôle n’est pas effectuée. Patientez quelques secondes, puis réessayez.

  • L’extension Azure Machine Learning AKS ou le cluster Kubernetes avec Azure Arc n’est pas correctement installé ou configuré. Vérifiez l’état et la configuration de l’extension Kubernetes avec Azure Arc ou Azure Machine Learning.

  • Le cluster Kubernetes a une configuration réseau incorrecte. Vérifiez le proxy, la stratégie réseau ou le certificat.

  • Votre cluster AKS privé ne dispose pas des points de terminaison appropriés. Veillez à configurer les points de terminaison privés pour Container Registry, le compte de stockage et l’espace de travail dans le réseau virtuel AKS.

  • La version de votre extension Azure Machine Learning est v1.1.25 ou inférieure. Vérifiez que la version de votre extension est supérieure à 1.1.25.

ERREUR : TokenRefreshFailed

Cette erreur se produit car l’identité du cluster Kubernetes n’est pas correctement définie et l’extension ne peut donc pas obtenir les informations d’identification à partir d’Azure. Réinstallez l’extension Azure Machine Learning et réessayez.

ERREUR : GetAADTokenFailed

Cette erreur se produit car le jeton Microsoft Entra ID de demande de cluster Kubernetes a échoué ou a expiré. Vérifiez votre accès au réseau, puis réessayez.

  • Suivez les instructions sur Utiliser le calcul Kubernetes pour vérifier le proxy sortant et veiller à ce que le cluster puisse se connecter à l’espace de travail. Vous trouverez l’URL de point de terminaison de l’espace de travail dans la Définition de ressource personnalisée (CRD) du point de terminaison en ligne dans le cluster.

  • Vérifiez que l’espace de travail autorise l’accès public. Que le cluster AKS lui-même soit public ou privé, si un espace de travail privé désactive un accès au réseau public, le cluster Kubernetes peut communiquer sans cet espace de travail uniquement via une liaison privée. Pour découvrir plus d’informations, voir Définition d’un environnement d’inférence AKS.

ERREUR : ACRAuthenticationChallengeFailed

Cette erreur se produit, car le cluster Kubernetes ne peut pas accéder au service Container Registry de l’espace de travail pour effectuer une demande d’authentification. Vérifiez votre réseau, en particulier l’accès au réseau public Container Registry, puis réessayez. Pour vérifier le réseau, vous pouvez suivre les étapes de résolution des problèmes décrites dans GetAADTokenFailed.

ERREUR : ACRTokenExchangeFailed

Cette erreur se produit, car le jeton Microsoft Entra ID n’est pas encore autorisé. Le jeton Container Registry d’échange de cluster Kubernetes ainsi échoue. L’attribution de rôle prend un certain temps. Veuillez donc patienter une minute, puis réessayez.

Cette défaillance est susceptible d’être également due à un nombre trop important de demandes simultanées au service Container Registry. Cette erreur doit être temporaire et vous pouvez réessayer plus tard.

ERREUR : KubernetesUnaccessible

Vous risquez d’obtenir l’erreur suivante pendant des déploiements de modèles Kubernetes :

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Pour atténuer cette erreur, vous pouvez faire pivoter le certificat AKS pour le cluster. Le nouveau certificat doit être mis à jour au bout de 5 heures. Vous pouvez donc attendre 5 heures et le redéployer. Pour découvrir plus d’informations, consultez Rotation des certificats dans Azure Kubernetes Service (AKS).

ERREUR : ImagePullLoopBackOff

Vous êtes susceptible de rencontrer cette erreur quand vous créez/mettez à jour des déploiements en ligne Kubernetes, car vous ne pouvez pas télécharger les images à partir du registre de conteneurs, ce qui provoque donc l’échec de l’extraction des images. Vérifiez la stratégie réseau du cluster et le registre de conteneurs de l’espace de travail pour voir si le cluster peut extraire des images du registre de conteneurs.

ERREUR : DeploymentCrashLoopBackOff

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car le conteneur utilisateur s’est bloqué lors de l’initialisation. Il existe deux raisons possibles à cette erreur :

  • Le script utilisateur score.py rencontre une erreur de syntaxe ou une erreur d’importation qui déclenche des exceptions lors de l’initialisation.
  • Le pod de déploiement a besoin de davantage de mémoire que sa limite.

Pour atténuer cette erreur, vérifiez d’abord les journaux d’activité du déploiement pour y rechercher des exceptions dans les scripts utilisateur. Si l’erreur persiste, essayez d’étendre la limite de mémoire du type de ressources/de l’instance.

ERREUR : KubernetesCrashLoopBackOff

Vous risquez de recevoir cette erreur, lorsque vous créez ou mettez à jour des déploiements ou points de terminaison en ligne Kubernetes, pour l’une des raisons suivantes :

  • Un ou plusieurs pods sont bloqués dans l’état CrashLoopBackoff. Vérifiez que le journal de déploiement existe et s’il présente des messages d’erreur.
  • Il existe une erreur dans score.py et le conteneur s’est bloqué lors de l’initialisation de votre code de score. Suivez les instructions sous ERROR: ResourceNotReady.
  • Le processus de votre scoring doit avoir plus de mémoire que la limite de configuration de votre déploiement. Vous pouvez essayer de mettre à jour le déploiement avec l’aide d’une limite de mémoire plus importante.

ERREUR : NamespaceNotFound

Vous risquez de rencontrer cette erreur quand vous créez ou mettez à jour des points de terminaison en ligne Kubernetes, car l’espace de noms utilisé par votre calcul Kubernetes n’est pas disponible dans votre cluster. Consultez le calcul Kubernetes dans le portail de votre espace de travail et vérifiez l’espace de noms dans votre cluster Kubernetes. Si l’espace de noms n’est pas disponible, détachez le calcul hérité, et rattachez-le pour en créer un nouveau, en spécifiant un espace de noms qui existe déjà dans votre cluster.

ERREUR : UserScriptInitFailed

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car la fonction init dans votre fichier score.py mis à jour a levé une exception. Consultez les journaux de déploiement pour voir le message d’exception en détail et corriger l’exception.

ERREUR : UserScriptImportError

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car le fichier score.py mis à jour importe des packages non disponibles. Consultez les journaux de déploiement pour voir le message d’exception en détail et corriger l’exception.

ERREUR : UserScriptFunctionNotFound

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car le fichier score.py mis à jour n’a pas de fonction nommée init() ou run(). Vérifiez votre code et ajoutez la fonction.

ERREUR : EndpointNotFound

Vous risquez de rencontrer cette erreur lorsque vous créez ou mettez à jour des déploiements en ligne Kubernetes, car le système ne trouve pas la ressource de point de terminaison pour le déploiement dans le cluster. Créez le déploiement dans un point de terminaison existant ou créez le point de terminaison en premier dans votre cluster.

ERREUR : EndpointAlreadyExists

Vous risquez d’obtenir cette erreur quand vous créez un point de terminaison en ligne Kubernetes, car le point de terminaison existe déjà dans votre cluster. Le nom du point de terminaison doit être unique par espace de travail et par cluster. Vous devez donc créer un point de terminaison avec un autre nom.

ERREUR : ScoringFeUnhealthy

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour un déploiement ou point de terminaison en ligne Kubernetes, car le service système azureml-fe s’exécutant dans le cluster n’est pas sain ou est introuvable. Pour atténuer ce problème, réinstallez ou mettez à jour l’extension Azure Machine Learning dans votre cluster.

ERREUR : ValidateScoringFailed

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car la validation de l’URL de requête de scoring a échoué lors du traitement du modèle. Vérifiez l’URL du point de terminaison, puis réessayez de déployer.

ERREUR : InvalidDeploymentSpec

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des déploiements en ligne Kubernetes, car la spécification de déploiement n’est pas valide. Vérifiez le message d’erreur pour veiller à ce que instance count soit valide. Si vous avez activé la mise à l’échelle automatique, vérifiez que le minimum instance count et le maximum instance count sont valides.

ERREUR : PodUnschedulable

Vous risquez de recevoir cette erreur, lorsque vous créez ou mettez à jour des déploiements ou points de terminaison en ligne Kubernetes, pour l’une des raisons suivantes :

  • Le système ne peut pas planifier le pod sur les nœuds en raison de ressources insuffisantes dans votre cluster.
  • Aucun nœud ne correspond au sélecteur d’affinité de nœud.

Pour atténuer cette erreur, effectuez les étapes suivantes :

  1. Vérifiez la définition node selector du instance_type utilisé et la configuration de node label des nœuds de votre cluster.
  2. Vérifiez le instance_type et la taille de référence SKU du nœud pour le cluster AKS ou la ressource du nœud pour le cluster Kubernetes avec Azure Arc.
  3. Si le cluster n’a pas assez de ressources, réduisez les besoins en ressources du type d’instance ou utilisez un autre type d’instance avec des exigences inférieures en ressource.
  4. Si le cluster n’a plus de ressources pour répondre aux exigences du déploiement, supprimez des déploiements pour libérer des ressources.

ERREUR : PodOutOfMemory

Vous risques d’obtenir cette erreur quand vous créez ou mettez à jour un déploiement en ligne, car la limite de mémoire donnée pour le déploiement est insuffisante. Pour atténuer cette erreur, vous pouvez définir la limite de mémoire sur une valeur supérieure ou utiliser un type d’instance plus grand.

ERREUR : InferencingClientCallFailed

Vous risquez d’obtenir cette erreur quand vous créez ou mettez à jour des points de terminaison ou déploiements en ligne Kubernetes, car l’extension k8s-extension du cluster Kubernetes n’est pas connectable. Dans ce cas, détachez, puis attachez à nouveau votre calcul.

Pour résoudre des problèmes en effectuant un rattachement, veillez à effectuer cette opération avec la même configuration que le calcul détaché, comme l’espace de noms et le nom de calcul, pour éviter d’autres erreurs. Si cela ne fonctionne toujours pas, demandez à un administrateur ayant accès au cluster d’utiliser kubectl get po -n azureml pour vérifier si les pods du serveur relais sont opérationnels.

Problèmes de consommation de modèles

Les erreurs courantes de consommation de modèles résultant de l’état de l’opération invoke du point de terminaison incluent les problèmes de limite de bande passante, la stratégie CORS et divers codes d’état HTTP.

Problèmes de limite de bande passante

Chaque point de terminaison en ligne managé a ses propres limites de bande passante. Vous trouverez la configuration de limite dans les limites pour les points de terminaison en ligne. Si votre utilisation de la bande passante dépasse la limite, votre requête est retardée.

Si vous souhaitez monitorer le délai de bande passante, utilisez la métrique Octets réseau pour comprendre l’utilisation actuelle de la bande passante. Pour plus d’informations, consultez Superviser des points de terminaison en ligne managés.

Deux codes de fin de réponse sont retournés si une limite de la bande passante est appliquée :

  • ms-azureml-bandwidth-request-delay-ms est le délai en millisecondes nécessaire au transfert du flux de requête.
  • ms-azureml-bandwidth-response-delay-ms est le délai en millisecondes nécessaire au transfert du flux de réponse.

Bloqué par la stratégie CORS

Les points de terminaison en ligne (V2) ne prennent pas en charge de manière native le Partage de ressources entre origines multiple (Cross-Origin Resource Sharing, CORS). Si votre application web tente d’appeler le point de terminaison sans correctement gérer les requêtes préalables CORS, vous pouvez obtenir le message d’erreur suivant :

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.

Vous pouvez utiliser Azure Functions, Azure Application Gateway ou tout autre service en tant que couche temporaire pour gérer les requêtes préalables CORS.

Codes d’état HTTP

Quand vous accédez à des points de terminaison en ligne avec des requêtes REST, les codes d’état retournés correspondent aux codes d’état HTTP standard. Les sections suivantes présentent des détails sur la façon dont les erreurs d’appel et de prédiction des points de terminaison sont mappées aux codes d’état HTTP.

Codes d’erreur courants pour les points de terminaison en ligne managés

Le tableau suivant contient des codes d’erreur courants lorsque des requêtes REST utilisent des points de terminaison en ligne managés :

Code d’état Motif Description
200 OK Votre modèle a été correctement exécuté dans les limites de votre latence.
401 Non autorisé Vous n’avez pas l’autorisation d’effectuer l’action demandée, par exemple un scoring, ou votre jeton a expiré ou n’a pas le bon format. Pour découvrir plus d’informations, consultez Authentification pour les points de terminaison en ligne managés et Authentifier les clients pour les points de terminaison en ligne.
404 Introuvable Le point de terminaison n’a pas de déploiement valide avec un poids positif.
408 Délai d’expiration de la demande L’exécution du modèle a dépassé le délai d’expiration spécifié dans request_timeout_ms sous request_settings dans la configuration du déploiement de votre modèle.
424 Erreur de modèle Si votre conteneur de modèle retourne une réponse autre que 200, Azure retourne un code 424. Vérifiez la dimension Model Status Code sous la métrique Requests Per Minute sur l’Explorateur de métriques Azure Monitor de votre point de terminaison. Vous pouvez également vérifier les en-têtes de réponse ms-azureml-model-error-statuscode et ms-azureml-model-error-reason pour plus d’informations. Si 424 est mentionné avec l’échec de probe liveness ou readiness, envisagez d’ajuster ProbeSettings pour accorder plus de temps à la probe readiness ou probe readiness du conteneur.
429 Requêtes en attente trop nombreuses Votre modèle obtient actuellement plus de requêtes qu’il ne peut en gérer. Afin d’assurer une fluidité des opérations, Azure Machine Learning autorise un nombre maximal de 2 * max_concurrent_requests_per_instance * instance_count requests à traiter en parallèle à un moment donné. Les requêtes dépassant ce maximum sont rejetées.

Vous pouvez passer en revue la configuration de votre modèle de déploiement sous les sections request_settings et scale_settings pour vérifier et ajuster ces paramètres. Veillez également à ce que la variable d’environnement WORKER_COUNT soit correctement transmise, comme indiqué dans RequestSettings.

Si vous obtenez cette erreur quand vous utilisez la mise à l’échelle automatique, votre modèle reçoit les requêtes trop rapidement par rapport à la vitesse de scale-up du système. Envisagez de renvoyer les requêtes avec un backoff exponentiel afin de donner au système le temps nécessaire pour s’ajuster. Vous pouvez également augmenter le nombre d’instances en utilisant le code pour calculer le nombre d’instances. Combinez ces étapes à la définition de la mise à l’échelle automatique pour permettre à votre modèle d’être prêt à gérer l’afflux de requêtes.
429 Limité en débit Le nombre de requêtes par seconde a atteint les limites des points de terminaison en ligne managés.
500 Erreur interne du serveur L’infrastructure provisionnée par Azure Machine Learning échoue.

Codes d’erreur courants pour les points de terminaison en ligne Kubernetes

Le tableau suivant contient des codes d’erreur courants lorsque des requêtes REST utilisent des points de terminaison en ligne Kubernetes :

Code d’état Erreur Description
409 Erreur de conflit Quand une opération est déjà en cours, toute nouvelle opération sur ce même point de terminaison en ligne répond en indiquant une erreur de conflit 409. Par exemple, si une opération de création ou de mise à jour du point de terminaison en ligne est en cours et que vous déclenchez une nouvelle opération de suppression, une erreur est générée.
502 Exception ou blocage dans la méthode run() du fichier score.py Quand il existe une erreur dans score.py, par exemple un package importé inexistant dans l’environnement Conda, une erreur de syntaxe ou un échec dans la méthode init(), consultez ERROR: ResourceNotReady pour déboguer le fichier.
503 Pics importants de requêtes par seconde L'Autoscaler est conçu pour gérer des changements progressifs de charge. Si vous recevez des pics importants de requêtes par seconde, il est possible que les clients reçoivent un code d’état HTTP 503. Même si la mise à l'échelle automatique réagit rapidement, il faut beaucoup de temps à AKS pour créer d'autres conteneurs. Consultez Comment éviter les erreurs de code d’état 503.
504 Délai d’expiration de la requête Un code d’état 504 indique que la requête a expiré. Le paramètre du délai d’expiration par défaut est 5 secondes. Vous pouvez augmenter le délai d’expiration ou essayer d’accélérer le point de terminaison en modifiant le fichier score.py pour supprimer les appels inutiles. Si ces actions ne corrigent pas le problème, il est possible que le code soit dans un état sans réponse ou de boucle infinie. Suivez ERROR: ResourceNotReady pour déboguer le fichier score.py.
500 Erreur interne du serveur L’infrastructure provisionnée par Azure Machine Learning échoue.

Comment éviter les erreurs de code d’état 503

Les déploiements en ligne Kubernetes prennent en charge la mise à l’échelle automatique, qui permet d’ajouter des réplicas pour prendre en charge une charge supplémentaire. Pour découvrir plus d’informations, consultez Routeur d’inférence Azure Machine Learning. La décision d’effectuer un scale-up ou un scale-down est basée sur l’utilisation des réplicas de conteneur actuels.

Deux actions peuvent permettre d’empêcher les erreurs de code d’état 503 : modifier le niveau d’utilisation pour créer des réplicas ou modifier le nombre minimal de réplicas. Vous pouvez utiliser ces approches individuellement ou conjointement.

  • Modifiez la cible d’utilisation à laquelle la mise à l’échelle automatique crée des réplicas en définissant autoscale_target_utilization sur une valeur inférieure. Cette modification n’entraîne pas l’accélération de la création des réplicas, mais un seuil d’utilisation inférieur. Par exemple, la modification de la valeur sur 30 % provoque la création de réplicas lorsqu’une utilisation à 30 % se produit, au lieu d’attendre que le service soit utilisé à 70 %.

  • Modifiez le nombre minimal de réplicas pour fournit un pool supérieur pouvant traiter les pics entrants.

Calcul du nombre d’instances

Pour augmenter le nombre d’instances, vous pouvez calculer les réplicas nécessaires comme suit :

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)

Remarque

Si vous recevez des pics de requêtes supérieurs au nouveau nombre minimal pouvant être géré par les réplicas, vous risquez de recevoir à nouveau le code d’état 503. Par exemple, à mesure que le trafic vers votre point de terminaison augmente, il est possible que vous deviez augmenter le nombre minimal de réplicas.

Si le point de terminaison en ligne Kubernetes utilise déjà le nombre maximal de réplicas actuel et que vous obtenez encore des codes d’état 503, augmentez la valeur de autoscale_max_replicas pour accroître le nombre maximal de réplicas.

Problèmes d’isolation réseau

Cette section offre des informations sur les problèmes courants d’isolement réseau.

Échec de la création du point de terminaison en ligne avec un message V1LegacyMode == true

Vous pouvez configurer l’espace de travail Azure Machine Learning pour v1_legacy_mode, ce qui désactive les API v2. Les points de terminaison en ligne managés sont une fonctionnalité de la plateforme d’API v2 et ne fonctionnent pas si vous activez v1_legacy_mode pour l’espace de travail.

Pour désactiver v1_legacy_mode, consultez Isolement réseau avec v2.

Important

Contactez votre équipe de sécurité du réseau avant de désactiver v1_legacy_mode, car elle peut l’avoir activé pour une raison spécifique.

Échec de la création d’un point de terminaison en ligne avec l’authentification basée sur une clé

Utilisez la commande suivante pour répertorier les règles réseau du coffre de clés Azure pour votre espace de travail. Remplacez <keyvault-name> par le nom de votre coffre de clés :

az keyvault network-rule list -n <keyvault-name>

Cette commande retourne une réponse similaire au code JSON suivant :

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Si bypass n’a pas la valeur AzureServices, suivez les conseils donnés dans Configurer les paramètres réseau du coffre de clés pour lui affecter la valeur AzureServices.

Échec des déploiements en ligne avec une erreur de téléchargement d’image

Remarque

Ce problème s’applique lorsque vous utilisez la méthode d’isolation réseau héritée pour les points de terminaison en ligne managés, dans laquelle Azure Machine Learning crée un réseau virtuel managé pour chaque déploiement sous un point de terminaison.

  1. Vérifiez si l’indicateur egress-public-network-access est disabled pour le déploiement. Si cet indicateur est activé et que la visibilité du registre de conteneurs est privée, cet échec est attendu.

  2. Utilisez la commande suivante pour vérifier l’état de la connexion au point de terminaison privé. Remplacez <registry-name> par le nom du registre de conteneurs Azure de votre espace de travail :

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    Dans le code de réponse, vérifiez que le champ status a la valeur Approved. Dans le cas contraire, utilisez la commande suivante pour l’approuver. Remplacez <private-endpoint-name> par le nom retourné par la commande précédente.

    az network private-endpoint-connection approve -n <private-endpoint-name>

Impossible de résoudre le point de terminaison de scoring

  1. Vérifiez que le client qui émet la requête de scoring est un réseau virtuel ayant accès à l’espace de travail Azure Machine Learning.

  2. Utilisez la commande nslookup sur le nom d’hôte du point de terminaison pour récupérer les informations d’adresse IP, par exemple :

    nslookup endpointname.westcentralus.inference.ml.azure.com

    La réponse contient une adresse qui doit se trouver dans la plage fournie par le réseau virtuel.

    Remarque

    • Pour le point de terminaison en ligne Kubernetes, le nom d’hôte du point de terminaison doit être le CName (nom de domaine) spécifié dans votre cluster Kubernetes.
    • Si le point de terminaison est HTTP, l’adresse IP est contenue dans l’URI du point de terminaison que vous pouvez obtenir directement dans l’interface utilisateur de studio.
    • Vous trouverez d’autres façons d’obtenir l’adresse IP du point de terminaison dans Sécuriser le point de terminaison en ligne Kubernetes.

  3. Si la commande nslookup ne résout pas le nom d’hôte, prenez les mesures suivantes :

Points de terminaison en ligne managés

  1. Utilisez la commande suivante pour vérifier qu’un enregistrement A existe dans la zone DNS (Domain Name System) pour le réseau virtuel.

    az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

    Les résultats doivent contenir une entrée similaire à *.<GUID>.inference.<region>.

  2. Si aucune valeur d’inférence n’est retournée, supprimez le point de terminaison privé de l’espace de travail, puis recréez-le. Pour plus d’informations, consultez Guide pratique pour configurer un point de terminaison privé.

  3. Si l’espace de travail avec un point de terminaison privé utilise un serveur DNS personnalisé, exécutez la commande suivante pour vérifier que la résolution du DNS personnalisé fonctionne correctement.

dig endpointname.westcentralus.inference.ml.azure.com

Points de terminaison en ligne Kubernetes

  1. Vérifiez la configuration DNS dans le cluster Kubernetes.

  2. De plus, vérifiez si azureml-fe fonctionne comme prévu, en utilisant la commande suivante :

    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"

    Pour HTTP, utilisez la commande suivante :

     curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

  3. Si les connexions HTTP via cURL sont défaillantes, ou s’il existe un dépassement du délai d’expiration alors que la connexion HTTP fonctionne, vérifiez que le certificat est valide.

  4. Si le processus précédent ne parvient pas à résoudre en enregistrement A, vérifiez si la résolution fonctionne à partir d’Azure DNS (168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

  5. Si la commande précédente réussit, vous pouvez résoudre des problèmes de redirecteur conditionnel pour la liaison privée sur le DNS personnalisé.

Les déploiements en ligne ne peuvent pas faire l’objet d’un scoring

  1. Exécutez la commande suivante pour voir si le déploiement a été correct :

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    Si le déploiement a réussi, la valeur de state est Succeeded.

  2. Si le déploiement a réussi, utilisez la commande suivante pour vérifier que le trafic est affecté au déploiement. Remplacez <endpointname> par le nom de votre point de terminaison.

    az ml online-endpoint show -n <endpointname>  --query traffic

    La réponse de cette commande doit indiquer le pourcentage du trafic affecté aux déploiements.

    Conseil

    Cette étape n’est pas nécessaire si vous utilisez l’en-tête azureml-model-deployment dans votre requête pour cibler ce déploiement.

  3. Si les affectations de trafic (ou l’en-tête de déploiement) sont définies correctement, utilisez la commande suivante pour obtenir les journaux d’activité du point de terminaison. Remplacez <endpointname> par le nom du point de terminaison et <deploymentname> par le déploiement.

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

  4. Passez en revue les journaux pour voir s’il existe un problème d’exécution du code de scoring lorsque vous envoyez une requête au déploiement.

Problèmes du serveur d’inférence

Cette section fournit des conseils de résolution des problèmes de base pour le Serveur HTTP d’inférence Azure Machine Learning.

Vérifier les packages installés

Suivez ces étapes pour résoudre les problèmes liés aux packages installés.

  1. Collectez des informations sur les packages et les versions installés pour votre environnement Python.

  2. Confirmez que la version du package Python azureml-inference-server-http spécifiée dans le fichier d’environnement correspond à la version du serveur HTTP d’inférence Azure Machine Learning affichée dans le journal de démarrage.

    Dans certains cas, le programme de résolution de dépendance pip installe des versions de package inattendues. Vous devrez peut-être exécuter pip pour corriger les packages et les versions installés.

  3. Si vous spécifiez Flask ou ses dépendances dans votre environnement, supprimez ces éléments.

    • Les packages dépendants incluent flask, jinja2, itsdangerous, werkzeug, markupsafe et click.
    • flask est listé comme une dépendance dans le package de serveur. La meilleure approche consiste à autoriser le serveur d’inférence à installer le package flask.
    • Lorsque le serveur d’inférence est configuré pour prendre en charge les nouvelles versions de Flask, le serveur reçoit automatiquement les mises à jour du package dès leur mise à disposition.

Vérifier la version du serveur

Le package de serveur azureml-inference-server-http est publié sur PyPI. La page PyPI répertorie le journal des modifications et toutes les versions précédentes.

Si vous utilisez une version antérieure du package, mettez à jour votre configuration vers la dernière version. Le tableau suivant récapitule les versions stables, les problèmes courants et les ajustements recommandés :

Version du package Description Problème Résolution
0.4.x Incluse dans les images de formation datant de 20220601 et antérieures et le package azureml-defaults versions .1.34 à 1.43. La dernière version stable est la version 0.4.13. Pour les versions de serveur antérieures à 0.4.11, il est possible que vous rencontriez des problèmes de dépendance à Flask comme "can't import name Markup from jinja2". Effectuez si possible une mise à niveau vers la version 0.4.13 ou 0.8.x (la dernière version).
0.6.x Préinstallée dans les images d’inférence datant de 20220516 et antérieures. La dernière version stable est la version 0.6.1. N/A N/A
0.7.x Prend en charge Flask 2. La dernière version stable est la version 0.7.7. N/A N/A
0.8.x Le format du journal a changé. La prise en charge de Python 3.6 a pris fin. N/A N/A

Vérifier les dépendances de package

Les packages dépendants les plus pertinents pour le package de serveur azureml-inference-server-http sont les suivants :

  • flask
  • opencensus-ext-azure
  • inference-schema

Si vous avez spécifié le package azureml-defaults dans votre environnement Python, le package azureml-inference-server-http est un package dépendant. La dépendance est installée automatiquement.

Conseil

Si vous utilisez le Kit de développement logiciel (SDK) Python v1 et que vous ne spécifiez pas explicitement le package azureml-defaults dans votre environnement Python, le SDK peut ajouter automatiquement le package. Toutefois, la version du packager est verrouillée par rapport à la version du SDK. Par exemple, si la version du SDK est 1.38.0, l’entrée azureml-defaults==1.38.0 est ajoutée aux exigences pip de l’environnement.

TypeError pendant le démarrage du serveur

Vous risquez de rencontrer l’erreur TypeError suivante lors du démarrage du serveur :

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

Cette erreur se produit lorsque Flask 2 est installé dans votre environnement Python, mais que votre version de package azureml-inference-server-http ne prend pas en charge Flask 2. La prise en charge de Flask 2 est disponible dans le package azureml-inference-server-http versions 0.7.0 et ultérieures, ainsi que le package azureml-defaults versions 1.44 et ultérieures.

  • Si vous n’utilisez pas le package Flask 2 dans une image Docker Azure Machine Learning, utilisez la dernière version du package azureml-inference-server-http ou azureml-defaults.

  • Si vous utilisez le package Flask 2 dans une image Docker Azure Machine Learning, vérifiez que la version de build de l’image indique juillet 2022 ou une date ultérieure.

    Vous trouverez la version de l’image dans les journaux du conteneur. Par exemple :

    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 |

    La date de génération de l’image apparaît après la notation Materialization Build. Dans l’exemple précédent, la version de l’image est 20220708 ou le 8 juillet 2022. Dans cet exemple, l’image est compatible avec Flask 2.

    Si vous ne voyez pas de message similaire dans le journal de votre conteneur, votre image est obsolète et doit être mise à jour. Si vous utilisez une image CUDA (Compute Unified Device Architecture) et que vous ne trouvez pas d’image plus récente, vérifiez si votre image est déconseillée dans AzureML-Containers. Vous trouverez des remplacements désignés pour les images déconseillées.

    Si vous utilisez le serveur avec un point de terminaison en ligne, vous trouverez également les journaux dans les Journaux d’activité de page Points de terminaison dans Azure Machine Learning studio.

Si vous effectuez le déploiement avec le SDK v1 et que vous ne spécifiez pas explicitement d’image dans la configuration de votre déploiement, le serveur applique le package openmpi4.1.0-ubuntu20.04 avec une version qui correspond à l’ensemble d’outils de votre SDK local. Toutefois, la version installée peut ne pas être la dernière version disponible de l’image.

Pour le SDK version 1.43, le serveur installe la version par défaut du package openmpi4.1.0-ubuntu20.04:20220616, mais cette version n’est pas compatible avec le SDK 1.43. Veillez à utiliser la dernière version du kit SDK pour votre déploiement.

Si vous ne pouvez pas mettre à jour l’image, vous pouvez éviter temporairement le problème en épinglant l’entrée azureml-defaults==1.43 ou azureml-inference-server-http~=0.4.13 dans votre fichier d’environnement. Ces entrées indiquent au serveur d’installer l’ancienne version avec flask 1.0.x.

ImportError ou ModuleNotFoundError lors du démarrage du serveur

Vous risquez de rencontrer une erreur ImportError ou ModuleNotFoundError sur des modules spécifiques lors du démarrage du serveur, notamment opencensus, jinja2, markupsafe ou click. L’exemple suivant montre le message d’erreur :

ImportError: cannot import name 'Markup' from 'jinja2'

Les erreurs liées à l’importation et au module se produisent lorsque vous utilisez la version 0.4.10 et versions antérieures du serveur qui n’épinglent pas la dépendance Flask à une version compatible. Pour éviter le problème, installez une version ultérieure du serveur.

Autres problèmes courants

D’autres problèmes courants liés au point de terminaison en ligne sont liés à l’installation et la mise à l’échelle de Conda.

Problèmes d’installation de Conda

Les problèmes liés au déploiement MLflow résultent généralement de problèmes liés à l’installation de l’environnement utilisateur spécifié dans le fichier conda.yml.

Pour déboguer des problèmes d’installation de conda, essayez les étapes suivantes :

  1. Vérifiez les journaux d’activité de l’installation de Conda. Si le conteneur s’est bloqué ou prend trop de temps à démarrer, il est probable que la mise à jour de l’environnement Conda n’a pas été résolue correctement.
  2. Installez le fichier mlflow conda localement avec la commande conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. En cas d’erreurs localement, essayez de résoudre l’environnement conda et de créer un environnement fonctionnel avant de le redéployer.
  4. Si le conteneur se bloque même s’il se résout localement, la taille de la référence SKU utilisée pour le déploiement peut être trop petite.
    • L’installation du package Conda se produit au moment du runtime. Par conséquent, si la taille de la référence SKU est trop petite pour prendre en charge tous les packages détaillés dans le fichier d’environnement conda.yml, il est possible que le conteneur se bloque.
    • Une machine virtuelle Standard_F4s_v2 est une bonne taille de référence SKU de départ, mais il est possible que vous ayez besoin de machines virtuelles de taille supérieure en fonction des dépendances spécifiées par le fichier Conda.
    • Pour les points de terminaison en ligne Kubernetes, le cluster Kubernetes doit disposer d’un minimum de 4 cœurs de processeur virtuel et de 8 Go de mémoire.

Problèmes de mise à l’échelle automatique

Si vous rencontrez des problèmes de mise à l’échelle automatique, consultez Dépanner la mise à l’échelle automatique Azure Monitor.

Pour les points de terminaison en ligne Kubernetes, le routeur d’inférence Azure Machine Learning est un composant front-end qui gère la mise à l’échelle automatique pour tous les modèles de déploiement sur le cluster Kubernetes. Pour découvrir plus d’informations, consultez Mise à l’échelle automatique du routage d’inférence Kubernetes.

Contenu connexe