Fehlerbehebung bei Agent Platform Workbench

Auf dieser Seite werden Schritte zur Fehlerbehebung beschrieben, die bei Problemen mit der Gemini Enterprise Agent Platform Workbench hilfreich sein können.

Informationen zur Verwendung anderer Komponenten der Gemini Enterprise Agent Platform finden Sie unter Fehlerbehebung für die Agent Platform.

Klicken Sie auf ein Thema, um die Inhalte dieser Seite zu filtern:

Agent Platform-Workbench-Instanzen

In diesem Abschnitt werden Schritte zur Fehlerbehebung für Agent Platform Workbench-Instanzen beschrieben.

Fehlerbehebung mit KI-Tools

In diesem Abschnitt wird beschrieben, wie Sie KI-Tools zur Fehlerbehebung verwenden.

Fehlerbehebung mit Cloud Assist-Prüfungen

Wenn Sie die Agent Platform mit anderen Google Cloud -Produkten verbinden, können Gemini Cloud Assist-Prüfungen bei der Fehlerbehebung von Integrationsproblemen hilfreich sein. Außerdem kann die Fehlerbehebung auf der Instanz selbst beschleunigt werden. Mit Gemini Cloud Assist können Sie Statistiken aus Messwerten und Logs ableiten, die von der Instanz generiert werden.

  • Beenden Sie die Instanz und folgen Sie dem Link View in Compute Engine.
  • Installieren Sie den Ops-Agent (empfohlen). Das kann einige Minuten dauern
  • Fügen Sie das Feld Benutzerdefinierte Metadaten notebook-enable-debug hinzu und legen Sie es auf true fest.
  • Starten Sie die Instanz neu und reproduzieren Sie das Problem.
  • Aktivieren und konfigurieren Sie die Cloud Assist Investigations API.
  • Erstellen Sie eine neue Untersuchung und beschreiben Sie das Problem detailliert mit einem Prompt in natürlicher Sprache.
  • Während der Eingabe wird ein Dialogfeld angezeigt, in dem Ressourcen vorgeschlagen werden, die der Untersuchung hinzugefügt werden können. Sehen Sie sich diese Liste an und fügen Sie die Instanz als Ressource sowie alle anderen Ressourcen in dieser Liste der unterstützten Produkte hinzu.
  • Beginnen Sie mit der Untersuchung und sehen Sie sich die Ergebnisse an.

Fehlerbehebung bei Diagnosedateien mit der Gemini CLI

Sie können die Ergebnisse der Cloud Assist-Untersuchung verwenden, um weitere KI-basierte Untersuchungen der Diagnosedatei der Instanz zu starten.

  • Führen Sie das Diagnosetool aus und geben Sie einen Cloud Storage-Bucket an, in den die Ergebnisse hochgeladen werden sollen.
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
  • Laden Sie die Diagnosedatei auf Ihre Workstation herunter und installieren und konfigurieren Sie dann die Gemini CLI.
  • Starten Sie die Anwendung und beschreiben Sie dann Ihr Problem. Nehmen Sie die Hypothese aus der Cloud Assistance-Prüfung in den Kontext auf. Bitten Sie das Modell, die Untersuchung zu erweitern, indem Sie die Inhalte der Diagnosedatei mit Prompts in natürlicher Sprache lesen.

Verbindung zu JupyterLab herstellen und JupyterLab öffnen

In diesem Abschnitt werden Schritte zur Fehlerbehebung beim Herstellen einer Verbindung zu und beim Öffnen von JupyterLab beschrieben.

Nach dem Klicken auf JupyterLab passiert nichts

Problem

Wenn Sie auf JupyterLab öffnen klicken, passiert nichts.

Lösung

Prüfen Sie, ob Ihr Browser das automatische Öffnen neuer Tabs blockiert. JupyterLab wird in einem neuen Browsertab geöffnet.

Zugriff auf das Terminal in einer Agent Platform Workbench-Instanz nicht möglich

Vorgang

Wenn Sie nicht auf das Terminal zugreifen können oder das Terminalfenster im Launcher nicht gefunden wird, liegt dies möglicherweise daran, dass auf Ihrer Agent Platform Workbench-Instanz der Terminalzugriff nicht aktiviert ist.

Lösung

