Risoluzione dei problemi di Agent Platform Workbench

Questa pagina descrive i passaggi per la risoluzione dei problemi, utili in caso di problemi nell'utilizzo di Gemini Enterprise Agent Platform Workbench.

Consulta anche Risoluzione dei problemi di Agent Platform per assistenza sull'utilizzo di altri componenti di Gemini Enterprise Agent Platform.

Per filtrare i contenuti di questa pagina, fai clic su un argomento:

Istanze Workbench di Agent Platform

Questa sezione descrive i passaggi per la risoluzione dei problemi relativi alle istanze di Agent Platform Workbench.

Risoluzione dei problemi con gli strumenti AI

Questa sezione illustra come utilizzare gli strumenti di AI per la risoluzione dei problemi.

Risoluzione dei problemi con le indagini di Cloud Assist

Quando connetti Agent Platform ad altri Google Cloud prodotti, potresti trovare indagini di Gemini Cloud Assist utili per risolvere i problemi di integrazione. Potrebbe anche accelerare la risoluzione dei problemi sull'istanza stessa. Gemini Cloud Assist ti consente di estrarre insight da metriche e log generati dall'istanza.

  • Arresta l'istanza e segui il link View in Compute Engine.
  • Installa Ops Agent (consigliato). L'operazione richiederà alcuni minuti
  • Aggiungi un campo Metadati personalizzati notebook-enable-debug e impostalo su true
  • Riavvia l'istanza e riproduci il problema.
  • Abilita e configura l'API Cloud Assist Investigations.
  • Crea una nuova indagine e descrivi il problema in dettaglio utilizzando un prompt in linguaggio naturale.
  • Mentre digiti, viene visualizzata una finestra di dialogo che suggerisce le risorse da aggiungere all'indagine. Esamina questo elenco e assicurati di aggiungere l'istanza come risorsa, nonché qualsiasi altra risorsa in questo elenco di prodotti supportati.
  • Inizia l'indagine e rivedi i risultati.

Risolvere i problemi relativi ai file di diagnostica con Gemini CLI

Puoi utilizzare i risultati dell'indagine di Cloud Assistance per informare ulteriori indagini basate sull'AI sul file di diagnostica dell'istanza.

  • Esegui lo strumento di diagnostica e specifica un bucket Cloud Storage in cui caricare i risultati.
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
  • Scarica il file di diagnostica sulla tua workstation, quindi installa e configura Gemini CLI.
  • Avvia la richiesta, quindi descrivi il problema. Includi l'ipotesi dell'indagine di Cloud Assist nel contesto. Chiedi al modello di estendere l'indagine leggendo i contenuti del file di diagnostica utilizzando prompt in linguaggio naturale.

Connessione e apertura di JupyterLab

Questa sezione descrive i passaggi per la risoluzione dei problemi relativi alla connessione e all'apertura di JupyterLab.

Non succede nulla dopo aver fatto clic su Apri JupyterLab

Problema

Quando fai clic su Apri JupyterLab, non succede nulla.

Soluzione

Verifica che il browser non blocchi l'apertura automatica di nuove schede. JupyterLab si apre in una nuova scheda del browser.

Impossibile accedere al terminale in un'istanza di Agent Platform Workbench

Problema

Se non riesci ad accedere al terminale o non riesci a trovare la finestra del terminale nel launcher, è possibile che l'accesso al terminale non sia abilitato nell'istanza di Agent Platform Workbench.

Soluzione

Devi creare una nuova istanza di Agent Platform Workbench con l'opzione Accesso al terminale attivata. Questa opzione non può essere modificata dopo la creazione dell'istanza.

Errore 502 all'apertura di JupyterLab

Problema

Un errore 502 potrebbe significare che la tua istanza di Agent Platform Workbench non è ancora pronta.

Soluzione

Attendi qualche minuto, aggiorna la scheda del browser della console Google Cloud e riprova.

Il notebook non risponde

Problema

L'istanza Workbench di Agent Platform non esegue celle o sembra essere bloccata.

Soluzione

Per prima cosa, prova a riavviare il kernel facendo clic su Kernel nel menu in alto e poi su Riavvia kernel. Se non funziona, puoi provare quanto segue:

  • Aggiorna la pagina del browser JupyterLab. L'output delle celle non salvate non viene mantenuto, quindi devi eseguire nuovamente le celle per rigenerare l'output.
  • Reimposta l'istanza.

