Dépannage d'Agent Platform Workbench

Cette page décrit les étapes de dépannage qui vous aideront si vous rencontrez des problèmes lors de l'utilisation de Gemini Enterprise Agent Platform Workbench.

Consultez également la page Résoudre les problèmes liés à Agent Platform pour obtenir de l'aide sur l'utilisation d'autres composants de Gemini Enterprise Agent Platform.

Cliquez sur l'une des catégories ci-après pour filtrer le contenu de cette page :

Instances Workbench Agent Platform

Cette section décrit les étapes de dépannage pour les instances Agent Platform Workbench.

Dépannage avec les outils d'IA

Cette section explique comment utiliser les outils d'IA pour résoudre les problèmes.

Résoudre les problèmes avec Cloud Assist Investigations

Lorsque vous connectez la plate-forme d'agent à d'autres produits Google Cloud , les investigations Gemini Cloud Assist peuvent vous aider à résoudre les problèmes d'intégration. Cela peut également accélérer le dépannage sur l'instance elle-même. Gemini Cloud Assist vous permet d'obtenir des insights à partir des métriques et des journaux générés par l'instance.

  • Arrêtez l'instance et suivez le lien View in Compute Engine.
  • Installez l'agent Ops (recommandé). Cette opération prendra quelques minutes.
  • Ajoutez un champ Métadonnées personnalisées notebook-enable-debug et définissez-le sur true.
  • Redémarrez l'instance et reproduisez le problème.
  • Activez et configurez l'API Cloud Assist Investigations.
  • Créez une enquête et décrivez le problème en détail à l'aide d'un prompt en langage naturel.
  • À mesure que vous saisissez du texte, une boîte de dialogue s'affiche et suggère des ressources à ajouter à l'enquête. Consultez cette liste et assurez-vous d'ajouter l'instance en tant que ressource, ainsi que toutes les autres ressources de cette liste de produits compatibles.
  • Lancez l'investigation et examinez les résultats.

Résoudre les problèmes liés aux fichiers de diagnostic avec Gemini CLI

Vous pouvez utiliser les résultats de l'investigation Cloud Assist pour effectuer une investigation plus approfondie basée sur l'IA sur le fichier de diagnostic de l'instance.

  • Exécutez l'outil de diagnostic et spécifiez un bucket Cloud Storage dans lequel importer les résultats.
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
  • Téléchargez le fichier de diagnostic sur votre poste de travail, puis installez et configurez Gemini CLI.
  • Commencez la demande, puis décrivez votre problème. Incluez l'hypothèse de l'investigation Cloud Assist dans le contexte. Demandez au modèle d'étendre l'enquête en lisant le contenu du fichier de diagnostic à l'aide de requêtes en langage naturel.

Se connecter à JupyterLab et l'ouvrir

Cette section décrit les étapes de dépannage pour la connexion et l'ouverture de JupyterLab.

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Problème

Lorsque vous cliquez sur Ouvrir JupyterLab, rien ne se passe.

Solution

Vérifiez que votre navigateur ne bloque pas l'ouverture automatique de nouveaux onglets. JupyterLab s'ouvre dans un nouvel onglet du navigateur.

Impossible d'accéder au terminal dans une instance Workbench Agent Platform

Problème

Si vous ne parvenez pas à accéder au terminal ou si vous ne trouvez pas la fenêtre de terminal dans le lanceur, il se peut que l'accès au terminal ne soit pas activé pour votre instance Agent Platform Workbench.

Solution

Vous devez créer une instance Agent Platform Workbench avec l'option Accès au terminal activée. Cette option ne peut plus être modifiée après la création de l'instance.

Erreur 502 lors de l'ouverture de JupyterLab

Problème

Une erreur 502 peut indiquer que votre instance Agent Platform Workbench n'est pas encore prête.

Solution

Attendez quelques minutes, actualisez l'onglet du navigateur de la console Google Cloud , puis réessayez.

Le notebook ne répond pas

Problème

Votre instance Agent Platform Workbench n'exécute pas de cellules ou semble être figée.

