Solución de problemas de Agent Platform Workbench

En esta página, se describen los pasos para solucionar problemas que pueden servirte si tienes dificultades cuando usas Gemini Enterprise Agent Platform Workbench.

Consulta también Solución de problemas de Agent Platform para obtener ayuda sobre cómo usar otros componentes de Gemini Enterprise Agent Platform.

Para filtrar el contenido de esta página, haz clic en un tema:

Instancias de Agent Platform Workbench

En esta sección, se describen los pasos para solucionar problemas de las instancias de Agent Platform Workbench.

Solución de problemas con herramientas de IA

En esta sección, se explica cómo usar las herramientas de IA para solucionar problemas.

Soluciona problemas con las investigaciones de Cloud Assist

Cuando conectes Agent Platform con otros productos de Google Cloud , es posible que las Investigaciones de Gemini Cloud Assist te resulten útiles para solucionar problemas de integración. También puede acelerar la solución de problemas en la instancia. Gemini Cloud Assist te permite extraer estadísticas de las métricas y los registros que genera la instancia.

  • Detén la instancia y sigue el vínculo View in Compute Engine.
  • Instala el Agente de operaciones (recomendado). El proceso tardará unos minutos
  • Agrega un campo de metadatos personalizados notebook-enable-debug y configúralo como true.
  • Reinicia la instancia y reproduce el problema.
  • Habilita y configura la API de Cloud Assist Investigations.
  • Crea una investigación nueva y describe el problema en detalle con una instrucción en lenguaje natural.
  • A medida que escribes, aparece un diálogo que sugiere recursos para agregar a la investigación. Revisa esta lista y asegúrate de agregar la instancia como un recurso, así como cualquier otro recurso de esta lista de productos compatibles.
  • Inicia la investigación y revisa los resultados.

Soluciona problemas relacionados con archivos de diagnóstico con Gemini CLI

Puedes usar los resultados de la investigación de Cloud Assist para realizar más investigaciones basadas en IA en el archivo de diagnóstico de la instancia.

  • Ejecuta la herramienta de diagnóstico y especifica un bucket de Cloud Storage para subir los resultados.
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
  • Descarga el archivo de diagnóstico en tu estación de trabajo y, luego, instala y configura Gemini CLI.
  • Inicia la aplicación y, luego, describe el problema. Incluye la hipótesis de la investigación de Cloud Assist en el contexto. Pídele al modelo que extienda la investigación leyendo el contenido del archivo de diagnóstico con instrucciones en lenguaje natural.

Abre JupyterLab y conéctate a él

En esta sección, se describen los pasos para solucionar problemas relacionados con la conexión y la apertura de JupyterLab.

No sucede nada cuando hago clic en Abrir JupyterLab

Problema

Cuando haces clic en Abrir JupyterLab, no sucede nada.

Solución

Verifica que tu navegador no bloquee la apertura automática de pestañas nuevas. JupyterLab se abre en una pestaña del navegador nueva.

No puedes acceder a la terminal en una instancia de Agent Platform Workbench

Problema

Si no puedes acceder a la terminal o no puedes encontrar la ventana de la terminal en el selector, es posible que tu instancia de Agent Platform Workbench no tenga habilitado el acceso a la terminal.

Solución

Debes crear una instancia nueva de Agent Platform Workbench con la opción Acceso a la terminal habilitada. Esta opción no se puede cambiar después de crear la instancia.

Error 502 cuando se abre JupyterLab

Problema

Un error 502 puede significar que tu instancia de Agent Platform Workbench aún no está lista.

Solución

Espera unos minutos, actualiza la pestaña del navegador de la Google Cloud consola y vuelve a intentarlo.

El notebook no responde

Problema

Tu instancia de Agent Platform Workbench no ejecuta celdas o parece estar bloqueada.

Solución

Primero, intenta reiniciar el kernel. Para ello, haz clic en Kernel en el menú superior y, luego, en Reiniciar kernel. Si eso no funciona, puedes intentar lo siguiente:

  • Actualiza la página del navegador de JupyterLab. No se conservarán los resultados de celda no guardados, por lo que debes volver a ejecutar esas celdas para volver a generar el resultado.
  • Restablece tu instancia