Sie müssen eine neue Agent Platform Workbench-Instanz mit aktivierter Option zum Terminalzugriff erstellen. Diese Option kann nach dem Erstellen der Instanz nicht mehr geändert werden.

Beim Öffnen von JupyterLab wird ein 502-Fehler angezeigt

Vorgang

Der Fehler 502 bedeutet möglicherweise, dass die Agent Platform Workbench-Instanz noch nicht bereit ist.

Lösung

Warten Sie einige Minuten, aktualisieren Sie den Browsertab der Google Cloud -Konsole und versuchen Sie es dann noch einmal.

Das Notebook reagiert nicht

Vorgang

Ihre Agent Platform Workbench-Instanz führt keine Zellen aus oder scheint eingefroren zu sein.

Lösung

Starten Sie den Kernel neu. Klicken Sie dazu im oberen Menü auf Kernel und dann auf Kernel neu starten. Wenn dies nicht funktioniert, versuchen Sie folgendes:

  • Aktualisieren Sie die JupyterLab-Browserseite. Nicht gespeicherte Zellenausgaben werden nicht beibehalten. Daher müssen Sie diese Zellen noch einmal ausführen, um die Ausgabe neu zu generieren.
  • Instanz zurücksetzen.

Verbindung zu einer Agent Platform Workbench-Instanz über SSH kann nicht hergestellt werden

Vorgang

Sie können keine Verbindung zu Ihrer Instanz über SSH über ein Terminalfenster herstellen.

Agent Platform Workbench-Instanzen verwenden OS Login, um den SSH-Zugriff zu ermöglichen. Wenn Sie eine Instanz erstellen, aktiviert Agent Platform Workbench standardmäßig OS Login, indem der Metadatenschlüssel enable-oslogin auf TRUE gesetzt wird. Wenn Sie keine SSH-Verbindung zur Instanz herstellen können, muss dieser Metadatenschlüssel möglicherweise auf TRUE gesetzt werden.

Lösung

Die Verbindung zu einer Agent Platform Workbench-Instanz über die Google Cloud Konsole wird nicht unterstützt. Wenn Sie keine Verbindung zu Ihrer Instanz über SSH über ein Terminalfenster herstellen können, beachten Sie Folgendes:

Um den Metadatenschlüssel enable-oslogin auf TRUE zu setzen, verwenden Sie die Methode projects.locations.instances.patch in der Notebooks API oder den Befehl gcloud workbench instances update im Agent Platform SDK.

Das GPU-Kontingent wurde überschritten

Vorgang

Sie können keine Agent Platform Workbench-Instanz mit GPUs erstellen.

Lösung

Prüfen Sie auf der Seite Kontingente die Anzahl der in Ihrem Projekt verfügbaren GPUs. Wenn auf der Seite „Kontingente“ keine GPUs aufgeführt sind oder Sie zusätzliche GPU-Kontingente benötigen, können Sie eine Erhöhung des Kontingents für Compute Engine-GPUs beantragen. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Agent Platform Workbench-Instanzen erstellen

In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Erstellen von Agent Platform Workbench-Instanzen beheben.

Instanz bleibt auf unbestimmte Zeit im Status „Ausstehend“ oder hängt im Bereitstellungsstatus fest

Vorgang

Nachdem Sie eine Agent Platform Workbench-Instanz erstellt haben, bleibt sie unbegrenzt im Status „Ausstehend“. In den seriellen Protokollen kann ein Fehler wie der folgende angezeigt werden:

Could not resolve host: notebooks.googleapis.com

Wenn der Bereitstellungsstatus Ihrer Instanz steckenbleibt, kann das an einer ungültigen Konfiguration für das private Netzwerk für Ihre Instanz liegen.

Lösung

Folgen Sie der Anleitung im Abschnitt In den Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt.

Instanz kann nicht in einem freigegebene VPC-Netzwerk erstellt werden

Problem

Der Versuch, eine Instanz in einem freigegebene VPC-Netzwerk zu erstellen, führt zu einer Fehlermeldung wie dieser:

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

Lösung

Das Problem besteht darin, dass das Notebooks-Dienstkonto versucht, die Instanz ohne die richtigen Berechtigungen zu erstellen.