Solution

Essayez d'abord de redémarrer le noyau en cliquant sur Noyau dans le menu supérieur, puis sur Redémarrer le noyau. Si cela ne fonctionne pas, vous pouvez essayer les solutions suivantes :

  • Actualisez la page du navigateur JupyterLab. Une sortie de cellule non enregistrée n'est pas conservée. Vous devez donc exécuter à nouveau ces cellules pour générer à nouveau la sortie.
  • Réinitialisez votre instance.

Impossible de se connecter à l'instance Agent Platform Workbench à l'aide de SSH

Problème

Vous ne parvenez pas à vous connecter à votre instance à l'aide de SSH via une fenêtre de terminal.

Les instances Workbench Agent Platform utilisent OS Login pour activer l'accès SSH. Lorsque vous créez une instance, Agent Platform Workbench active OS Login par défaut en définissant la clé de métadonnées enable-oslogin sur TRUE. Si vous ne parvenez pas à vous connecter en SSH à votre instance, il est possible que cette clé de métadonnées doive être définie sur TRUE.

Solution

Il n'est pas possible de se connecter à une instance Agent Platform Workbench à l'aide de la console Google Cloud . Si vous ne parvenez pas à vous connecter à votre instance à l'aide de SSH via une fenêtre de terminal, consultez les articles suivants :

Pour définir la clé de métadonnéesenable-oslogin sur TRUE, utilisez la méthode projects.locations.instances.patch dans l'API Notebooks ou la commande gcloud workbench instances update dans le SDK Agent Platform.

Le quota de GPU a été dépassé

Problème

Vous ne pouvez pas créer d'instance Agent Platform Workbench avec des GPU.

Solution

Pour déterminer le nombre de GPU disponibles dans votre projet, accédez à la page Quotas. Si les GPU ne figurent pas sur la page "Quotas" ou que vous avez besoin d'un quota de GPU Compute Engine supplémentaire, vous pouvez demander une augmentation de quota. Consultez Demander une limite de quota supérieure.

Créer des instances Agent Platform Workbench

Cette section explique comment résoudre les problèmes liés à la création d'instances Agent Platform Workbench.

L'instance reste en attente indéfiniment ou est bloquée à l'état de provisionnement

Problème

Une fois que vous avez créé une instance Agent Platform Workbench, elle reste en attente indéfiniment. Une erreur semblable à l'erreur suivante peut apparaître dans les journaux série :

Could not resolve host: notebooks.googleapis.com

Si votre instance est bloquée à l'état de provisionnement, il est possible que la configuration de votre réseau privé soit incorrecte.

Solution

Suivez la procédure décrite dans la section Les journaux d'instance affichent des erreurs de connexion ou de délai avant expiration.

Impossible de créer une instance dans un réseau VPC partagé

Problème

Toute tentative de création d'une instance au sein d'un réseau VPC partagé génère un message d'erreur semblable à celui-ci :

Required 'compute.subnetworks.use' permission for
'projects/network-administration/regions/us-central1/subnetworks/v'

Solution

Le problème est que le compte de service Notebooks tente de créer l'instance sans les autorisations appropriées.

Pour vous assurer que le compte de service Notebooks dispose des autorisations nécessaires pour créer une instance Agent Platform Workbench dans un réseau VPC partagé, demandez à votre administrateur d'accorder le rôle IAM Utilisateur du réseau Compute (roles/compute.networkUser) au compte de service Notebooks sur le projet hôte.

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour garantir que le compte de service Notebooks peut créer une instance Agent Platform Workbench dans un réseau VPC partagé. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour garantir que le compte de service Notebooks peut créer une instance Agent Platform Workbench dans un réseau VPC partagé :

  • Pour utiliser des sous-réseaux : compute.subnetworks.use

Votre administrateur peut également attribuer au compte de service ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Impossible de créer une instance Agent Platform Workbench avec un conteneur personnalisé

Problème

Il n'existe aucune option permettant d'utiliser un conteneur personnalisé lors de la création d'une instance Agent Platform Workbench dans la console Google Cloud .