No se puede establecer una conexión con la instancia de Agent Platform Workbench a través de SSH

Problema

No puedes conectarte a tu instancia con SSH a través de una ventana de terminal.

Las instancias de Agent Platform Workbench usan el Acceso al SO para habilitar el acceso SSH. Cuando creas una instancia, Agent Platform Workbench habilita el Acceso al SO de forma predeterminada configurando la clave de metadatos enable-oslogin en TRUE. Si no puedes usar SSH para conectarte a tu instancia, es posible que debas establecer esta clave de metadatos en TRUE.

Solución

No se admite la conexión a una instancia de Agent Platform Workbench con la Google Cloud consola. Si no puedes conectarte a tu instancia con SSH a través de una ventana de terminal, consulta lo siguiente:

Para configurar la clave de metadatos enable-oslogin en TRUE, usa el método projects.locations.instances.patch en la API de Notebooks o el comando gcloud workbench instances update en el SDK de Agent Platform.

Se superó la cuota de GPU

Problema

No puedes crear una instancia de Agent Platform Workbench con GPUs.

Solución

Determina la cantidad de GPU disponibles en el proyecto. Para hacerlo, verifica la página de cuotas. Si las GPUs no están enumeradas en la página de cuotas o si necesitas obtener más cuota de GPU, puedes solicitar un aumento de cuota para las GPUs de Compute Engine. Consulta Solicita un límite de cuota más alto.

Crea instancias de Agent Platform Workbench

En esta sección, se describe cómo solucionar problemas relacionados con la creación de instancias de Agent Platform Workbench.

La instancia permanece en estado pendiente de forma indefinida o está atascada en el estado de aprovisionamiento

Problema

Después de crear una instancia de Agent Platform Workbench, permanece en estado pendiente de forma indefinida. Puede aparecer un error como el siguiente en los registros en serie:

Could not resolve host: notebooks.googleapis.com

Si tu instancia está atascada en el estado de aprovisionamiento, es posible que tengas una configuración de red privada no válida para ella.

Solución

Sigue los pasos que se indican en la sección Los registros de la instancia muestran errores de conexión o de tiempo de espera.

No se puede crear una instancia dentro de una red de VPC compartida

Problema

Si intentas crear una instancia dentro de una red de VPC compartida, se mostrará un mensaje de error como el siguiente:

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

Solución

El problema es que la cuenta de servicio de Notebooks intenta crear la instancia sin los permisos correctos.

Para asegurarte de que la cuenta de servicio de Notebooks tenga los permisos necesarios para crear una instancia de Agent Platform Workbench en una red de VPC compartida, pídele a tu administrador que le otorgue el rol de IAM de usuario de red de Compute (roles/compute.networkUser) a la cuenta de servicio de Notebooks en el proyecto host.

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene los permisos necesarios para garantizar que la cuenta de servicio de Notebooks pueda crear una instancia de Agent Platform Workbench dentro de una red de VPC compartida. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

Se requieren los siguientes permisos para garantizar que la cuenta de servicio de Notebooks pueda crear una instancia de Agent Platform Workbench dentro de una red de VPC compartida:

  • Para usar subredes, haz lo siguiente: compute.subnetworks.use

Es posible que tu administrador también pueda otorgar estos permisos a la cuenta de servicio de Notebooks con roles personalizados o con otros roles predefinidos.

No se puede crear una instancia de Agent Platform Workbench con un contenedor personalizado

Problema

No hay una opción para usar un contenedor personalizado cuando se crea una instancia de Agent Platform Workbench en la consola de Google Cloud .

Solución

No se admite agregar un contenedor personalizado a una instancia de Agent Platform Workbench y no puedes agregar un contenedor personalizado con la Google Cloud consola.

Se recomienda agregar un entorno conda en lugar de usar un contenedor personalizado.

Puedes agregar un contenedor personalizado a una instancia de Agent Platform Workbench con la API de Notebooks, pero esta función no es compatible.

No se puede usar la CLI de Gemini

Problema

