Share via

Résolution des problèmes de points de terminaison de traitement de lots

  • Article

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

Découvrez comment résoudre les erreurs courantes liées à l’utilisation de points de terminaison de traitement par lots pour le scoring par lot. Dans cet article, vous apprenez :

Comprendre les journaux d’un travail de scoring par lot

Obtenir des journaux d’activité

Quand vous appelez un point de terminaison de lot à l’aide d’Azure CLI ou de l’API REST, le travail de scoring par lot s’exécute de façon asynchrone. Il existe deux options pour obtenir les journaux d’un travail de scoring par lot.

Option 1 : Streamer les journaux à la console locale

Vous pouvez exécuter la commande suivante pour streamer les journaux générés par le système à votre console. Seuls les journaux dans le dossier azureml-logs sont streamés.

az ml job stream --name <job_name>

Option 2 : Voir les journaux dans le studio

Pour obtenir le lien vers l’exécution dans le studio, exécutez :

az ml job show --name <job_name> --query services.Studio.endpoint -o tsv
  1. Ouvrez le travail dans le studio à l’aide de la valeur retournée par la commande ci-dessus.
  2. Choisissez batchscoring
  3. Ouvrez l’onglet Sorties + journaux
  4. Choisissez un ou plusieurs journaux à examiner

Comprendre la structure des journaux

Il existe deux dossiers de journaux de niveau supérieur : azureml-logs et logs.

Le fichier ~/azureml-logs/70_driver_log.txt contient des informations provenant du contrôleur qui lance le script de scoring.

En raison de la nature distribuée des travaux de scoring par lot, il existe des journaux provenant de plusieurs sources différentes. Toutefois, deux fichiers combinés sont créés et fournissent des informations générales :

  • ~/logs/job_progress_overview.txt : Ce fichier fournit des informations générales sur le nombre de mini-lots (également appelés tâches) créés jusqu’à présent et le nombre de mini-lots traités jusqu’à présent. À l’achèvement des mini-lots, le journal enregistre les résultats du travail. Si le travail a échoué, le message d’erreur s’affiche et indique où démarrer la résolution des problèmes.

  • ~/logs/sys/master_role.txt: Ce fichier fournit la vue du nœud principal (également connu sous le nom d’orchestrateur) du travail en cours d’exécution. Ce journal fournit des informations sur la création de tâches, le monitoring de la progression et le résultat de la tâche.

Pour une compréhension concise des erreurs contenues dans votre script :

  • ~/logs/user/error.txt: Ce fichier tentera de résumer les erreurs contenues dans votre script.

Pour plus d’informations sur les erreurs dans votre script :

  • ~/logs/user/error/ : Ce fichier contient des traces de la pile complète d’exceptions levées pendant le chargement et l’exécution du script d’entrée.

Lorsque vous avez besoin de comprendre en détail la façon dont chaque nœud a exécuté le script de score, examinez les journaux de processus individuels pour chaque nœud. Les journaux de processus se trouvent dans le dossier sys/node, regroupés par nœuds Worker :

  • ~/logs/sys/node/<ip_address>/<process_name>.txt: Ce fichier fournit des informations détaillées sur chaque mini-lot au fur et à mesure qu’il est sélectionné ou traité par un Worker. Pour chaque mini-lot, ce fichier comprend les éléments suivants :

    • L’adresse IP et le PID du processus Worker.
    • Le nombre total d’éléments, le nombre d’éléments traités avec succès et le nombre d’élément ayant échoué.
    • L’heure de début, la durée, le temps de traitement et la durée de la méthode d’exécution.

Vous pouvez également voir les résultats de vérifications périodiques de l’utilisation de ressources pour chaque nœud. Les fichiers journaux et les fichiers d’installation se trouvent dans ce dossier :

  • ~/logs/perf : Définissez --resource_monitor_interval pour modifier l’intervalle de vérification en secondes. La valeur définir pour l’intervalle par défaut est 600, soit environ 10 minutes. Pour arrêter la surveillance, définissez la valeur sur 0. Chaque dossier <ip_address> comprend les éléments suivants :

    • os/ : informations sur tous les processus en cours d’exécution dans le nœud. Une vérification exécute une commande du système d’exploitation et enregistre le résultat dans un fichier. Sous Linux, la commande est ps.
      • %Y%m%d%H : le nom du sous-dossier correspond à l’heure.
        • processes_%M : le nom du fichier se termine par la minute à laquelle la vérification a été effectuée.
    • node_disk_usage.csv : utilisation détaillée du disque du nœud.
    • node_resource_usage.csv : vue d’ensemble de l’utilisation des ressources du nœud.
    • processes_resource_usage.csv : vue d’ensemble de l’utilisation des ressources de chaque processus.