Bitten Sie Ihren Administrator, dem Notebooks-Dienstkonto die IAM-Rolle „Compute Network User“ (roles/compute.networkUser) für das Hostprojekt zuzuweisen, damit das Notebooks-Dienstkonto die erforderlichen Berechtigungen hat, um eine Agent Platform Workbench-Instanz in einem freigegebene VPC-Netzwerk zu erstellen.

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die erforderlich sind, damit das Notebook-Dienstkonto eine Agent Platform Workbench-Instanz in einem freigegebene VPC-Netzwerk erstellen kann. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, damit das Notebooks-Dienstkonto eine Agent Platform Workbench-Instanz in einem freigegebene VPC-Netzwerk erstellen kann:

  • So verwenden Sie Subnetzwerke: compute.subnetworks.use

Ihr Administrator kann dem Notebooks-Dienstkonto möglicherweise auch diese Berechtigungen mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erteilen.

Kann keine Agent Platform Workbench-Instanz mit einem benutzerdefinierten Container erstellen

Vorgang

Beim Erstellen einer Agent Platform Workbench-Instanz in der Google Cloud Console können Sie keinen benutzerdefinierten Container verwenden.

Lösung

Das Hinzufügen eines benutzerdefinierten Containers zu einer Agent Platform Workbench-Instanz wird nicht unterstützt. Sie können einen benutzerdefinierten Container auch nicht über die Google Cloud Console hinzufügen.

Das Hinzufügen einer Conda-Umgebung statt eines benutzerdefinierten Containers wird empfohlen.

Sie können einer Agent Platform Workbench-Instanz mithilfe der Notebooks API einen benutzerdefinierten Container hinzufügen. Diese Funktion wird jedoch nicht unterstützt.

Gemini CLI kann nicht verwendet werden

Vorgang

Die Gemini CLI-Kachel befindet sich im JupyterLab-Launcher und wird erfolgreich geöffnet, aber Gemini reagiert nicht auf Prompts.

Lösung

Ein Administrator hat möglicherweise den Zugriff auf die Gemini CLI blockiert. Weitere Informationen finden Sie unter Zugriff auf die Gemini CLI steuern.

Button „Freigegebenen Speicher bereitstellen“ ist nicht vorhanden

Problem

Der Button Freigegebenen Speicher bereitstellen befindet sich nicht auf dem Tab Dateibrowser der JupyterLab-Benutzeroberfläche.

Lösung

Die Berechtigung storage.buckets.list ist erforderlich, damit der Button Freigegebenen Speicher bereitstellen in der JupyterLab-Oberfläche Ihrer Agent Platform Workbench-Instanz angezeigt wird. Bitten Sie Ihren Administrator, dem Dienstkonto Ihrer Agent Platform Workbench-Instanz die Berechtigung storage.buckets.list für das Projekt zu erteilen.

Fehler 599 bei Verwendung von Managed Service for Apache Spark

Vorgang

Wenn Sie versuchen, eine Managed Service for Apache Spark-kompatible Instanz zu erstellen, wird eine Fehlermeldung wie die folgende ausgegeben:

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

Lösung

Fügen Sie in Ihrer Cloud DNS-Konfiguration einen Cloud DNS-Eintrag für die Domain *.googleusercontent.com hinzu.

JupyterLab-Erweiterung von Drittanbietern kann nicht installiert werden

Problem

Der Versuch, eine JupyterLab-Erweiterung eines Drittanbieters zu installieren, führt zu einer Error: 500-Nachricht.

Lösung

JupyterLab-Erweiterungen von Drittanbietern werden in Agent Platform Workbench-Instanzen nicht unterstützt.

Die zugrunde liegende virtuelle Maschine kann nicht bearbeitet werden

Vorgang

Wenn Sie versuchen, die zugrunde liegende virtuelle Maschine (VM) einer Agent Platform Workbench-Instanz zu bearbeiten, erhalten Sie möglicherweise eine Fehlermeldung ähnlich der folgenden:

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

Lösung

Dieser Fehler tritt auf, weil Sie die zugrunde liegende VM einer Instanz nicht mit der Google Cloud Console oder der Compute Engine API bearbeiten können.

Verwenden Sie zum Bearbeiten der zugrunde liegenden VM einer Agent Platform Workbench-Instanz die Methode projects.locations.instances.patch in der Notebooks API oder den Befehl gcloud workbench instances update im Agent Platform SDK.

pip-Pakete sind nach dem Hinzufügen der Conda-Umgebung nicht verfügbar