La tarjeta de Gemini CLI se encuentra en el selector de JupyterLab y se abre correctamente, pero Gemini no responde a las instrucciones.

Solución

Es posible que un administrador haya bloqueado el acceso a Gemini CLI. Consulta Cómo controlar el acceso a Gemini CLI.

No aparece el botón para activar el almacenamiento compartido

Problema

El botón Activar almacenamiento compartido no se encuentra en la pestaña Navegador de archivos de la interfaz de JupyterLab.

Solución

El permiso storage.buckets.list es obligatorio para que el botón Activar almacenamiento compartido aparezca en la interfaz de JupyterLab de tu instancia de Agent Platform Workbench. Pídele al administrador que le otorgue a la cuenta de servicio de la instancia de Agent Platform Workbench el permiso storage.buckets.list en el proyecto.

Error 599 cuando se usa Managed Service para Apache Spark

Problema

Si intentas crear una instancia habilitada para Managed Service para Apache Spark, se mostrará un mensaje de error como el siguiente:

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.)

Solución

En tu configuración de Cloud DNS, agrega una entrada de Cloud DNS para el dominio *.googleusercontent.com.

No se pudo instalar la extensión de JupyterLab de terceros

Problema

Si intentas instalar una extensión de JupyterLab de terceros, se mostrará un mensaje Error: 500.

Solución

Las extensiones de JupyterLab de terceros no son compatibles con instancias de Agent Platform Workbench.

No se puede editar la máquina virtual subyacente

Problema

Cuando intentas editar la máquina virtual (VM) subyacente de una instancia de Agent Platform Workbench, es posible que recibas un mensaje de error similar al siguiente:

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

Solución

Este error se produce porque no puedes editar la VM subyacente de una instancia con la consola de Google Cloud o la API de Compute Engine.

Para editar la VM subyacente de una instancia de Agent Platform Workbench, usa el método projects.locations.instances.patch en la API de Notebooks o el comando gcloud workbench instances update en el SDK de Agent Platform.

Los paquetes pip no están disponibles después de agregar el entorno de conda

Problema

Tus paquetes pip no estarán disponibles después de agregar un kernel basado en conda.

Solución

Para resolver el problema, consulta Agrega un entorno conda y prueba lo siguiente:

  • Verifica que hayas usado la variable DL_ANACONDA_ENV_HOME y que contenga el nombre de tu entorno.

  • Verifica que pip se encuentre en una ruta similar a opt/conda/envs/ENVIRONMENT/bin/pip. Puedes ejecutar el comando which pip para obtener la ruta de acceso.

No se puede acceder ni copiar datos de una instancia con acceso de usuario único

Problema

No se puede acceder a los datos de una instancia con acceso de usuario único.

Para las instancias de Agent Platform Workbench que están configuradas con acceso de usuario único, solo el usuario especificado (el propietario) puede acceder a los datos en la instancia.

Solución

Para acceder a los datos o copiarlos cuando no eres el propietario de la instancia, abre un caso de asistencia.

Cierre inesperado

Problema

Tu instancia de Agent Platform Workbench se apaga de forma inesperada.

Solución

Si tu instancia se cierra de forma inesperada, es posible que se haya iniciado el cierre por inactividad.

Si habilitaste el cierre inactivo, la instancia se cerrará cuando no haya actividad del kernel durante el período especificado. Por ejemplo, ejecutar una celda o una nueva impresión de resultado en un notebook es una actividad que restablece el temporizador de tiempo de espera por inactividad. El uso de CPU no restablece el temporizador de tiempo de espera de inactividad.

Los registros de instancias muestran errores de conexión o de tiempo de espera

Problema

Los registros de tu instancia de Agent Platform Workbench muestran errores de conexión o de tiempo de espera.

Solución

Si observas errores de conexión o de tiempo de espera en los registros de la instancia, asegúrate de que el servidor de Jupyter se esté ejecutando en el puerto 8080. Sigue los pasos que se indican en la sección para verificar que la API interna de Jupyter esté activa.

Si desactivaste External IP y usas una red de VPC privada, asegúrate de haber seguido también la documentación sobre las opciones de configuración de red. Ten en cuenta lo siguiente:

Los registros de la instancia muestran el error "No se pudo establecer contacto con la API de Jupyter" "ReadTimeoutError"

Problema

En los registros de tu instancia de Agent Platform Workbench, se muestra un error como el siguiente:

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

Solución

Sigue los pasos que se indican en la sección Los registros de la instancia muestran errores de conexión o de tiempo de espera. También puedes intentar modificar la secuencia de comandos del agente de recopilación de Notebooks para cambiar HTTP_TIMEOUT_SESSION a un valor mayor, por ejemplo, 60, y verificar si la solicitud falló porque la llamada tardó demasiado en responder o no se puede acceder a la URL solicitada.

La dirección docker0 entra en conflicto con la dirección de la VPC

Problema

De forma predeterminada, la interfaz docker0 se crea con una dirección IP de 172.17.0.1/16. Esto podría entrar en conflicto con el direccionamiento IP de tu red de VPC, de modo que la instancia no pueda conectarse a otros extremos con direcciones 172.17.0.1/16.

Solución

Puedes forzar la creación de la interfaz docker0 con una dirección IP que no entre en conflicto con tu red de VPC usando la siguiente secuencia de comandos posterior al inicio y configurando el comportamiento de la secuencia de comandos posterior al inicio en 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

No existen las reservas especificadas

Problema

La operación para crear la instancia genera un mensaje de error Specified reservations do not exist. El resultado de la operación podría ser similar al siguiente:

{
  "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"
      }
    ]
  }
}

Solución

Algunos tipos de máquinas de Compute Engine requieren parámetros adicionales en el momento de la creación, como SSD locales o una plataforma de CPU mínima. La especificación de la instancia debe incluir estos campos adicionales.

  • De forma predeterminada, las instancias de Agent Platform Workbench usan la plataforma de CPU mínima automática. Si tu reserva establece una plataforma específica, debes configurar min_cpu_platform según corresponda cuando crees instancias de Agent Platform Workbench.
  • Las instancias de Agent Platform Workbench siempre establecen la cantidad de SSD locales en los valores predeterminados según el tipo de máquina. Por ejemplo, a2-ultragpu-1g siempre tiene 1 SSD local, mientras que a2-highgpu-1g siempre tiene 0. Cuando crees reservas para usarlas en instancias de Agent Platform Workbench, debes dejar el SSD local en su valor predeterminado.

Procedimientos útiles

En esta sección, se describen los procedimientos que pueden resultarte útiles.

Usa SSH para conectarte a tu instancia de Agent Platform Workbench

Usa ssh a fin de conectarte a tu instancia heredada; para ello, escribe el siguiente comando en Cloud Shell o en cualquier entorno en el que esté instalada la Google Cloud CLI.

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

Reemplaza lo siguiente:

  • PROJECT_ID: el ID de tu proyecto
  • ZONE: La zona Google Cloud en la que se encuentra tu instancia
  • INSTANCE_NAME: el nombre de tu instancia.

También puedes conectarte a tu instancia si abres su página de detalles de Compute Engine y, luego, haces clic en el botón SSH.

Vuelve a registrarte con el servidor proxy de inversión.

Para volver a registrar la instancia de Agent Platform Workbench con el servidor de proxy de inversión interno, puedes detener y volver a iniciar la VM desde la página Instancias o puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

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

Verifica el estado del servicio de Docker

Si deseas verificar el estado del servicio de Docker, puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo service docker status

Verifica que el agente de proxy de inversión esté en ejecución

Para verificar si se está ejecutando el agente de proxy de inversión de notebook, usa SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresa lo siguiente:

# 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

Verifica el estado del servicio de Jupyter y recopila registros

Para verificar el estado del servicio de Jupyter, puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo service jupyter status

Para recopilar registros del servicio de Jupyter, ingresa lo siguiente:

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

Verifica que la API interna de Jupyter esté activa

La API de Jupyter siempre debe ejecutarse en el puerto 8080. Para verificarlo, inspecciona los registros del sistema de la instancia en busca de una entrada similar a la siguiente:

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

Para verificar que la API interna de Jupyter esté activa, también puedes usar ssh para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

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