Comment journaliser dans le script de scoring

Vous pouvez utiliser la journalisation Python dans votre script de scoring. Les journaux sont stockés dans logs/user/stdout/<node_id>/processNNN.stdout.txt.

import argparse
import logging

# Get logging_level
arg_parser = argparse.ArgumentParser(description="Argument parser.")
arg_parser.add_argument("--logging_level", type=str, help="logging level")
args, unknown_args = arg_parser.parse_known_args()
print(args.logging_level)

# Initialize Python logger
logger = logging.getLogger(__name__)
logger.setLevel(args.logging_level.upper())
logger.info("Info log statement")
logger.debug("Debug log statement")

Problèmes courants

La section suivante présente les problèmes courants liés au développement et à la consommation de points de terminaison de traitement par lots et les solutions possibles.

Aucun module nommé « azureml »

Message journalisé : No module named 'azureml'.

Motif : Les déploiements par lots Azure Machine Learning nécessitent l’installation du package azureml-core.

Solution : Ajoutez azureml-core à votre fichier de dépendances conda.

La sortie existe déjà

Motif : Le déploiement par lots Azure Machine Learning ne peut pas remplacer le fichier predictions.csv généré par la sortie.

Solution : Si vous êtes indiqué un emplacement de sortie pour les prédictions, assurez-vous que le chemin mène à un fichier non existant.

La fonction run() dans le script d’entrée avait un délai d’expiration pour [nombre] fois

Message journalisé : No progress update in [number] seconds. No progress update in this check. Wait [number] seconds since last update.

Motif : Les déploiements par lots peuvent être configurés avec une valeur timeout qui indique la durée pendant laquelle le déploiement doit attendre qu’un seul lot soit traité. Si l’exécution du lot prend plus que cette valeur, la tâche est abandonnée. Les tâches abandonnées peuvent être retentées jusqu’à un maximum de fois qui peuvent également être configurées. Si le timeout se produit à chaque nouvelle tentative, le travail de déploiement échoue. Ces propriétés peuvent être configurées pour chaque déploiement.

Solution : Augmentez la valeur timemout du déploiement en mettant celui-ci à jour. Ces propriétés sont configurées dans le paramètre retry_settings. Par défaut, un timeout=30 et un retries=3 sont configurés. Quand vous décidez de la valeur de timeout, prenez en compte le nombre de fichiers en cours de traitement sur chaque lot et la taille de chacun de ces fichiers. Vous pouvez également les diminuer pour prendre en charge un plus grand nombre de mini-lots de plus petite taille et donc plus rapides à exécuter.

ScriptExecution.StreamAccess.Authentication

Message journalisé : ScriptExecutionException a été provoqué par StreamAccessException. StreamAccessException a été provoqué par AuthenticationException.

Motif : Le cluster de calcul sur lequel le déploiement s’exécute ne peut pas monter le stockage où se trouve la ressource de données. L’identité managée du calcul ne dispose pas des autorisations nécessaires pour effectuer le montage.

Solutions : Vérifiez que l’identité associée au cluster de calcul sur lequel votre déploiement s’exécute dispose au moins de l’accès Lecteur des données blob du stockage au compte de stockage. Seuls les propriétaires de comptes de stockage peuvent modifier votre niveau d’accès via le portail Azure.

Échec de l’initialisation du jeu de données

Message journalisé : Échec de l’initialisation du jeu de données : UserErrorException : Message : Impossible de monter le jeu de données(id='xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', name='None', version=None). La source du jeu de données n’est pas accessible ou ne contient pas de données.

Motif : Le cluster de calcul sur lequel le déploiement s’exécute ne peut pas monter le stockage où se trouve la ressource de données. L’identité managée du calcul ne dispose pas des autorisations nécessaires pour effectuer le montage.

Solutions : Vérifiez que l’identité associée au cluster de calcul sur lequel votre déploiement s’exécute dispose au moins de l’accès Lecteur des données blob du stockage au compte de stockage. Seuls les propriétaires de comptes de stockage peuvent modifier votre niveau d’accès via le portail Azure.

Le nœud du jeu de données [code] fait référence au paramètre dataset_param qui n’a pas de valeur spécifiée ou de valeur par défaut

Message journalisé : le nœud du jeu de données [code] fait référence au paramètre dataset_param qui n’a pas de valeur spécifiée ou de valeur par défaut.

Motif : La ressource de données d’entrée fournie au point de terminaison de traitement par lots n’est pas prise en charge.

Solution : Veillez à fournir une entrée de données prise en charge pour les points de terminaison de traitement par lots.

Échec du programme utilisateur avec exception : l’exécution a échoué. Consultez les journaux pour plus d’informations

