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 AI per la risoluzione dei problemi;

Risoluzione dei problemi con le indagini di Cloud Assist

Quando connetti Agent Platform ad altri prodotti Google Cloud , potresti trovare utili le indagini di Gemini Cloud Assist per risolvere i problemi di integrazione. Potrebbe anche accelerare la risoluzione dei problemi nell'istanza stessa. Gemini Cloud Assist ti consente di ricavare insight dalle metriche e dai 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, oltre a tutte le altre risorse in questo elenco di prodotti supportati
  • Avvia l'indagine ed esamina i risultati.

Risolvi i problemi dei file di diagnostica con Gemini CLI

Puoi utilizzare i risultati dell'indagine di Cloud Assist 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 l'applicazione, quindi descrivi il problema. Includi nel contesto l'ipotesi dell'indagine di Cloud Assist. 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 di connessione e 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 trovi la finestra del terminale in Avvio app, è possibile che l'accesso al terminale non sia abilitato per l'istanza di Agent Platform Workbench.

Soluzione

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

Errore 502 durante l'apertura di JupyterLab

Problema

Un errore 502 potrebbe indicare che l'istanza 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 di Agent Platform Workbench non esegue le 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 a eseguire le operazioni seguenti:

  • Aggiorna la pagina del browser JupyterLab. L'output delle celle non salvato non viene mantenuto, quindi devi eseguire nuovamente queste 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 OS Login 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 dei metadati su TRUE.

Soluzione

La connessione a un'istanza di Agent Platform Workbench tramite la console Google Cloud non è supportata. Se non riesci a connetterti all'istanza tramite SSH utilizzando 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 riesci a creare un'istanza di Agent Platform Workbench con GPU.

Soluzione

Determina il numero di GPU disponibili nel tuo progetto controllando la pagina delle 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 Richiedi un limite di quota più elevato.

Creazione di istanze Workbench di Agent Platform

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 in stato di provisioning

Problema

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

Could not resolve host: notebooks.googleapis.com

Se l'istanza è bloccata nello stato di provisioning, potrebbe essere perché la configurazione di rete privata dell'istanza non è valida.

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 il ruolo IAM Utente di rete Compute (roles/compute.networkUser) al service account Notebooks nel 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 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 è possibile 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 .

Ti consigliamo di aggiungere un ambiente conda anziché utilizzare 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 in Avvio app di JupyterLab e si apre correttamente, ma Gemini non risponde ai prompt.

Soluzione

Un amministratore potrebbe aver bloccato l'accesso a Gemini CLI. Consulta Controlla l'accesso a Gemini CLI.

Il pulsante Monta spazio di archiviazione condiviso non è presente

Problema

Il pulsante Monta spazio di archiviazione condiviso non è presente nella scheda Browser 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 al service account dell'istanza Agent Platform Workbench l'autorizzazione storage.buckets.list per il 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 genera 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 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 pacchetti pip non sono disponibili dopo l'aggiunta di un kernel basato su conda.

Soluzione

Per risolvere il problema, consulta 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 ai dati di un'istanza con accesso per un singolo utente o copiarli

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 specificato (il proprietario) può accedere ai dati nell'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 di Agent Platform Workbench si arresta in modo imprevisto.

Soluzione

Se l'istanza si arresta in modo imprevisto, potrebbe essere dovuto all'avvio dell'arresto per inattività.

Se hai attivato l'arresto per inattività, l'istanza viene arrestata quando non si verifica alcuna 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 notebook è un'attività che reimposta il timer del timeout di inattività. L'utilizzo della CPU non reimposta il timer del timeout di inattività.

I log dell'istanza mostrano errori di connessione o timeout

Problema

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

Soluzione

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

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

I log dell'istanza mostrano "Impossibile contattare l'API Jupyter" "ReadTimeoutError"

Problema

I log dell'istanza Workbench di Agent Platform 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 di Notebooks per cambiare HTTP_TIMEOUT_SESSION in un valore più grande, ad esempio 60, per verificare se la richiesta non è andata a buon fine perché la chiamata ha impiegato troppo tempo per rispondere o l'URL richiesto non è raggiungibile.