También puedes medir el tiempo que tarda la API en responder en caso de que las solicitudes tarden demasiado:

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

Para ejecutar estos comandos en tu instancia de Agent Platform Workbench, abre JupyterLab y crea una terminal nueva.

Reinicia el servicio de Docker

Para reiniciar el servicio de Docker, puedes detener y volver a iniciar la VM en la página Instancias o puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo service docker restart

Reinicia el agente del proxy de inversión

Para reiniciar el agente de proxy de inversión, puedes detener y volver a iniciar la VM en la página Instancias o puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo docker restart proxy-agent

Reinicia el servicio de Jupyter

Para reiniciar el servicio de Jupyter, puedes detener y volver a iniciar la VM en la página Instancias o puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo service jupyter restart

Reinicia el agente de recopilación de Notebooks

El servicio Notebooks Collection Agent ejecuta un proceso de Python en segundo plano que verifica el estado de los servicios principales de la instancia de Agent Platform Workbench.

Para reiniciar el servicio del agente de recopilación de notebooks, puedes detener y volver a iniciar la VM desde la consola deGoogle Cloud o puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

sudo systemctl stop notebooks-collection-agent.service

seguido de:

sudo systemctl start notebooks-collection-agent.service

Para ejecutar estos comandos en tu instancia de Agent Platform Workbench, abre JupyterLab y crea una terminal nueva.

Modifica la secuencia de comandos del agente de recopilación de Notebooks

Para acceder al guion y editarlo, abre una terminal en nuestra instancia o usa SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresa lo siguiente:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Después de editar el archivo, recuerda guardarlo.

Luego, debes reiniciar el servicio del agente de recopilación de Notebooks.

Verifica que la instancia pueda resolver los dominios DNS requeridos

Para verificar que la instancia pueda resolver los dominios de DNS requeridos, puedes usar SSH para conectarte a tu instancia de Agent Platform Workbench y, luego, ingresar lo siguiente:

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

o:

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

Si la instancia tiene habilitado Managed Service para Apache Spark, puedes verificar que la instancia resuelva *.kernels.googleusercontent.com ejecutando el siguiente comando:

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

Para ejecutar estos comandos en tu instancia de Agent Platform Workbench, abre JupyterLab y crea una terminal nueva.

Realiza una copia de los datos del usuario en una instancia

Para almacenar una copia de los datos del usuario de la instancia en Cloud Storage, completa los siguientes pasos.

Crea un bucket de Cloud Storage (opcional)

En el mismo proyecto en el que se encuentra la instancia, crea un bucket de Cloud Storage en el que puedas almacenar tus datos del usuario. Si ya tienes un bucket de Cloud Storage, omite este paso.

  • Crea un bucket de Cloud Storage: 
    gcloud storage buckets create gs://BUCKET_NAME
     Reemplaza BUCKET_NAME por un nombre de bucket que cumpla con los requisitos de nombres de buckets.

Copia los datos del usuario

  1. En la interfaz de JupyterLab de tu instancia, selecciona Archivo > Nuevo > Terminal para abrir una ventana de la terminal. En el caso de las instancias de Agent Platform Workbench, puedes conectarte a la terminal de tu instancia mediante SSH.

  2. Usa gcloud CLI para copiar tus datos del usuario en un bucket de Cloud Storage. Con el siguiente comando de ejemplo, se copian todos los archivos del directorio /home/jupyter/ de la instancia a un directorio en un bucket de Cloud Storage.

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

    Reemplaza lo siguiente:

    • BUCKET_NAME: el nombre de tu bucket de Cloud Storage.
    • PATH: La ruta de acceso al directorio en el que deseas copiar los archivos, por ejemplo: /copy/jupyter/.

Investiga una instancia atascada en el aprovisionamiento con gcpdiag

gcpdiag es una herramienta de código abierto. No es un producto Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir Google Cloudproblemas del proyecto. Para obtener más información, consulta el proyecto en GitHub.