Impossibile connettersi all'istanza Workbench di Agent Platform tramite SSH

Problema

Non riesci a connetterti all'istanza utilizzando SSH tramite una finestra del terminale.

Le istanze di Agent Platform Workbench utilizzano l'accesso del sistema operativo per attivare l'accesso SSH. Quando crei un'istanza, Agent Platform Workbench attiva OS Login per impostazione predefinita impostando la chiave dei metadati enable-oslogin su TRUE. Se non riesci a utilizzare SSH per connetterti all'istanza, potrebbe essere necessario impostare questa chiave di metadati su TRUE.

Soluzione

La connessione a un'istanza di Agent Platform Workbench utilizzando la console Google Cloud non è supportata. Se non riesci a connetterti alla tua istanza utilizzando SSH tramite una finestra del terminale, consulta quanto segue:

Per impostare la chiave dei metadati enable-oslogin su TRUE, utilizza il metodo projects.locations.instances.patch nell'API Notebooks o il comando gcloud workbench instances update nell'SDK Agent Platform.

La quota di GPU è stata superata

Problema

Non puoi creare un'istanza di Agent Platform Workbench con GPU.

Soluzione

Determina il numero di GPU disponibili nel progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina delle quote o se hai bisogno di una quota di GPU aggiuntiva, puoi richiedere un aumento della quota per le GPU di Compute Engine. Consulta Richiedere un limite di quota superiore.

Creazione di istanze di Agent Platform Workbench

Questa sezione descrive come risolvere i problemi relativi alla creazione di istanze di Agent Platform Workbench.

L'istanza rimane in stato In attesa a tempo indeterminato o è bloccata nello stato di provisioning

Problema

Dopo aver creato un'istanza di Agent Platform Workbench, questa rimane nello stato in attesa a tempo indeterminato. Nei log seriali potrebbe essere visualizzato un errore simile al seguente:

Could not resolve host: notebooks.googleapis.com

Se la tua istanza è bloccata nello stato di provisioning, il motivo potrebbe essere una configurazione di rete privata non valida per l'istanza.

Soluzione

Segui i passaggi descritti nella sezione I log dell'istanza mostrano errori di connessione o timeout.

Impossibile creare un'istanza all'interno di una rete VPC condiviso

Problema

Il tentativo di creare un'istanza all'interno di una rete VPC condiviso genera un messaggio di errore simile al seguente:

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

Soluzione

Il problema è che il service account Notebooks sta tentando di creare l'istanza senza le autorizzazioni corrette.

Per assicurarti che il service account Notebooks disponga delle autorizzazioni necessarie per creare un'istanza di Agent Platform Workbench all'interno di una rete VPC condiviso, chiedi all'amministratore di concedere al service account Notebooks il ruolo IAM Utente di rete Compute (roles/compute.networkUser) sul progetto host.

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Questo ruolo predefinito contiene le autorizzazioni necessarie per garantire che il service account Notebooks possa creare un'istanza di Agent Platform Workbench all'interno di una rete VPC condiviso. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per garantire che il service account Notebooks possa creare un'istanza di Agent Platform Workbench all'interno di una rete VPC condiviso, sono necessarie le seguenti autorizzazioni:

  • Per utilizzare le subnet: compute.subnetworks.use

L'amministratore potrebbe anche essere in grado di concedere al service account Notebooks queste autorizzazioni tramite ruoli personalizzati o altri ruoli predefiniti.

Impossibile creare un'istanza di Agent Platform Workbench con un container personalizzato

Problema

Non è disponibile un'opzione per utilizzare un container personalizzato durante la creazione di un'istanza di Agent Platform Workbench nella console Google Cloud .

Soluzione

L'aggiunta di un container personalizzato a un'istanza di Agent Platform Workbench non è supportata e non puoi aggiungere un container personalizzato utilizzando la console Google Cloud .

L'aggiunta di un ambiente conda è consigliata anziché l'utilizzo di un container personalizzato.

Puoi aggiungere un container personalizzato a un'istanza di Agent Platform Workbench utilizzando l'API Notebooks, ma questa funzionalità non è supportata.