L'indirizzo docker0 è in conflitto 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 rete VPC, impedendo all'istanza di 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-avvio e impostando il comportamento dello script post-avvio 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 SSD locali o una piattaforma CPU minima. La specifica dell'istanza deve includere questi campi aggiuntivi.

  • Le istanze Workbench di Agent Platform utilizzano la piattaforma CPU minima automatica per impostazione predefinita. Se la prenotazione imposta una piattaforma specifica, devi impostare min_cpu_platform di conseguenza quando crei le istanze Workbench di Agent Platform.
  • 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 ha sempre 0 SSD locali. 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 potrebbero esserti utili.

Utilizza SSH per connetterti all'istanza Agent Platform Workbench

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.

user English:

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 alla tua 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 blocco note è 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 Jupyter interna sia attiva

L'API Jupyter deve essere sempre eseguita sulla porta 8080. Puoi verificarlo esaminando i syslog dell'istanza per trovare 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 per la risposta dell'API 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 Inverting Proxy, puoi arrestare e avviare la VM dalla pagina Istanze oppure puoi utilizzare SSH per connetterti all'istanza 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 di Notebooks

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 Notebooks Collection Agent, puoi arrestare e avviare la VM dalla consoleGoogle Cloud oppure puoi utilizzare SSH per connetterti alla tua 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 di Notebooks

Per accedere allo script e modificarlo, apri un terminale nella nostra istanza o utilizza SSH per connetterti all'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 Notebooks Collection Agent.

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.

Crea un bucket Cloud Storage (facoltativo)

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.

Copia i dati utente

  1. Nell'interfaccia JupyterLab dell'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 in una directory in un bucket Cloud Storage.

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

    Sostituisci quanto segue:

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

Esamina un'istanza bloccata in fase di provisioning utilizzando gcpdiag

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

Questo playbook gcpdiag esamina le potenziali cause per cui un'istanza di Agent Platform Workbench si blocca nello stato di provisioning, incluse le seguenti aree:
  • Stato: controlla lo stato attuale dell'istanza per assicurarsi che sia bloccata in fase di provisioning e non sia arrestata o attiva.
  • Immagine disco di avvio della VM Compute Engine dell'istanza: controlla 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 verificandone l'eseguibilità dell'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 utilizzo elevato della CPU, da memoria insufficiente o da problemi di spazio su disco che potrebbero interrompere le normali operazioni.
  • Porta seriale di Compute Engine o logging di sistema dell'istanza: controlla se l'istanza dispone di log della porta seriale, che vengono analizzati per garantire che Jupyter sia in esecuzione sulla porta 127.0.0.1:8080.
  • Accesso SSH e terminale di Compute Engine dell'istanza: controlla se la VM di Compute Engine dell'istanza è in esecuzione in modo che l'utente possa connettersi tramite SSH e aprire un terminale per verificare che l'utilizzo dello spazio in "home/jupyter" sia inferiore all'85%. Se non rimane spazio, l'istanza potrebbe bloccarsi nello stato di provisioning.
  • IP esterno disattivato: controlla 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 tua 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 contenente la risorsa.
  • INSTANCE_NAME: il nome dell'istanza Agent Platform Workbench di destinazione nel progetto.
  • ZONE: la zona in cui si trova l'istanza Agent Platform Workbench 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 dei account di servizio con Agent Platform

Problema

Ricevi errori di autorizzazioni generali quando utilizzi i ruoli dei account di servizio con la piattaforma dell'agente.

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 dei service account.

  • Hai concesso a un account di servizio le autorizzazioni per più progetti, cosa che non è consentita per impostazione predefinita.

Soluzione

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

  • Determina se è necessario il ruolo Service Account Token Creator o Service Account User. Per saperne di più, consulta 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 le autorizzazioni per più progetti, consenti il collegamento dei service account tra i 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