En este runbook de gcpdiag, se investigan las posibles causas por las que una instancia de Agent Platform Workbench se queda atascada en el estado de aprovisionamiento, incluidas las siguientes áreas:
  • Estado: Verifica el estado actual de la instancia para garantizar que esté atascada en el aprovisionamiento y no detenida ni activa.
  • Imagen del disco de arranque de la VM de Compute Engine de la instancia: Verifica si la instancia se creó con un contenedor personalizado, una imagen oficial de workbench-instances, imágenes de VM de aprendizaje profundo o imágenes no compatibles que podrían hacer que la instancia se quede atascada en el estado de aprovisionamiento.
  • Secuencias de comandos personalizadas: Verifica si la instancia usa secuencias de comandos de inicio o posteriores al inicio personalizadas que cambian el puerto predeterminado de Jupyter o interrumpen dependencias que podrían hacer que la instancia se quede atascada en el estado de aprovisionamiento.
  • Versión del entorno: Verifica si la instancia usa la versión más reciente del entorno comprobando si se puede actualizar. Las versiones anteriores pueden hacer que la instancia se quede atascada en el estado de aprovisionamiento.
  • Rendimiento de la VM de Compute Engine de la instancia: Verifica el rendimiento actual de la VM para garantizar que no se vea afectado por un uso elevado de la CPU, memoria insuficiente o problemas de espacio en disco que puedan interrumpir las operaciones normales.
  • Registro del sistema o del puerto en serie de Compute Engine de la instancia: Verifica si la instancia tiene registros del puerto en serie, que se analizan para garantizar que Jupyter se ejecute en el puerto 127.0.0.1:8080.
  • Acceso a la terminal y a SSH de Compute Engine de la instancia: Verifica si la VM de Compute Engine de la instancia se está ejecutando para que el usuario pueda acceder a ella a través de SSH y abrir una terminal para verificar que el uso del espacio en "home/jupyter" sea inferior al 85%. Si no queda espacio, es posible que la instancia se quede atascada en el estado de aprovisionamiento.
  • IP externa desactivada: Verifica si el acceso a la IP externa está desactivado. Una configuración de red incorrecta puede hacer que la instancia se quede atascada en el estado de aprovisionamiento.

Docker

Puedes ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.

  1. Copia y ejecuta el siguiente comando en tu estación de trabajo local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Ejecuta el comando gcpdiag. 
    ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Consulta los parámetros disponibles para este runbook.

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto que contiene el recurso.
  • INSTANCE_NAME: Es el nombre de la instancia de Agent Platform Workbench de destino dentro de tu proyecto.
  • ZONE: Es la zona en la que se encuentra la instancia de Agent Platform Workbench de destino.

Marcas útiles:

Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.

Errores de permisos cuando se usan roles de cuentas de servicio con Agent Platform

Problema

Recibes errores generales de permisos cuando usas roles de cuentas de servicio con Agent Platform.

Estos errores pueden aparecer en Cloud Logging, ya sea en los registros de componentes del producto o en los registros de auditoría. También pueden aparecer en cualquier combinación de los proyectos afectados.

Estos problemas pueden deberse a uno o ambos de los siguientes motivos:

  • Se usa el rol Service Account Token Creator cuando se debería haber usado el rol Service Account User, o viceversa. Estos roles otorgan diferentes permisos en una cuenta de servicio y no son intercambiables. Para obtener información sobre las diferencias entre los roles de Service Account Token Creator y Service Account User, consulta Roles de cuentas de servicio.

  • Otorgaste permisos a una cuenta de servicio en varios proyectos, lo que no se permite de forma predeterminada.

Solución

Para resolver el problema, prueba una o más de las siguientes opciones:

  • Determina si se necesita el rol de Service Account Token Creator o Service Account User. Para obtener más información, lee la documentación de IAM para los servicios de Agent Platform que usas, así como cualquier otra integración de productos que utilices.

  • Si otorgaste permisos a una cuenta de servicio en varios proyectos, habilita las cuentas de servicio para que se puedan adjuntar en todos los proyectos. Para ello, asegúrate de que iam.disableCrossProjectServiceAccountUsage. no se aplica de manera forzosa. Para asegurarte de que iam.disableCrossProjectServiceAccountUsage no se aplique, ejecuta el siguiente comando:

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