Solution

Il n'est pas possible d'ajouter un conteneur personnalisé à une instance Agent Platform Workbench, et vous ne pouvez pas ajouter de conteneur personnalisé à l'aide de la console Google Cloud .

Il est recommandé d'ajouter un environnement Conda au lieu d'utiliser un conteneur personnalisé.

L'API Notebooks permet l'ajout d'un conteneur personnalisé à une instance Agent Platform Workbench, mais cette capacité n'est pas disponible.

Impossible d'utiliser Gemini CLI

Problème

Le bloc Gemini CLI se trouve dans le lanceur JupyterLab et s'ouvre correctement, mais Gemini ne répond pas aux requêtes.

Solution

Il est possible qu'un administrateur ait bloqué l'accès à Gemini CLI. Consultez Contrôler l'accès à Gemini CLI.

Le bouton d'installation du stockage partagé ne s'affiche pas

Problème

Le bouton Mount shared storage (Installer le stockage partagé) ne se trouve pas dans l'onglet Explorateur de fichiers de l'interface JupyterLab.

Solution

L'autorisation storage.buckets.list est requise pour que le bouton Installer le stockage partagé s'affiche dans l'interface JupyterLab de votre instance Agent Platform Workbench. Demandez à votre administrateur d'accorder au compte de service de votre instance Agent Platform Workbench l'autorisation storage.buckets.list sur le projet.

Erreur 599 lors de l'utilisation de Managed Service pour Apache Spark

Problème

Toute tentative de création d'une instance compatible avec Managed Service pour Apache Spark génère un message d'erreur semblable à celui-ci :

HTTP 599: Unknown (Error from Gateway: [Timeout while connecting]
Exception while attempting to connect to Gateway server url.
Ensure gateway url is valid and the Gateway instance is running.)

Solution

Dans votre configuration Cloud DNS, ajoutez une entrée Cloud DNS pour le domaine *.googleusercontent.com.

Impossible d'installer l'extension JupyterLab tierce

Problème

Toute tentative d'installation d'une extension JupyterLab tierce génère un message Error: 500.

Solution

Les extensions JupyterLab tierces ne sont pas compatibles avec les instances Agent Platform Workbench.

Impossible de modifier la machine virtuelle sous-jacente

Problème

Lorsque vous essayez de modifier la machine virtuelle (VM) sous-jacente d'une instance Agent Platform Workbench, vous obtenez un message d'erreur semblable à celui-ci :

Current principal doesn't have permission to mutate this resource.

Solution

Cette erreur se produit car vous ne pouvez pas modifier la VM sous-jacente d'une instance à l'aide de la console Google Cloud ou de l'API Compute Engine.

Pour modifier la VM sous-jacente d'une instance Agent Platform Workbench, utilisez la méthode projects.locations.instances.patch de l'API Notebooks, ou bien la commande gcloud workbench instances update dans le SDK Agent Platform.

Les packages pip ne sont plus disponibles après l'ajout de l'environnement Conda.

Problème

Vos packages pip ne sont plus disponibles après l'ajout d'un noyau basé sur Conda.

Solution

Pour résoudre le problème, consultez la section Ajouter un environnement Conda et essayez les solutions suivantes :

  • Vérifiez que vous avez utilisé la variable DL_ANACONDA_ENV_HOME et qu'elle contient le nom de votre environnement.

  • Vérifiez que pip se trouve dans un chemin semblable à opt/conda/envs/ENVIRONMENT/bin/pip. Vous pouvez exécuter la commande which pip pour obtenir le chemin.

Impossible de copier ou d'accéder aux données d'une instance avec accès utilisateur unique

Problème

Les données d'une instance avec accès utilisateur unique sont inaccessibles.

Pour les instances Agent Platform Workbench configurées avec accès utilisateur unique, seul l'utilisateur unique (le propriétaire) peut accéder aux données de l'instance.

Solution

Pour accéder aux données ou les copier lorsque vous n'êtes pas le propriétaire de l'instance, ouvrez une demande d'assistance.

