Travaux

Si la création de l'exécution de travail échoue et que vous voyez les détails de cycle de vie suivants :

The specified log group is not found or not authorized. Cannot create log object on behalf of the user.
Ensure the log group is valid and the user has appropriate permissions configured

OCID de groupe de journaux incorrect

Assurez-vous que l'OCID du groupe de journaux spécifié dans la configuration de création d'exécution de travail est correct.

Autorisations incorrectes

Les autorisations sont manquantes. L'utilisateur qui crée l'exécution de travail doit être autorisé à journaliser les groupes et le contenu de journalisation. Cela permet de s'assurer que l'utilisateur a accès au groupe de journaux et à l'objet de journal spécifiés. En outre, pour faciliter la création d'un nouvel objet de journal au nom de l'utilisateur lorsque enableAutoLogCreation est activé.

allow group <group-name> to manage log-groups in compartment <log-compartment-name>
                            

allow group <group-name> to use log-content in compartment <log-compartment-name>
                            

Les erreurs courantes sont les suivantes :

• Accorder uniquement à l'utilisateur les autorisations use sur les groupes de journaux. L'autorisation manage est requise lorsque enableAutoLogCreation est activé.
• Autoriser le mauvais groupe. Le groupe fait référence au groupe dans lequel se trouve le créateur de l'exécution de travail. Si vous créez des exécutions de travail à l'aide de principaux d'instance, la politique requise est la suivante :

  dynamic group <instance-principal-dynamic-group-name>
                          

Lors de la tentative de création d'une tâche d'utilisation de votre propre conteneur, elle échoue avec des erreurs lors du téléchargement de l'image, assurez-vous des éléments suivants :

• Il se peut que l'hôte soit manquant dans le chemin d'accès à l'image. Le format correct pour le chemin d'image est <region-key>.ocir.io/<tenancy-namespace>/<repository-name>:<tag> . Une erreur courante est de manquer la première partie du chemin (l'URL de l'hôte).
• L'image de conteneur se trouve dans une région différente de celle de l'exécution de travail : Les tâches du service de science des données ne prennent pas en charge l'extraction d'images à partir d'une inter-région OCIR. Assurez-vous que l'image de conteneur se trouve dans la même région que l'exécution de travail.

Lorsque vous créez une tâche ou une exécution de travail et que cette erreur se produit, cela signifie que vous avez atteint les limites de service OCI. Regardez la vidéo sur l'augmentation des limites du service de science des données pour savoir comment soumettre une demande d'augmentation des limites.

Si cette erreur se produit lors de la création d'une exécution de travail (comme le décrit le détail du cycle de vie), il n'y a pas de capacité à créer l'exécution. Vous devez réessayer plus tard, essayer dans d'autres régions ou utiliser des familles de formes différentes.

Ce type d'erreur n'a aucun rapport avec le service de science des données. Il s'agit plutôt d'un problème côté utilisateur lors de la création et de la signature des demandes.

Si vous utilisez le principal d'utilisateur pour effectuer la demande, certaines erreurs courantes sont les suivantes :

• Ayant des clés d'API non valides, voir Affectation de clés.
• Faire une demande immédiatement après le chargement d'une clé publique. Les informations d'identité ont besoin de temps pour se propager entre les régions d'un domaine. Généralement, cela se produit dans les 5 minutes, mais parfois plus de temps peut être nécessaire.

Pour une exécution de travail créée avec succès qui a atteint l'état IN_PROGRESS, mais aucun journal n'apparaît dans l'objet de journal. En général, cela se produit lorsque les politiques sont manquantes ou incorrectes. L'exécution de travail doit être autorisée à écrire dans le journal d'exécution de travail.

Tout d'abord, définissez un groupe dynamique pour la ressource d'exécution de travail :

all { resource.type='datasciencejobrun', resource.compartment.id='<job-run-compartment-ocid>' }

Définissez ensuite l'accès à ce groupe dynamique :

allow dynamic-group <job-runs-dynamic-group> to use log-content in compartment <log-compartment-name>
                

Certaines erreurs courantes sont :

• Un compartiment incorrect a été spécifié. Notez que le compartiment décrit dans les politiques précédentes est différent.
  • Pour la définition de groupe dynamique, il s'agit du compartiment de l'exécution de travail.
  • Pour l'énoncé de politique d'accès au contenu du journal, il s'agit du compartiment du journal.
• Définition du groupe dynamique à l'aide de compartment.id au lieu de resource.compartment.id.
• Un type de ressource incorrect a été inclus dans la définition du groupe dynamique. Probablement, le groupe dynamique défini est pour la ressource de session de carnet et n'inclut pas la ressource d'exécution de travail. Le principal de ressource datasciencejobrun est utilisé pour écrire dans les journaux pour l'intégration de la journalisation de l'exécution de travail. Il doit donc être inclus dans la définition du groupe dynamique.

Les tâches du service de science des données prennent en charge l'intégration au service de journalisation OCI pour la journalisation automatique. Si les journaux apparaissent tronqués ou incomplets, cela est probablement dû aux limites de service de journalisation suivantes :

• Chaque entrée doit être inférieure à 1 Mo.
• Tout champ de données de journal ne peut pas comporter plus de 10 000 caractères.

Si les données dépassent ces limites, l'entrée de journal est tronquée lors de l'ingestion.

Si vous ne voyez pas les mesures d'exécution de travail pendant ou après le traitement de la tâche, il est probable que les politiques correctes ne soient pas configurées. Assurez-vous d'avoir la politique suivante :

allow group <user-group-name> to read metrics in compartment <compartment-name>
                

Le compartiment est le compartiment de l'exécution de travail.

Cela signifie que l'exécution du code a échoué avec le code de sortie indiqué lié au code. Activez l'intégration de la journalisation et assurez-vous de disposer de suffisamment d'énoncés de journal dans le code pour déboguer le problème.

Les travaux indiquent le code de sortie d'un échec d'exécution de travail lorsqu'il se termine. Ces informations sont disponibles dans le champ détaillé du cycle de vie de l'exécution de travail. Cette fonction est prise en charge pour toutes les exécutions de travail, y compris l'utilisation de vos propres exécutions de travail conteneur.

Si vous constatez que le code de sortie avec lequel vous savez que l'exécution du travail a échoué n'est pas correctement indiqué, le code de sortie n'est probablement pas propagé correctement.

Certaines erreurs courantes sont :

• Si vous utilisez un script shell comme point d'entrée démarrer d'autres fichiers à exécuter (autres fichiers python), le script shell doit capturer le code de sortie de l'exécution du fichier interne, puis quitter le script shell avec le code de sortie capturé.
• Lancer des exceptions peut ne pas suffire. L'exécution du fichier (ou le conteneur pour apporter votre propre conteneur) doit explicitement quitter avec un code de sortie. En Python, cela se fait à l'aide de sys.exit(ERROR_CODE).
• Utilisation d'un type incorrect pour la valeur du code de sortie. Généralement, le type incorrect utilisé est une chaîne. Les codes de sortie doivent être des nombres ou des nombres entiers, et compris entre 1 et 255, comme décrit dans Emploi avec codes de sortie.

La spécification de JOB_RUN_ENTRYPOINT à un fichier qui n'existe pas ou qui n'est pas à l'emplacement spécifié entraîne cette erreur :

Job run bootstrap failure: invalid job run entry point (JOB_RUN_ENTRYPOINT).