Impossibile utilizzare Gemini CLI

Problema

Il riquadro Gemini CLI si trova nel launcher di JupyterLab e si apre correttamente, ma Gemini non risponde ai prompt.

Soluzione

Un amministratore potrebbe aver bloccato l'accesso a Gemini CLI. Vedi Controllare l'accesso a Gemini CLI.

Il pulsante Monta archivio condiviso non è presente

Problema

Il pulsante Monta spazio di archiviazione condiviso non è presente nella scheda Esplora file dell'interfaccia di JupyterLab.

Soluzione

L'autorizzazione storage.buckets.list è necessaria per visualizzare il pulsante Monta spazio di archiviazione condiviso nell'interfaccia JupyterLab dell'istanza Agent Platform Workbench. Chiedi all'amministratore di concedere all'account di servizio dell'istanza di Agent Platform Workbench l'autorizzazione storage.buckets.list sul progetto.

Errore 599 durante l'utilizzo di Managed Service for Apache Spark

Problema

Il tentativo di creare un'istanza abilitata per Managed Service for Apache Spark restituisce un messaggio di errore simile al seguente:

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

Soluzione

Nella configurazione di Cloud DNS, aggiungi una voce Cloud DNS per il dominio *.googleusercontent.com.

Impossibile installare l'estensione JupyterLab di terze parti

Problema

Il tentativo di installare un'estensione JupyterLab di terze parti genera un messaggio Error: 500.

Soluzione

Le estensioni JupyterLab di terze parti non sono supportate nelle istanze di Agent Platform Workbench.

Impossibile modificare la macchina virtuale sottostante

Problema

Quando provi a modificare la macchina virtuale (VM) sottostante di un'istanza di Agent Platform Workbench, potresti ricevere un messaggio di errore simile al seguente:

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

Soluzione

Questo errore si verifica perché non puoi modificare la VM sottostante di un'istanza utilizzando la console Google Cloud o l'API Compute Engine.

Per modificare la VM sottostante di un'istanza di Agent Platform Workbench, utilizza il metodo projects.locations.instances.patch nell'API Notebooks o il comando gcloud workbench instances update nell'SDK Agent Platform

I pacchetti pip non sono disponibili dopo l'aggiunta dell'ambiente conda

Problema

I tuoi pacchetti pip non sono disponibili dopo l'aggiunta di un kernel basato su conda.

Soluzione

Per risolvere il problema, vedi Aggiungi un ambiente conda e prova quanto segue:

  • Verifica di aver utilizzato la variabile DL_ANACONDA_ENV_HOME e che contenga il nome del tuo ambiente.

  • Verifica che pip si trovi in un percorso simile a opt/conda/envs/ENVIRONMENT/bin/pip. Puoi eseguire il comando which pip per ottenere il percorso.

Impossibile accedere o copiare i dati di un'istanza con accesso per un solo utente

Problema

I dati di un'istanza con accesso per un singolo utente non sono accessibili.

Per le istanze di Agent Platform Workbench configurate con accesso per un singolo utente, solo l'utente singolo specificato (il proprietario) può accedere ai dati sull'istanza.

Soluzione

Per accedere ai dati o copiarli quando non sei il proprietario dell'istanza, apri una richiesta di assistenza.

Arresto imprevisto

Problema

L'istanza Workbench di Agent Platform si spegne in modo imprevisto.

Soluzione

Se la tua istanza si arresta in modo imprevisto, il motivo potrebbe essere l'avvio dell'arresto inattivo.

Se hai attivato l'arresto inattivo, l'istanza viene arrestata quando non viene rilevata attività del kernel per il periodo di tempo specificato. Ad esempio, l'esecuzione di una cella o la stampa di un nuovo output in un blocco note è un'attività che reimposta il timer di timeout per inattività. L'utilizzo della CPU non reimposta il timer di timeout per inattività.

I log dell'istanza mostrano errori di connessione o timeout

Problema

I log dell'istanza di Agent Platform Workbench mostrano errori di connessione o timeout.

Soluzione

Se noti errori di connessione o timeout nei log dell'istanza, assicurati che il server Jupyter sia in esecuzione sulla porta 8080. Segui i passaggi descritti nella sezione Verifica che l'API interna Jupyter sia attiva.