Arrêt inattendu

Problème

Votre instance Agent Platform Workbench s'arrête de manière inattendue.

Solution

Si votre instance s'arrête de manière inattendue, cela peut être dû au fait que l'arrêt en cas d'inactivité a été lancé.

Si vous avez activé l'arrêt en cas d'inactivité, votre instance s'arrête en l'absence d'activité du noyau pour la période spécifiée. Par exemple, l'exécution d'une cellule ou une nouvelle impression de sortie sur un notebook est une activité qui réinitialise le minuteur de délai d'inactivité. L'utilisation du processeur ne réinitialise pas le minuteur de délai d'inactivité.

Les journaux de l'instance affichent des erreurs de connexion ou de délai avant expiration

Problème

Les journaux de votre instance Agent Platform Workbench affichent des erreurs de connexion ou de délai avant expiration.

Solution

Si vous constatez des erreurs de connexion ou de délai avant expiration dans les journaux de l'instance, assurez-vous que le serveur Jupyter s'exécute sur le port 8080. Suivez la procédure décrite dans la section Vérifier que l'API interne Jupyter est active.

Si vous avez désactivé External IP et que vous utilisez un réseau VPC privé, assurez-vous également d'avoir suivi la documentation sur les options de configuration du réseau. Réfléchissez aux éléments suivants :

Les journaux d'instance indiquent "Impossible de contacter l'API Jupyter" ou "ReadTimeoutError"

Problème

Les journaux de votre instance Agent Platform Workbench affichent une erreur semblable à celle-ci :

notebooks_collection_agent. Unable to contact Jupyter API:
HTTPConnectionPool(host=\'127.0.0.1\', port=8080):
Max retries exceeded ReadTimeoutError(\"HTTPConnectionPool(host=\'127.0.0.1\', port=8080

Solution

Suivez la procédure décrite dans la section Les journaux d'instance affichent des erreurs de connexion ou de délai avant expiration. Vous pouvez également essayer de modifier le script de l'agent de collecte des notebooks pour remplacer HTTP_TIMEOUT_SESSION par une valeur plus élevée, par exemple 60, afin de vérifier si la requête a échoué parce que l'appel prend trop de temps à répondre ou que l'URL demandée ne peut pas être atteinte.

L'adresse docker0 est en conflit avec l'adressage VPC

Problème

Par défaut, l'interface docker0 est créée avec l'adresse IP 172.17.0.1/16. Cela peut entrer en conflit avec l'adressage IP de votre réseau VPC, de sorte que l'instance ne peut pas se connecter à d'autres points de terminaison avec des adresses 172.17.0.1/16.

Solution

Vous pouvez forcer la création de l'interface docker0 avec une adresse IP qui n'entre pas en conflit avec votre réseau VPC en utilisant le script post-démarrage suivant et en définissant le comportement du script post-démarrage sur run_once.

#!/bin/bash
# Wait for Docker to be fully started
while ! systemctl is-active docker; do
sleep 1
done
# Stop the Docker service
systemctl stop docker
# Modify /etc/docker/daemon.json
cat < /etc/docker/daemon.json
{
"bip": "CUSTOM_DOCKER_IP/16"
}
EOF
# Restart the Docker service
systemctl start docker

Les réservations spécifiées n'existent pas

Problème

L'opération de création de l'instance génère un message d'erreur Specified reservations do not exist. Le résultat de l'opération peut ressembler à ce qui suit :

{
  "name": "projects/PROJECT/locations/LOCATION/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.notebooks.v2.OperationMetadata",
    "createTime": "2025-01-01T01:00:01.000000000Z",
    "endTime": "2025-01-01T01:00:01.000000000Z",
    "target": "projects/PROJECT/locations/LOCATION/instances/INSTANCE_NAME",
    "verb": "create",
    "requestedCancellation": false,
    "apiVersion": "v2",
    "endpoint": "CreateInstance"
  },
  "done": true,
  "error": {
    "code": 3,
    "message": "Invalid value for field 'resource.reservationAffinity': '{  \"consumeReservationType\": \"SPECIFIC_ALLOCATION\",  \"key\": \"compute.googleapis.com/reservation-name...'. Specified reservations [projects/PROJECT/zones/ZONE/futureReservations/RESERVATION_NAME] do not exist.",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "REQUEST_ID"
      }
    ]
  }
}