Problem

Ihre pip-Pakete sind nicht mehr verfügbar, nachdem Sie einen Conda-basierten Kernel hinzugefügt haben.

Lösung

Weitere Informationen zur Behebung des Problems finden Sie unter Conda-Umgebung hinzufügen. Versuchen Sie Folgendes:

  • Prüfen Sie, ob Sie die Variable DL_ANACONDA_ENV_HOME verwendet haben und ob sie den Namen Ihrer Umgebung enthält.

  • Prüfen Sie, ob sich pip in einem Pfad befindet, der opt/conda/envs/ENVIRONMENT/bin/pip ähnelt. Sie können den Befehl which pip ausführen, um den Pfad abzurufen.

Auf eine Instanz mit Einzelnutzerzugriff kann nicht zugegriffen oder ihre Daten können nicht kopiert werden

Problem

Auf die Daten einer Instanz mit Einzelnutzerzugriff kann nicht zugegriffen werden.

Bei Agent Platform Workbench-Instanzen, die mit Einzelnutzerzugriff eingerichtet sind, kann nur der angegebene Einzelnutzer (der Inhaber) auf die Daten in der Instanz zugreifen.

Lösung

Öffnen Sie eine Supportanfrage, um auf die Daten zuzugreifen oder sie zu kopieren, wenn Sie nicht der Inhaber der Instanz sind.

Unerwartetes Herunterfahren

Vorgang

Ihre Agent Platform Workbench-Instanz wird unerwartet heruntergefahren.

Lösung

Wenn Ihre Instanz unerwartet heruntergefahren wird, könnte dies daran liegen, dass Herunterfahren bei Inaktivität initiiert wurde.

Wenn Sie das Herunterfahren bei Inaktivität aktiviert haben, wird Ihre Instanz heruntergefahren, wenn für den angegebenen Zeitraum keine Kernel-Aktivität vorhanden ist. Das Ausführen einer Zelle oder eines neuen Ausgabedrucks auf einem Notebook ist beispielsweise eine Aktivität, die den Timer für das Zeitlimit bei Inaktivität zurücksetzt. Die CPU-Nutzung setzt den Timer für das Zeitlimit bei Inaktivität nicht zurück.

In Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt

Vorgang

In den Protokollen Ihrer Agent Platform Workbench-Instanz werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt.

Lösung

Wenn Sie in den Protokollen der Instanz Verbindungs- oder Zeitüberschreitungsfehler feststellen, prüfen Sie, ob der Jupyter-Server auf Port 8080 ausgeführt wird. Folgen Sie der Anleitung im Abschnitt Prüfen, ob die interne Jupyter API aktiv ist.

Wenn Sie External IP deaktiviert haben und ein privates VPC-Netzwerk verwenden, lesen Sie auch die Dokumentation zu den Netzwerkkonfigurationsoptionen. Berücksichtigen Sie Folgendes:

In den Instanzprotokollen wird „Keine Verbindung zur Jupyter API herstellbar“ und „Zeitüberschreitung beim Lesen“ angezeigt.

Vorgang

In den Protokollen Ihrer Agent Platform Workbench-Instanz wird ein Fehler angezeigt, z. B.:

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

Lösung

Folgen Sie der Anleitung im Abschnitt In Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt. Sie können auch versuchen, das Script des Notebooks Collection Agents zu ändern, um HTTP_TIMEOUT_SESSION in einen größeren Wert zu ändern, z. B. 60. So können Sie prüfen, ob die Anfrage fehlgeschlagen ist, weil der Aufruf zu lange gebraucht hat mit dem Antworten oder die angeforderte URL nicht erreicht werden kann.

docker0-Adresse steht in Konflikt mit der VPC-Adressierung

Vorgang

Standardmäßig wird die docker0-Schnittstelle mit der IP-Adresse 172.17.0.1/16 erstellt. Dies kann zu Konflikten mit der IP-Adressierung in Ihrem VPC-Netzwerk führen, sodass die Instanz keine Verbindung zu anderen Endpunkten mit 172.17.0.1/16-Adressen herstellen kann.

Lösung

Sie können erzwingen, dass die docker0-Schnittstelle mit einer IP-Adresse erstellt wird, die nicht mit Ihrem VPC-Netzwerk in Konflikt steht. Verwenden Sie dazu das folgende Post-Startup-Skript und legen Sie das Verhalten des Post-Startup-Skripts auf run_once fest.

