Travaux

Si la création de l'exécution de travail échoue et que vous obtenez 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 de groupe de journaux indiqué dans la configuration de création d'exécution de travail est correct.

Droits d'accès incorrects

Il vous manque des autorisations. L'utilisateur qui crée l'exécution de travail doit disposer des droits d'accès permettant de 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 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 :

• Octroi de droits d'accès use uniquement à l'utilisateur sur les groupes de journaux. Le droit d'accès manage est requis 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 stratégie requise est la suivante :

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

Lorsque vous essayez de créer votre propre exécution de travail Conteneur, celle-ci échoue avec des erreurs lors du téléchargement de l'image, vérifiez les points suivants :

• L'hôte peut être 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 l'exécution de travail : les travaux Data Science ne prennent pas en charge l'extraction d'images à partir d'une région croisée 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 un travail 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 présentant l'augmentation des limites de service Data Science pour découvrir comment soumettre une demande d'augmentation des limites de service.

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 aucune capacité pour créer l'exécution. Vous devez réessayer ultérieurement, essayer dans d'autres régions ou utiliser différentes familles de formes.

Ce type d'erreur n'est pas lié au service Data Science. 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 utilisateur pour effectuer la demande, certaines erreurs courantes sont les suivantes :

• En cas de clés d'API non valides, reportez-vous à Affectation de clés.
• Effectuer une demande immédiatement après avoir téléchargé une clé publique. Les informations d'identité ont besoin de temps pour se propager dans 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 des stratégies sont manquantes ou incorrectes. L'exécution de travail doit être autorisée à écrire dans le journal d'exécution de travail.

Définissez d'abord 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 cet accès au groupe dynamique :

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

Les erreurs courantes sont les suivantes :

• Un compartiment incorrect est indiqué. Le compartiment décrit dans les stratégies 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'instruction de stratégie d'accès au contenu de 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. Il est probable que le groupe dynamique défini concerne la ressource de session de bloc-notes 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 journalisation d'exécution de travail. Il doit donc être inclus dans la définition de groupe dynamique.

Les travaux Data Science prennent en charge l'intégration avec le service OCI Logging pour la journalisation automatique. Si les journaux semblent tronqués ou incomplets, cela est probablement dû aux limites de service Logging suivantes :

• Chaque entrée doit être inférieure à 1 Mo.
• Un 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 du travail, il est probable que les stratégies appropriées ne soient pas configurées. Assurez-vous que vous disposez de la stratégie suivante :

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

Le compartiment est le compartiment du traitement 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 que le code contient suffisamment d'instructions de journal pour résoudre le problème.

Les travaux indiquent le code de sortie d'un échec d'exécution de travail lorsqu'il se ferme. Ces informations sont disponibles dans le champ de détails du cycle de vie de l'exécution de travail. Cette option 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 remarquez que le code de sortie avec lequel vous savez que l'exécution du travail a échoué n'est pas correctement indiqué, il est probable que le code de sortie ne soit pas propagé correctement.

Les erreurs courantes sont les suivantes :

• Si vous utilisez un script shell comme point d'entrée pour démarrer d'autres fichiers à exécuter (d'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é.
• Générer des exceptions peut ne pas suffire. L'exécution de fichier (ou conteneur permettant d'utiliser votre propre conteneur) doit se fermer explicitement avec un code de sortie. En Python, cela se fait à l'aide de sys.exit(ERROR_CODE).
• Utilisation d'un type incorrect pour le code value de sortie. En général, le type incorrect utilisé est une chaîne. Les codes de sortie doivent être des nombres ou des entiers, et être compris entre 1 et 255, comme décrit dans la section Emploi avec codes de sortie.

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

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