Solution

Certains types de machines Compute Engine nécessitent des paramètres supplémentaires lors de la création, tels que des disques SSD locaux ou une plate-forme de processeur minimale. La spécification d'instance doit inclure ces champs supplémentaires.

  • Les instances Workbench Agent Platform utilisent par défaut la configuration minimale automatique de la plate-forme du processeur. Si votre réservation définit une plate-forme spécifique, vous devez définir min_cpu_platform en conséquence lorsque vous créez des instances Workbench Agent Platform.
  • Les instances Agent Platform Workbench définissent toujours le nombre de disques SSD locaux sur les valeurs par défaut en fonction du type de machine. Par exemple, a2-ultragpu-1g dispose toujours d'un disque SSD local, tandis que a2-highgpu-1g n'en a jamais. Lorsque vous créez des réservations à utiliser pour les instances Agent Platform Workbench, vous devez laisser le SSD local à sa valeur par défaut.

Procédures utiles

Cette section décrit des procédures qui pourraient vous être utiles.

Utiliser SSH pour se connecter à votre instance Agent Platform Workbench

Utilisez ssh pour vous connecter à votre instance en saisissant la commande suivante dans Cloud Shell ou dans tout environnement dans lequel Google Cloud CLI est installé.

gcloud compute ssh --project PROJECT_ID \
  --zone ZONE \
  INSTANCE_NAME -- -L 8080:localhost:8080

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet.
  • ZONE : zone Google Cloud où se trouve votre instance.
  • INSTANCE_NAME : nom de l'instance

Vous pouvez également vous connecter à votre instance en ouvrant la page d'informations Compute Engine de votre instance, puis en cliquant sur le bouton SSH.

.

Se réenregistrer auprès du serveur de proxy d'inversion

Pour réenregistrer l'instance Agent Platform Workbench auprès du serveur de proxy d'inversion interne, vous pouvez arrêter et démarrer la VM à partir de la page Instances, ou utiliser SSH pour vous connecter à votre instance Agent Platform Workbench et saisir la commande suivante :

cd /opt/deeplearning/bin
sudo ./attempt-register-vm-on-proxy.sh

Vérifier l'état du service Docker

Pour vérifier l'état du service Docker, vous pouvez utiliser ssh pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

sudo service docker status

Vérifier que l'agent de proxy inverse est en cours d'exécution

Pour vérifier si l'agent de proxy inverse du notebook est en cours d'exécution, utilisez SSH pour vous connecter à votre instance Agent Platform Workbench, puis saisissez la commande suivante :

# Confirm Inverting Proxy agent Docker container is running (proxy-agent)
sudo docker ps

# Verify State.Status is running and State.Running is true.
sudo docker inspect proxy-agent

# Grab logs
sudo docker logs proxy-agent

Vérifier l'état du service Jupyter et collecter les journaux

Pour vérifier l'état du service Jupyter, vous pouvez utiliser SSH pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

sudo service jupyter status

Pour collecter les journaux du service Jupyter, procédez comme suit :

sudo journalctl -u jupyter.service --no-pager

Vérifier que l'API interne Jupyter est active

L'API Jupyter doit toujours s'exécuter sur le port 8080. Pour vérifier cela, inspectez les syslogs de l'instance pour trouver une entrée semblable à la suivante :

Jupyter Server ... running at:
http://localhost:8080

Pour vérifier que l'API interne Jupyter est active, vous pouvez également utiliser SSH pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

curl http://127.0.0.1:8080/api/kernelspecs

Vous pouvez également mesurer le temps nécessaire à l'API pour répondre en cas de requêtes trop longues :

time curl -V http://127.0.0.1:8080/api/status
time curl -V http://127.0.0.1:8080/api/kernels
time curl -V http://127.0.0.1:8080/api/connections