#!/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

Die angegebenen Reservierungen sind nicht vorhanden

Vorgang

Beim Vorgang zum Erstellen der Instanz wird die Fehlermeldung Specified reservations do not exist ausgegeben. Die Ausgabe des Vorgangs könnte etwa so aussehen:

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

Lösung

Für einige Compute Engine-Maschinentypen sind bei der Erstellung zusätzliche Parameter wie lokale SSDs oder eine Mindest-CPU-Plattform erforderlich. Die Instanzspezifikation muss diese zusätzlichen Felder enthalten.

  • Für Agent Platform Workbench-Instanzen wird standardmäßig die automatische Mindest-CPU-Plattform verwendet. Wenn in Ihrer Reservierung eine bestimmte Plattform festgelegt ist, müssen Sie min_cpu_platform beim Erstellen von Agent Platform Workbench-Instanzen entsprechend festlegen.
  • Für Agent Platform Workbench-Instanzen wird die Anzahl der lokalen SSDs immer auf die Standardwerte entsprechend dem Maschinentyp festgelegt. a2-ultragpu-1g hat beispielsweise immer eine lokale SSD, während a2-highgpu-1g immer keine lokale SSD hat. Wenn Sie Reservierungen für Agent Platform Workbench-Instanzen erstellen, müssen Sie die lokale SSD auf dem Standardwert belassen.

Nützliche Vorgehensweisen

In diesem Abschnitt werden Verfahren beschrieben, die Ihnen helfen können.

SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen

Verwenden Sie SSH, um eine Verbindung zu Ihrer Instanz herzustellen. Geben Sie dafür folgenden Befehl in Cloud Shell oder in einer Umgebung ein, in der das Google Cloud CLI installiert ist.

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

Dabei gilt:

  • PROJECT_ID: Ihre Projekt-ID
  • ZONE: Die Google Cloud Zone, in der sich Ihre Instanz befindet
  • INSTANCE_NAME: Der Name Ihrer Instanz.

Sie können auch eine Verbindung zu Ihrer Instanz herstellen, indem Sie die Compute Engine-Detailseite der Instanz öffnen und dann auf den Button SSH klicken.

Beim Inverting-Proxy-Server neu registrieren

Wenn Sie die Agent Platform Workbench-Instanz noch einmal beim internen Inverting-Proxy-Server registrieren möchten, können Sie die VM auf der Seite Instanzen anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

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

Docker-Dienststatus überprüfen

Prüfen Sie den Docker-Dienststatus, indem Sie SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo service docker status

Prüfen, ob der Backverting-Proxy-Agent ausgeführt wird

Sie können prüfen, ob der Notebook-Inverting-Proxy-Agent ausgeführt wird. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer Agent Platform Workbench-Instanz her und geben Sie Folgendes ein:

# 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

Jupyter-Dienststatus prüfen und Logs erfassen

Prüfen Sie den Jupyter-Dienststatus, indem Sie SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo service jupyter status

So erfassen Sie Jupyter-Dienstlogs:

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

Prüfen, ob die interne Jupyter API aktiv ist

Die Jupyter API sollte immer auf Port 8080 ausgeführt werden. Sie können dies prüfen, indem Sie in den Syslogs der Instanz nach einem Eintrag suchen, der in etwa so aussieht:

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

Sie können prüfen, ob die interne Jupyter API aktiv ist. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer Agent Platform Workbench-Instanz her und geben Sie Folgendes ein:

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

Sie können auch die Zeit messen, die die API für die Antwort benötigt, falls die Anfragen zu lange dauern:

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

Wenn Sie diese Befehle in Ihrer Agent Platform Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.

Starten Sie den Docker-Dienst neu

Sie können den Docker-Dienst neu starten, indem Sie die VM über die Seite Instanzen anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo service docker restart

Reverse-Proxy-Agent neu starten

Wenn Sie den Inverting-Proxy-Agent neu starten möchten, können Sie die VM über die Seite Instanzen anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo docker restart proxy-agent

Jupyter-Dienst neu starten

Sie können den Jupyter-Dienst neu starten, indem Sie die VM über die Seite Instanzen anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo service jupyter restart

Notebooks-Collection-Agent neu starten