Se hai disattivato External IP e utilizzi una rete VPC privata, assicurati di aver seguito anche la documentazione sulle opzioni di configurazione di rete. Considera quanto segue:

I log dell'istanza mostrano "Unable to contact Jupyter API" (Impossibile contattare l'API Jupyter) "ReadTimeoutError"

Problema

I log dell'istanza di Agent Platform Workbench mostrano un errore come:

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

Soluzione

Segui i passaggi descritti nella sezione I log dell'istanza mostrano errori di connessione o timeout. Puoi anche provare a modificare lo script dell'agente di raccolta dei notebook per impostare HTTP_TIMEOUT_SESSION su un valore maggiore, ad esempio 60, per verificare se la richiesta non è riuscita perché la chiamata ha impiegato troppo tempo per rispondere o l'URL richiesto non è raggiungibile.

docker0 conflitti di indirizzi con l'indirizzamento VPC

Problema

Per impostazione predefinita, l'interfaccia docker0 viene creata con un indirizzo IP 172.17.0.1/16. Ciò potrebbe entrare in conflitto con l'indirizzamento IP nella tua rete VPC, in modo che l'istanza non possa connettersi ad altri endpoint con indirizzi 172.17.0.1/16.

Soluzione

Puoi forzare la creazione dell'interfaccia docker0 con un indirizzo IP che non sia in conflitto con la tua rete VPC utilizzando il seguente script post-startup e impostando il comportamento dello script post-startup su 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

Le prenotazioni specificate non esistono

Problema

L'operazione per creare l'istanza genera un messaggio di errore Specified reservations do not exist. L'output dell'operazione potrebbe essere simile al seguente:

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

Soluzione

Alcuni tipi di macchine Compute Engine richiedono parametri aggiuntivi al momento della creazione, come gli SSD locali o una piattaforma CPU minima. La specifica dell'istanza deve includere questi campi aggiuntivi.

  • Per impostazione predefinita, le istanze di Agent Platform Workbench utilizzano la piattaforma CPU minima automatica. Se la prenotazione imposta una piattaforma specifica, devi impostare min_cpu_platform di conseguenza quando crei istanze di Agent Platform Workbench.
  • Le istanze di Agent Platform Workbench impostano sempre il numero di SSD locali sui valori predefiniti in base al tipo di macchina. Ad esempio, a2-ultragpu-1g ha sempre 1 SSD locale, mentre a2-highgpu-1g ne ha sempre 0. Quando crei prenotazioni da utilizzare per le istanze di Agent Platform Workbench, devi lasciare l'SSD locale al valore predefinito.

Procedure utili

Questa sezione descrive le procedure che potresti trovare utili.

Utilizza SSH per connetterti all'istanza Workbench di Agent Platform

Utilizza SSH per connetterti all'istanza digitando il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installata Google Cloud CLI.

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

Sostituisci quanto segue:

  • PROJECT_ID: il tuo ID progetto
  • ZONE: La zona Google Cloud in cui si trova l'istanza
  • INSTANCE_NAME: Il nome dell'istanza

Puoi anche connetterti all'istanza aprendo la pagina dei dettagli di Compute Engine dell'istanza e facendo clic sul pulsante SSH.

Esegui nuovamente la registrazione con il server Inverting Proxy

Per registrare nuovamente l'istanza Agent Platform Workbench con il server Inverting Proxy interno, puoi arrestare e avviare la VM dalla pagina Istanze oppure puoi utilizzare SSH per connetterti all'istanza Agent Platform Workbench e inserire:

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

Verifica lo stato del servizio Docker

Per verificare lo stato del servizio Docker, puoi utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

sudo service docker status

Verifica che l'agente Inverting Proxy sia in esecuzione

Per verificare se l'agente Inverting Proxy del notebook è in esecuzione, utilizza SSH per connetterti all'istanza di Agent Platform Workbench e inserisci:

# 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 lo stato del servizio Jupyter e raccogli i log

Per verificare lo stato del servizio Jupyter, puoi utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

sudo service jupyter status

Per raccogliere i log del servizio Jupyter:

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