Pour exécuter ces commandes dans votre instance Agent Platform Workbench, ouvrez JupyterLab et créez un terminal.

Redémarrer le service Docker

Pour redémarrer le service Docker, vous pouvez arrêter et démarrer la VM à partir de la page Instances, ou utiliser ssh pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

sudo service docker restart

Redémarrer l'agent de proxy inverse

Pour redémarrer l'agent de proxy inverse, vous pouvez arrêter et démarrer la VM à partir de la page Instances ou utiliser ssh pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

sudo docker restart proxy-agent

Redémarrer le service Jupyter

Pour redémarrer le service Jupyter, vous pouvez arrêter et démarrer la VM à partir de la page Instances ou utiliser ssh pour vous connecter à votre instance Agent Platform Workbench, puis saisir la commande suivante :

sudo service jupyter restart

Redémarrer l'agent de collecte de notebooks

Le service d'agent de collecte de notebooks exécute un processus Python en arrière-plan qui vérifie l'état des services principaux de l'instance Agent Platform Workbench.

Pour redémarrer le service d'agent de collecte de notebooks, vous pouvez arrêter et démarrer la VM à partir de la consoleGoogle Cloud ou utiliser ssh pour vous connecter à votre instance Agent Platform Workbench, puis saisir :

sudo systemctl stop notebooks-collection-agent.service

suivi de :

sudo systemctl start notebooks-collection-agent.service

Pour exécuter ces commandes dans votre instance Agent Platform Workbench, ouvrez JupyterLab et créez un terminal.

Modifier le script de l'agent de collecte de notebooks

Pour accéder au script et le modifier, ouvrez un terminal dans notre instance ou utilisez SSH pour vous connecter à votre instance Agent Platform Workbench, puis saisissez :

nano /opt/deeplearning/bin/notebooks_collection_agent.py

N'oubliez pas d'enregistrer le fichier après l'avoir modifié.

Vous devez ensuite redémarrer le service d'agent de collecte de notebooks.

Vérifier que l'instance peut résoudre les domaines DNS requis

Pour vérifier que l'instance peut résoudre les domaines DNS requis, vous pouvez utiliser SSH pour vous connecter à votre instance Agent Platform Workbench, puis saisir :

host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com

ou :

curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?

Si Managed Service pour Apache Spark est activé sur l'instance, vous pouvez vérifier qu'elle résout *.kernels.googleusercontent.com en exécutant la commande suivante :

curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .

Pour exécuter ces commandes dans votre instance Agent Platform Workbench, ouvrez JupyterLab et créez un terminal.

Créer une copie des données utilisateur sur une instance

Pour stocker une copie des données utilisateur d'une instance dans Cloud Storage, suivez la procédure suivante.

Créer un bucket Cloud Storage (facultatif)

Dans le même projet que celui où se trouve votre instance, créez un bucket Cloud Storage dans lequel vous pouvez stocker vos données utilisateur. Si vous disposez déjà d'un bucket Cloud Storage, ignorez cette étape.

Copier vos données utilisateur

  1. Dans l'interface JupyterLab de votre instance, sélectionnez Fichier > Nouveau > Terminal pour ouvrir une fenêtre de terminal. Pour les instances Workbench Agent Platform, vous pouvez vous connecter au terminal de votre instance à l'aide de SSH.

  2. Utilisez gcloud CLI pour copier vos données utilisateur dans un bucket Cloud Storage. L'exemple de commande suivant copie tous les fichiers du répertoire /home/jupyter/ de votre instance dans un répertoire situé dans un bucket Cloud Storage.

    gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive

    Remplacez les éléments suivants :

    • BUCKET_NAME : nom du bucket Cloud Storage.
    • PATH : chemin d'accès au répertoire dans lequel vous souhaitez copier vos fichiers, par exemple : /copy/jupyter/

Examiner une instance bloquée lors du provisionnement à l'aide de gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud officiellement pris en charge. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