Der Notebooks Collection Agent-Dienst führt einen Python-Prozess im Hintergrund aus, der den Status der Hauptdienste der Agent Platform Workbench-Instanz prüft.

Sie können den Dienst „Notebooks Collection Agent“ neu starten, indem Sie die VM über die Google Cloud -Konsole anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Agent Platform Workbench-Instanz herzustellen, und dann Folgendes eingeben:

sudo systemctl stop notebooks-collection-agent.service

Gefolgt von:

sudo systemctl start notebooks-collection-agent.service

Wenn Sie diese Befehle in Ihrer Agent Platform Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.

Skript für Notebooks Collection Agent ändern

Wenn Sie auf das Script zugreifen und es bearbeiten möchten, öffnen Sie ein Terminal in unserer Instanz oder verbinden Sie sich per SSH mit Ihrer Agent Platform Workbench-Instanz und geben Sie Folgendes ein:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Denken Sie daran, die Datei nach der Bearbeitung zu speichern.

Anschließend müssen Sie den Dienst „Notebooks Collection Agent“ neu starten.

Prüfen, ob die Instanz die erforderlichen DNS-Domains auflösen kann

Sie können prüfen, ob die Instanz die erforderlichen DNS-Domains auflösen kann. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer Agent Platform Workbench-Instanz her und geben Sie Folgendes ein:

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

oder:

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

Wenn für die Instanz Managed Service for Apache Spark aktiviert ist, können Sie mit dem folgenden Befehl prüfen, ob die Instanz *.kernels.googleusercontent.com auflöst:

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

Wenn Sie diese Befehle in Ihrer Agent Platform Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.

Kopie der Nutzerdaten auf einer Instanz erstellen

Führen Sie die folgenden Schritte aus, um eine Kopie der Nutzerdaten Ihrer Instanz in Cloud Storage zu speichern.

Cloud Storage-Bucket erstellen (optional)

Erstellen Sie in dem Projekt, in dem sich Ihre Instanz befindet und einen Cloud Storage-Bucket, in dem Sie Ihre Nutzerdaten speichern können. Wenn Sie bereits einen Cloud Storage-Bucket haben, überspringen Sie diesen Schritt.

  • Erstellen Sie einen Cloud Storage-Bucket: 
    gcloud storage buckets create gs://BUCKET_NAME
     Ersetzen Sie BUCKET_NAME durch einen Bucket-Namen, der den Anforderungen für Bucket-Namen entspricht.

Nutzerdaten kopieren

  1. Wählen Sie auf der JupyterLab-Benutzeroberfläche Ihrer verwalteten Notebookinstanz Datei >Neu > Terminal aus, um ein Terminalfenster zu öffnen. Bei Agent Platform Workbench-Instanzen können Sie stattdessen mit SSH eine Verbindung zum Terminal Ihrer Instanz herstellen.

  2. Verwenden Sie die gcloud CLI, um Ihre Nutzerdaten in einen Cloud Storage-Bucket zu kopieren. Mit dem folgenden Beispielbefehl werden alle Dateien aus dem Verzeichnis /home/jupyter/ Ihrer Instanz in ein Verzeichnis in einem Cloud Storage-Bucket kopiert.

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

    Ersetzen Sie dabei Folgendes:

    • BUCKET_NAME: Der Name Ihres Cloud Storage-Buckets.
    • PATH: Der Pfad zu dem Verzeichnis, in das Sie Ihre Dateien kopieren möchten, z. B. /copy/jupyter/.

Problem mit einer Instanz, die in der Bereitstellung festhängt, mit gcpdiag untersuchen

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud -Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