Verifica che l'API interna Jupyter sia attiva

L'API Jupyter deve essere sempre eseguita sulla porta 8080. Puoi verificarlo controllando i syslog dell'istanza per una voce simile a:

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

Per verificare che l'API Jupyter interna sia attiva, puoi anche utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

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

Puoi anche misurare il tempo necessario all'API per rispondere nel caso in cui le richieste richiedano troppo tempo:

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

Per eseguire questi comandi nell'istanza di Agent Platform Workbench, apri JupyterLab e crea un nuovo terminale.

Riavvia il servizio Docker

Per riavviare il servizio Docker, puoi arrestare e avviare la VM dalla pagina Istanze oppure puoi utilizzare SSH per connetterti all'istanza Agent Platform Workbench e inserire:

sudo service docker restart

Riavvia l'agente Inverting Proxy

Per riavviare l'agente proxy inverso, puoi arrestare e avviare la VM dalla pagina Istanze oppure puoi utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

sudo docker restart proxy-agent

Riavvia il servizio Jupyter

Per riavviare il servizio Jupyter, puoi arrestare e avviare la VM dalla pagina Istanze oppure puoi utilizzare SSH per connetterti all'istanza Agent Platform Workbench e inserire:

sudo service jupyter restart

Riavvia l'agente di raccolta dei notebook

Il servizio Notebooks Collection Agent esegue un processo Python in background che verifica lo stato dei servizi principali dell'istanza di Agent Platform Workbench.

Per riavviare il servizio dell'agente di raccolta dei notebook, puoi arrestare e avviare la VM dalla consoleGoogle Cloud oppure puoi utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

sudo systemctl stop notebooks-collection-agent.service

seguito da:

sudo systemctl start notebooks-collection-agent.service

Per eseguire questi comandi nell'istanza di Agent Platform Workbench, apri JupyterLab e crea un nuovo terminale.

Modifica lo script dell'agente di raccolta dei notebook

Per accedere allo script e modificarlo, apri un terminale nella nostra istanza o utilizza SSH per connetterti alla tua istanza di Agent Platform Workbench e inserisci:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Dopo aver modificato il file, ricordati di salvarlo.

Poi devi riavviare il servizio dell'agente di raccolta dei blocchi note.

Verifica che l'istanza possa risolvere i domini DNS richiesti

Per verificare che l'istanza possa risolvere i domini DNS richiesti, puoi utilizzare SSH per connetterti all'istanza di Agent Platform Workbench e inserire:

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

oppure:

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

Se l'istanza ha Managed Service for Apache Spark abilitato, puoi verificare che l'istanza risolva *.kernels.googleusercontent.com eseguendo:

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

Per eseguire questi comandi nell'istanza di Agent Platform Workbench, apri JupyterLab e crea un nuovo terminale.

Crea una copia dei dati utente su un'istanza

Per archiviare una copia dei dati utente di un'istanza in Cloud Storage, completa i seguenti passaggi.

(Facoltativo) Crea un bucket Cloud Storage

Nello stesso progetto in cui si trova l'istanza, crea un bucket Cloud Storage in cui archiviare i dati utente. Se hai già un bucket Cloud Storage, salta questo passaggio.

Copiare i dati utente

  1. Nell'interfaccia JupyterLab della tua istanza, seleziona File > Nuovo > Terminale per aprire una finestra del terminale. Per le istanze di Agent Platform Workbench, puoi invece connetterti al terminale dell'istanza utilizzando SSH.

  2. Utilizza gcloud CLI per copiare i dati utente in un bucket Cloud Storage. Il seguente comando di esempio copia tutti i file dalla directory /home/jupyter/ dell'istanza a una directory in un bucket Cloud Storage.

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

    Sostituisci quanto segue:

    • BUCKET_NAME: il nome del bucket Cloud Storage
    • PATH: il percorso della directory in cui vuoi copiare i file, ad esempio: /copy/jupyter/

Analizza un'istanza bloccata nel provisioning utilizzando gcpdiag

Google Cloud

gcpdiag è uno strumento open source. Non è un prodotto Google Cloud supportato ufficialmente. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere Google Cloud i problemi del progetto. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