Ce runbook gcpdiag examine les causes potentielles pour lesquelles une instance Workbench Agent Platform peut rester bloquée dans l'état de provisionnement, y compris les domaines suivants :
  • État : vérifie l'état actuel de l'instance pour s'assurer qu'elle est bloquée au niveau du provisionnement et qu'elle n'est pas arrêtée ni active.
  • Image du disque de démarrage de la VM Compute Engine de l'instance : vérifie si l'instance a été créée avec un conteneur personnalisé, une image workbench-instances officielle, des images Deep Learning VM Image ou des images non compatibles qui pourraient empêcher l'instance de se provisionner.
  • Scripts personnalisés : vérifie si l'instance utilise des scripts de démarrage ou post-démarrage personnalisés qui modifient le port Jupyter par défaut ou rompent les dépendances qui pourraient empêcher l'instance de se provisionner.
  • Version de l'environnement : vérifie si l'instance utilise la dernière version de l'environnement en vérifiant sa possibilité de mise à niveau. Les versions antérieures peuvent entraîner un blocage de l'instance à l'état de provisionnement.
  • Performances de la VM Compute Engine de l'instance : vérifie les performances actuelles de la VM pour s'assurer qu'elle n'est pas affectée par une utilisation élevée du processeur, une mémoire insuffisante ou des problèmes d'espace disque qui pourraient perturber les opérations normales.
  • Journalisation du port série ou du système de l'instance Compute Engine : vérifie si l'instance dispose de journaux de port série, qui sont analysés pour s'assurer que Jupyter s'exécute sur le port 127.0.0.1:8080.
  • Accès SSH et terminal Compute Engine de l'instance : vérifie si la VM Compute Engine de l'instance est en cours d'exécution afin que l'utilisateur puisse utiliser SSH et ouvrir un terminal pour vérifier que l'espace utilisé dans "home/jupyter" est inférieur à 85 %. Si aucun espace n'est disponible, l'instance peut rester bloquée à l'état de provisionnement.
  • Adresse IP externe désactivée : vérifie si l'accès à l'adresse IP externe est désactivé. Une configuration réseau incorrecte peut empêcher l'instance de provisionner.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant la ressource.
  • INSTANCE_NAME : nom de l'instance Workbench Agent Platform cible dans votre projet.
  • ZONE : zone dans laquelle se trouve votre instance Workbench Agent Platform cible.

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Erreurs d'autorisation lors de l'utilisation de rôles de compte de service avec Agent Platform

Problème

Des erreurs d'autorisation générales s'affichent lorsque vous utilisez des rôles de compte de service avec Agent Platform.

Ces erreurs peuvent s'afficher dans Cloud Logging, dans les journaux des composants du produit ou dans les journaux d'audit. Elles peuvent également apparaître dans n'importe quelle combinaison des projets concernés.

Ces problèmes peuvent être dus à l'une des raisons suivantes ou aux deux :

  • Utilisation du rôle Service Account Token Creator au lieu du rôle Service Account User, ou inversement. Ces rôles accordent différentes autorisations sur un compte de service et ne sont pas interchangeables. Pour en savoir plus sur les différences entre les rôles Service Account Token Creator et Service Account User, consultez Rôles des comptes de service.

  • Vous avez accordé des autorisations à un compte de service dans plusieurs projets, ce qui n'est pas autorisé par défaut.

Solution

Pour résoudre le problème, essayez une ou plusieurs des solutions suivantes :

  • Déterminez si le rôle Service Account Token Creator ou Service Account User est nécessaire. Pour en savoir plus, consultez la documentation IAM pour les services Agent Platform que vous utilisez, ainsi que pour toute autre intégration de produit que vous utilisez.

  • Si vous avez accordé des autorisations à un compte de service dans plusieurs projets, activez l'association des comptes de service à plusieurs projets en vous assurant que iam.disableCrossProjectServiceAccountUsage. n'est pas appliquée. Pour vous assurer que iam.disableCrossProjectServiceAccountUsage n'est pas appliqué, exécutez la commande suivante :

    gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=PROJECT_ID