In diesem gcpdiag-Runbook werden mögliche Ursachen dafür untersucht, dass der Bereitstellungsstatus einer Agent Platform Workbench-Instanz nicht fortgesetzt wird. Dazu gehören die folgenden Bereiche:
  • Status: Prüft den aktuellen Status der Instanz, um sicherzustellen, dass sie in der Bereitstellung festhängt und nicht angehalten oder aktiv ist.
  • Compute Engine-VM-Bootlaufwerk-Image der Instanz: Es Wird geprüft, ob die Instanz mit einem benutzerdefinierten Container, einem offiziellen workbench-instances-Image, Deep Learning-VM-Images oder nicht unterstützten Images erstellt wurde, die dazu führen können, dass die Instanz im Bereitstellungsstatus hängen bleibt.
  • Benutzerdefinierte Scripts: Prüft, ob für die Instanz benutzerdefinierte Start- oder Post-Start-Scripts verwendet werden, die den Standard-Jupyter-Port ändern oder Abhängigkeiten aufheben, die dazu führen können, dass die Instanz im Bereitstellungsstatus hängen bleibt.
  • Umgebungsversion: Prüft, ob für die Instanz die neueste Umgebungsversion verwendet wird, indem die Möglichkeit zum Upgrade geprüft wird. Bei älteren Versionen bleibt die Instanz möglicherweise im Bereitstellungsstatus hängen.
  • Compute Engine-VM-Leistung der Instanz: Wird die aktuelle Leistung der VM geprüft, um sicherzustellen, dass sie nicht durch eine hohe CPU-Auslastung, einen unzureichenden Arbeitsspeicher oder Probleme mit dem Speicherplatz beeinträchtigt wird, die den normalen Betrieb beeinträchtigen könnten.
  • Compute Engine-Seriellport oder Systemprotokollierung der Instanz: Prüft, ob die Instanz Protokolle für den seriellen Port hat. Diese werden analysiert, um sicherzustellen, dass Jupyter an Port 127.0.0.1:8080 ausgeführt wird.
  • Compute Engine-SSH- und Terminalzugriff der Instanz: Prüft, ob die Compute Engine-VM der Instanz ausgeführt wird, damit der Nutzer SSH verwenden und ein Terminal öffnen kann, um zu prüfen, ob die Speichernutzung unter „home/jupyter“ unter 85 % liegt. Wenn kein Speicherplatz mehr vorhanden ist, bleibt die Instanz möglicherweise im Bereitstellungsstatus hängen.
  • Externe IP deaktiviert: Prüft, ob der externe IP-Zugriff deaktiviert ist. Eine falsche Netzwerkkonfiguration kann dazu führen, dass die Instanz im Bereitstellungsstatus hängen bleibt.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Führen Sie den Befehl gcpdiag aus. 
    ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Verfügbare Parameter für dieses Runbook ansehen

Ersetzen Sie Folgendes:

  • PROJECT_ID: die ID des Projekts, das die Ressource enthält
  • INSTANCE_NAME: Der Name der Ziel-Agent Platform Workbench-Instanz in Ihrem Projekt.
  • ZONE: Die Zone, in der sich die Ziel-Agent Platform Workbench-Instanz befindet.

Nützliche Flags:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.

Berechtigungsfehler bei der Verwendung von Dienstkontorollen mit der Agent Platform

Vorgang

Sie erhalten allgemeine Berechtigungsfehler, wenn Sie Dienstkontorollen mit der Agent Platform verwenden.

Diese Fehler können in Cloud Logging entweder in den Logs der Produktkomponente oder in den Audit-Logs angezeigt werden. Sie können auch in einer beliebigen Kombination der betroffenen Projekte angezeigt werden.

Diese Probleme können eine oder beide der folgenden Ursachen haben:

  • Verwendung der Rolle Service Account Token Creator, wenn die Rolle Service Account User hätte verwendet werden sollen, oder umgekehrt. Diese Rollen gewähren unterschiedliche Berechtigungen für ein Dienstkonto und sind nicht austauschbar. Informationen zu den Unterschieden zwischen den Rollen Service Account Token Creator und Service Account User finden Sie unter Dienstkontenrollen.

  • Sie haben einem Dienstkonto Berechtigungen für mehrere Projekte gewährt, was standardmäßig nicht zulässig ist.

Lösung

Versuchen Sie Folgendes, um das Problem zu beheben:

  • Entscheiden Sie, ob die Rolle Service Account Token Creator oder Service Account User erforderlich ist. Weitere Informationen finden Sie in der IAM-Dokumentation für die von Ihnen verwendeten Agent Platform-Dienste sowie für alle anderen von Ihnen verwendeten Produktintegrationen.

  • Wenn Sie einem Dienstkonto Berechtigungen für mehrere Projekte gewährt haben, müssen Sie dafür sorgen, dass iam.disableCrossProjectServiceAccountUsage, damit Dienstkonten projektübergreifend angehängt werden können. wird nicht erzwungen. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass iam.disableCrossProjectServiceAccountUsage nicht erzwungen wird:

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