Questo runbook gcpdiag esamina le potenziali cause per cui un'istanza di Agent Platform Workbench si blocca nello stato di provisioning, tra cui le seguenti aree:
  • Stato: controlla lo stato attuale dell'istanza per assicurarsi che sia bloccata nel provisioning e non arrestata o attiva.
  • Immagine disco di avvio della VM di Compute Engine dell'istanza: Verifica se l'istanza è stata creata con un container personalizzato, un'immagine workbench-instances ufficiale, Deep Learning VM Images o immagini non supportate che potrebbero causare il blocco dell'istanza nello stato di provisioning.
  • Script personalizzati: controlla se l'istanza utilizza script di avvio o post-avvio personalizzati che modificano la porta Jupyter predefinita o interrompono le dipendenze che potrebbero causare il blocco dell'istanza nello stato di provisioning.
  • Versione dell'ambiente: controlla se l'istanza utilizza l'ultima versione dell'ambiente verificando la sua possibilità di upgrade. Le versioni precedenti potrebbero causare il blocco dell'istanza nello stato di provisioning.
  • Prestazioni della VM Compute Engine dell'istanza: Controlla le prestazioni attuali della VM per assicurarsi che non siano compromesse da un elevato utilizzo della CPU, memoria insufficiente o problemi di spazio su disco che potrebbero interrompere le normali operazioni.
  • Porta seriale Compute Engine o registrazione di sistema dell'istanza: controlla se l'istanza ha log della porta seriale, che vengono analizzati per assicurarsi che Jupyter sia in esecuzione sulla porta 127.0.0.1:8080.
  • Accesso SSH e al terminale di Compute Engine dell'istanza: verifica se la VM Compute Engine dell'istanza è in esecuzione in modo che l'utente possa utilizzare SSH e aprire un terminale per verificare che l'utilizzo dello spazio in "home/jupyter" sia inferiore all'85%. Se non è rimasto spazio, l'istanza potrebbe bloccarsi nello stato di provisioning.
  • IP esterno disattivato: verifica se l'accesso all'IP esterno è disattivato. Una configurazione di rete errata può causare il blocco dell'istanza nello stato di provisioning.

Docker

Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. Docker o Podman devono essere installati.

  1. Copia ed esegui il seguente comando sulla workstation locale. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Esegui il comando gcpdiag. 
    ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Visualizza i parametri disponibili per questo runbook.

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto che contiene la risorsa.
  • INSTANCE_NAME: il nome dell'istanza Agent Platform Workbench di destinazione all'interno del progetto.
  • ZONE: la zona in cui si trova l'istanza Workbench di Agent Platform di destinazione.

Flag utili:

Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.

Errori di autorizzazione durante l'utilizzo dei ruoli del account di servizio con Agent Platform

Problema

Quando utilizzi i ruoli del account di servizio con Agent Platform, vengono visualizzati errori di autorizzazione generali.

Questi errori possono essere visualizzati in Cloud Logging nei log dei componenti del prodotto o negli audit log. Potrebbero anche essere visualizzati in qualsiasi combinazione dei progetti interessati.

Questi problemi possono essere causati da uno o entrambi i seguenti fattori:

  • Utilizzo del ruolo Service Account Token Creator quando avrebbe dovuto essere utilizzato il ruolo Service Account User o viceversa. Questi ruoli concedono autorizzazioni diverse su un account di servizio e non sono intercambiabili. Per scoprire le differenze tra i ruoli Service Account Token Creator e Service Account User, consulta Ruoli degli account di servizio.

  • Hai concesso a un account di servizio autorizzazioni su più progetti, il che non è consentito per impostazione predefinita.

Soluzione

Per risolvere il problema, prova una o più delle seguenti soluzioni:

  • Determina se è necessario il ruolo Service Account Token Creator o Service Account User. Per saperne di più, leggi la documentazione IAM per i servizi Agent Platform che utilizzi, nonché per qualsiasi altra integrazione di prodotto che utilizzi.

  • Se hai concesso a un account di servizio autorizzazioni in più progetti, consenti l'allegato dei service account in più progetti assicurandoti che iam.disableCrossProjectServiceAccountUsage. non è applicata in modo forzato. Per assicurarti che iam.disableCrossProjectServiceAccountUsage non venga applicato, esegui questo comando:

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