Message journalisé : Échec du programme utilisateur avec exception : l’exécution a échoué. Consultez les journaux pour plus d’informations. Vous pouvez vérifier les journaux/readme.txt pour connaître la disposition des journaux.

Motif : Une erreur s’est produite lors de l’exécution de la fonction init() ou run() du script de scoring.

Solution : Accédez à Sorties + Journaux et ouvrez le fichier à l’adresse logs > user > error > 10.0.0.X > process000.txt. Le message d’erreur généré par la méthode init() ou run() s’affiche.

ValueError : aucun objet à concaténer

Message journalisé : ValueError : aucun objet à concaténer.

Raison : tous les fichiers du mini-lot généré sont des types de fichiers endommagés ou non pris en charge. N’oubliez pas que les modèles MLflow prennent en charge un sous-ensemble de types de fichiers, comme indiqué dans Considérations lors du déploiement dans l’inférence par lots.

Solution: accédez au fichier logs/usr/stdout/<process-number>/process000.stdout.txt et recherchez des entrées telles que ERROR:azureml:Error processing input file. Si le type de fichier n’est pas pris en charge, consultez la liste des fichiers pris en charge. Vous devrez peut-être modifier le type de fichier des données d’entrée ou personnaliser le déploiement en fournissant un script de scoring comme indiqué dans la section Utilisation de modèles MLflow avec un script de scoring.

Aucun élément de mini-lot réussi n’est retourné à partir de run()

Message journalisé : Aucun élément de mini-lot réussi n’est retourné à partir de run(). Vérifiez « response: run() » dans https://aka.ms/batch-inference-documentation.

Motif : Le point de terminaison de traitement par lots n’a pas pu fournir de données à la méthode run() au format attendu. Cela peut être dû à des fichiers endommagés en cours de lecture ou à une incompatibilité des données d’entrée avec la signature du modèle (MLflow).

Solution : Pour comprendre ce qui peut se passer, accédez à Sorties + Journaux et ouvrez le fichier à l’adresse logs > user > stdout > 10.0.0.X > process000.stdout.txt. Recherchez les entrées d’erreur telles que Error processing input file. Vous devriez trouver des détails sur la raison pour laquelle le fichier d’entrée ne peut pas être lu correctement.

Les audiences dans JWT ne sont pas autorisées

Contexte : lors de l’appel d’un point de terminaison de lot à l’aide de ses API REST.

Motif : le jeton d’accès utilisé pour appeler l’API REST pour le point de terminaison/déploiement indique un jeton émis pour un autre public/service. Les jetons Microsoft Entra sont émis pour des actions spécifiques.

Solution : Lors de la génération d’un jeton d’authentification à utiliser avec l’API REST de point de terminaison Batch, vérifiez que le paramètre resourcea la valeurhttps://ml.azure.com. Notez que cette ressource est différente de la ressource que vous devez indiquer pour gérer le point de terminaison à l’aide de l’API REST. Toutes les ressources Azure (y compris les points de terminaison de lots) utilisent la ressource https://management.azure.com pour les gérer. Veillez à utiliser l’URI de ressource approprié pour chaque cas. Notez que si vous souhaitez utiliser l’API de gestion et l’API d’appel de travail en même temps, vous aurez besoin de deux jetons. Pour plus d’informations, consultez : Authentification sur les points de terminaison de lot (REST).

Aucun déploiement valide vers lequel effectuer l’acheminement. Vérifiez que le point de terminaison dispose d’au moins un déploiement avec des valeurs de pondération positives ou utilisez un en-tête propre au déploiement pour l’acheminement.

Raison : le déploiement par lots par défaut n’est pas défini correctement.

Solution : vérifiez que le déploiement par lots par défaut est correctement défini. Vous devrez peut-être mettre à jour le déploiement par lots par défaut. Pour plus d’informations, consultez Mettre à jour le déploiement par lots par défaut.

Limitations et scénarios non pris en charge

Lors de la conception de solutions Machine Learning qui s’appuient sur des points de terminaison de lot, certaines configurations et scénarios peuvent ne pas être pris en charge.

Les configurations espace de travail ne sont pas prises en charge:

  • Espaces de travail configurés avec Azure Container Registries avec la fonctionnalité quarantaine activée.
  • Espaces de travail avec des clés gérées par le client (CMK).

Les configurations calcul ne sont pas prises en charge:

  • Clusters Kubernetes Azure ARC.
  • Demande de ressources granulaire (mémoire, processeur virtuel, GPU) pour les clusters Azure Kubernetes. Seul le nombre d’instances peut être demandé.

Les types d’entrée suivants ne sont pas pris en charge:

  • Jeux de données tabulaires (V1).
  • Dossiers et jeux de données de fichiers (V1).
  • MLtable (V2).

Étapes suivantes