Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Agent Platform Workbench のトラブルシューティング

このページでは、Gemini Enterprise Agent Platform Workbench の使用中に問題が発生した場合に役立つトラブルシューティング手順について説明します。

Gemini Enterprise Agent Platform のその他のコンポーネントの使用方法については、Agent Platform のトラブルシューティングをご覧ください。

このページのコンテンツをフィルタするには、トピックをクリックします。

Agent Platform Workbench インスタンス

このセクションでは、Agent Platform Workbench インスタンスのトラブルシューティング手順について説明します。

AI ツールを使用したトラブルシューティング

このセクションでは、トラブルシューティングに AI ツールを使用する方法について説明します。

Cloud Assistance Investigation を使用したトラブルシューティング

Agent Platform を他の Google Cloud プロダクトと接続する際に、Gemini Cloud Assist Investigations がインテグレーションに関する問題のトラブルシューティングに役立つことがあります。インスタンス自体のトラブルシューティングも迅速に行える場合があります。Gemini Cloud Assist を使用すると、インスタンスによって生成された指標とログから分析情報を取得できます。

インスタンスを停止し、View in Compute Engine リンクにアクセスします。
Ops エージェントをインストールします（推奨）。これには数分かかります。
カスタムメタデータフィールド notebook-enable-debug を追加し、これを true に設定します。
インスタンスを再起動し、問題を再現します。
Cloud Assist Investigations API を有効にして構成します。
新しい調査を作成し、自然言語プロンプトを使用して問題を詳しく説明します。
入力すると、調査に追加するリソースの候補がダイアログに表示されます。このリストを確認し、インスタンスをリソースとして追加してください。また、サポートされているプロダクトのリストにある他のリソースも追加してください。
調査を開始し、結果を確認します。

Gemini CLI を使用して診断ファイルのトラブルシューティングを行う

Cloud Assistance Investigation の結果を使用して、インスタンスの診断ファイルに対する AI 主導のさらなる調査を行うことができます。

診断ツールを実行し、結果をアップロードする Cloud Storage バケットを指定します。

sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]

診断ファイルをワークステーションにダウンロードし、Gemini CLI をインストールして構成します。
アプリを起動し、問題について説明します。Cloud Assistance investigation の仮説をコンテキストに含めます。自然言語プロンプトを使用して診断ファイルの内容を読み取り、調査を拡張するようにモデルに指示します。

JupyterLab への接続と起動

このセクションでは、JupyterLab に接続して開く際のトラブルシューティング手順について説明します。

[JupyterLab を開く] をクリックした後、何も行われない

問題

[JupyterLab を開く] をクリックしても、何も行われません。

ソリューション

ブラウザで新しいタブの自動表示がブロックされている場合は、その設定を解除します。JupyterLab が新しいブラウザタブで開きます。

Agent Platform Workbench インスタンスのターミナルにアクセスできない

問題

ターミナルにアクセスできない場合、またはランチャーでターミナルウィンドウが見つからない場合は、Agent Platform Workbench インスタンスでターミナルアクセスが有効になっていない可能性があります。

ソリューション

ターミナルアクセス オプションを有効にして、新しい Agent Platform Workbench インスタンスを作成する必要があります。このオプションをインスタンスの作成後に変更することはできません。

JupyterLab を開いたときに 502 エラーが発生する

問題

502 エラーが発生した場合は、Agent Platform Workbench インスタンスの準備ができていない可能性があります。

ソリューション

数分待ってから Google Cloud コンソールのブラウザタブを更新して、もう一度お試しください。

ノートブックが応答しない

問題

Agent Platform Workbench インスタンスがセルを実行していないか、フリーズしているように見えます。

ソリューション

トップメニューから [Kernel] をクリックし、[Restart Kernel] をクリックして、カーネルを再起動してみてください。それでも解決しない場合は、次のことを試してください。

ブラウザの JupyterLab ページを更新します。保存されていないセルの出力は破棄されます。出力を再生成するには、これらのセルを再度実行する必要があります。
インスタンスをリセットします。

SSH を使用して Agent Platform Workbench インスタンスに接続できない

問題

ターミナルウィンドウから SSH 経由でインスタンスに接続できません。

Agent Platform Workbench インスタンスは、OS Login を使用して SSH アクセスを有効にします。インスタンスを作成すると、Agent Platform Workbench はメタデータキー enable-oslogin を TRUE に設定し、デフォルトで OS Login を有効にします。SSH 経由でインスタンスに接続できない場合は、このメタデータキーを TRUE に設定する必要があります。

ソリューション

Google Cloud コンソールを使用して Agent Platform Workbench インスタンスに接続することはできません。ターミナルウィンドウから SSH 経由でインスタンスに接続できない場合は、以下をご覧ください。

メタデータキー enable-oslogin を TRUE に設定するには、Notebooks API の projects.locations.instances.patch メソッドまたは Agent Platform SDK の gcloud workbench instances update コマンドを使用します。

GPU 割り当てを超えた

問題

GPU を使用する Agent Platform Workbench インスタンスを作成できません。

ソリューション

プロジェクトで使用可能な GPU の数を [割り当て] ページで確認してください。GPU が割り当てページのリストにない場合や、さらに GPU 割り当てが必要な場合には、Compute Engine GPU の割り当て量の増加をリクエストしてください。割り当て上限の引き上げをリクエストするをご覧ください。

Agent Platform Workbench インスタンスの作成

このセクションでは、Agent Platform Workbench インスタンスの作成に関連する問題のトラブルシューティングについて説明します。

インスタンスがいつまでも保留状態になる、またはプロビジョニングのステータスから進まなくなる

問題

Agent Platform Workbench インスタンスの作成後、インスタンスがいつまでも保留状態のままになります。シリアルログに次のようなエラーが表示されることがあります。

Could not resolve host: notebooks.googleapis.com

インスタンスがプロビジョニングのステータスから先に進まない場合は、インスタンスのプライベートネットワーク構成が無効な可能性があります。

ソリューション

インスタンスのログに接続エラーまたはタイムアウトエラーが表示されるのセクションの手順に沿って操作します。

共有 VPC ネットワーク内にインスタンスを作成できない

問題

共有 VPC ネットワーク内にインスタンスを作成しようとすると、次のようなエラーメッセージが表示されます。

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

ソリューション

この問題は、Notebooks サービスアカウントが適切な権限なしでインスタンスを作成しようとしているために発生しています。

Notebooks サービスアカウントに、共有 VPC ネットワーク内に Agent Platform Workbench インスタンスを作成するために必要な権限を確実に付与するには、ホストプロジェクトの Notebooks サービスアカウントに Compute ネットワークユーザーロール（roles/compute.networkUser）IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

この事前定義ロールには、Notebooks サービスアカウントが共有 VPC ネットワーク内に Agent Platform Workbench インスタンスを作成するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

Notebooks サービスアカウントが共有 VPC ネットワーク内に Agent Platform Workbench インスタンスを作成するには、次の権限が必要です。

サブネットワークを使用するには: compute.subnetworks.use

管理者は、Notebooks サービスアカウントに、カスタムロールや他の事前定義ロールを付与することもできます。

カスタムコンテナを使用して Agent Platform Workbench インスタンスを作成できない

問題

Google Cloud コンソールで Agent Platform Workbench インスタンスを作成するときに、カスタムコンテナを使用できません。

ソリューション

Agent Platform Workbench インスタンスへのカスタムコンテナの追加はサポートされておらず、 Google Cloud コンソールを使用してカスタムコンテナを追加することはできません。

カスタムコンテナを使用する代わりに、conda 環境を追加することをおすすめします。

Notebooks API を使用して、Agent Platform Workbench インスタンスにカスタムコンテナを追加できますが、この機能はサポートされていません。

Gemini CLI を使用できない

問題

Gemini CLI タイルが JupyterLab ランチャーにあり、正常に開きますが、Gemini がプロンプトに応答しません。

ソリューション

管理者が Gemini CLI へのアクセスをブロックしている可能性があります。Gemini CLI へのアクセスを制御するをご覧ください。

[Mount shared storage] ボタンが表示されない

問題

JupyterLab インターフェースの [File Browser] タブに [Mount shared storage] ボタンが表示されません。

ソリューション

Agent Platform Workbench インスタンスの JupyterLab インターフェースに [共有ストレージをマウント] ボタンを表示するには、storage.buckets.list 権限が必要です。Agent Platform Workbench インスタンスのサービスアカウントに、プロジェクトに対する storage.buckets.list 権限を付与するよう管理者に依頼してください。

Managed Service for Apache Spark の使用時に 599 エラーが発生する

問題

Managed Service for Apache Spark が有効になっているインスタンスを作成しようとすると、次のようなエラーメッセージが表示されます。

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

ソリューション

Cloud DNS 構成で、*.googleusercontent.com ドメインの Cloud DNS エントリを追加します。

サードパーティの JupyterLab 拡張機能をインストールできない

問題

サードパーティの JupyterLab 拡張機能をインストールしようとすると、Error: 500 メッセージが表示されます。

ソリューション

サードパーティの JupyterLab 拡張機能は、Agent Platform Workbench インスタンスではサポートされていません。

基盤となる仮想マシンを編集できない

問題

Agent Platform Workbench インスタンスの基盤となる仮想マシン（VM）を編集しようとすると、次のようなエラーメッセージが表示されることがあります。

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

ソリューション

Google Cloud コンソールまたは Compute Engine API を使用してインスタンスの基盤となる VM を編集することはできないため、このエラーが発生します。

Agent Platform Workbench インスタンスの基盤となる VM を編集するには、Notebooks API の projects.locations.instances.patch メソッドまたは Agent Platform SDK の gcloud workbench instances update コマンドを使用します。

conda 環境を追加した後に `pip` パッケージが利用できない

問題

conda ベースのカーネルを追加した後、pip パッケージが利用できません。

ソリューション

この問題を解決するには、conda 環境を追加するを参照して、次のことを試してください。

DL_ANACONDA_ENV_HOME 変数を使用していることと、その変数に環境の名前が含まれていることを確認します。
pip が opt/conda/envs/ENVIRONMENT/bin/pip のようなパスにあることを確認します。which pip コマンドを実行すると、パスを取得できます。

シングルユーザーアクセスでインスタンスのデータにアクセスしたり、データをコピーしたりできない

問題

シングルユーザーアクセスでインスタンスのデータにアクセスできません。

シングルユーザーアクセスが設定されている Agent Platform Workbench インスタンスの場合、インスタンスのデータにアクセスできるのは、指定されたシングルユーザー（オーナー）だけです。

ソリューション

インスタンスのオーナー以外がデータにアクセスしたり、コピーできるようにする必要がある場合は、サポートケースを登録してください。

予期しないシャットダウン

問題

Agent Platform Workbench インスタンスが予期せずシャットダウンします。

ソリューション

インスタンスが予期せずシャットダウンする場合は、アイドル状態でのシャットダウンが開始した可能性があります。

アイドル状態でのシャットダウンを有効にした場合、指定した期間内にカーネルアクティビティが発生しないと、インスタンスがシャットダウンされます。アイドルタイムアウトタイマーをリセットするアクティビティとしては、セルの実行やノートブックへの新しい出力があります。CPU 使用率では、アイドルタイムアウトタイマーはリセットされません。

インスタンスのログに接続エラーまたはタイムアウトエラーが表示される

問題

Agent Platform Workbench インスタンスのログに接続エラーまたはタイムアウトエラーが表示されます。

ソリューション

インスタンスのログに接続エラーまたはタイムアウトエラーが表示された場合は、Jupyter サーバーがポート 8080 で実行されていることを確認します。Jupyter の内部 API がアクティブであることを確認するのセクションの手順に沿って操作します。

External IP をオフにしてプライベート VPC ネットワークを使用している場合は、ネットワーク構成オプションのドキュメントも参照してください。次の点を考慮してください。

VPC ホストプロジェクトにインスタンスが配置されているリージョンと同じリージョンで選択したサブネットワークで、プライベート Google アクセスを有効にする必要があります。プライベート Google アクセスの構成に関する詳細については、プライベート Google アクセスのドキュメントをご覧ください。
Cloud DNS を使用している場合、インスタンスは、ネットワーク構成オプションのドキュメントで指定されている必要な Cloud DNS ドメインを解決できる必要があります。これを確認するには、インスタンスが必要な DNS ドメインを解決できることを確認するのセクションの手順に沿って操作します。

インスタンスのログに [Unable to contact Jupyter API]、[ReadTimeoutError] と表示される

問題

Agent Platform Workbench インスタンスのログに次のようなエラーが表示されます。

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

ソリューション

インスタンスのログに接続エラーまたはタイムアウトエラーが表示されるのセクションの手順に沿って操作します。また、Notebooks Collection Agent スクリプトを変更して HTTP_TIMEOUT_SESSION をより大きな値（60 など）に変更することで、呼び出しの応答に時間がかかりすぎたためにリクエストが失敗したのか、それともリクエストされた URL に到達できなかったのかを確認することもできます。

`docker0` アドレスが VPC アドレスと競合する

問題

デフォルトでは、docker0 インターフェースは 172.17.0.1/16 の IP アドレスで作成されます。これにより、VPC ネットワーク内の IP アドレスと競合し、インスタンスが 172.17.0.1/16 アドレスを持つ他のエンドポイントに接続できなくなる可能性があります。

ソリューション

次の起動後スクリプトを使用して、起動後スクリプトの動作を run_once に設定すると、強制的に、VPC ネットワークと競合しない IP アドレスで docker0 インターフェースを作成できます。

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

指定された予約が存在しない

問題

インスタンスを作成するオペレーションで、Specified reservations do not exist エラーメッセージが表示されます。オペレーションの出力は次のようになります。

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

ソリューション

一部の Compute Engine マシンタイプでは、作成時にローカル SSD や最小 CPU プラットフォームなどの追加パラメータが必要です。インスタンス仕様に、これらの追加フィールドを含める必要があります。

Agent Platform Workbench インスタンスでは、デフォルトで自動最小 CPU プラットフォームが使用されます。予約で特定のプラットフォームを設定している場合は、Agent Platform Workbench インスタンスの作成時に min_cpu_platform を適切に設定する必要があります。
Agent Platform Workbench インスタンスでは、ローカル SSD の数は常にマシンタイプに応じたデフォルト値に設定されます。たとえば、a2-ultragpu-1g には常に 1 つのローカル SSD があり、a2-highgpu-1g には常に 0 個のローカル SSD があります。Agent Platform Workbench インスタンスで使用する予約を作成する場合は、ローカル SSD をデフォルト値のままにする必要があります。

役に立つ手順

このセクションでは、役に立ちそうな手順について説明します。

SSH を使用して Agent Platform Workbench インスタンスに接続する

SSH を使用してインスタンスに接続するには、Cloud Shell または Google Cloud CLI がインストールされている環境で次のコマンドを入力します。

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

次のように置き換えます。

PROJECT_ID: プロジェクト ID
ZONE: インスタンスが配置されている Google Cloud ゾーン
INSTANCE_NAME: インスタンスの名前

インスタンスの Compute Engine の詳細ページを開き、[SSH] ボタンをクリックしてインスタンスに接続することもできます。

Inverting Proxy サーバーに再登録する

Agent Platform Workbench インスタンスを内部 Inverting Proxy サーバーに再登録するには、インスタンスページから VM を停止して起動します。あるいは、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

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

Docker サービスのステータスを確認する

Docker サービスのステータスを確認するには、SSH で Agent Platform Workbench インスタンスに接続して、次のように入力します。

sudo service docker status

Inverting Proxy エージェントが実行されていることを確認する

ノートブックの Inverting Proxy エージェントが実行されているかどうかを確認するには、SSH で Agent Platform Workbench インスタンスに接続して、次のように入力します。

# 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 サービスのステータスを確認してログを収集する

Jupyter サービスのステータスを確認するには、SSH で Agent Platform Workbench インスタンスに接続して、次のように入力します。

sudo service jupyter status

Jupyter サービスログを収集するには、以下を入力します。

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

Jupyter の内部 API がアクティブであることを確認する

Jupyter API は常にポート 8080 で実行する必要があります。これを確認するには、インスタンスの syslog で次のようなエントリを調べます。

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

Jupyter の内部 API がアクティブであることを確認するには、SSH を使用して Agent Platform Workbench インスタンスに接続して、次のように入力する方法もあります。

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

リクエストに時間がかかりすぎる場合は、API が応答するまでの時間を測定することもできます。

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

Agent Platform Workbench インスタンスでこれらのコマンドを実行するには、JupyterLab を開いて新しいターミナルを作成します。

Docker サービスを再起動する

Docker サービスを再起動するには、インスタンスページから VM を停止して起動します。または、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

sudo service docker restart

Inverting Proxy エージェントを再起動する

Inverting Proxy エージェントを再起動するには、インスタンスのページから VM を停止して起動します。あるいは、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

sudo docker restart proxy-agent

Jupyter サービスを再起動する

Jupyter サービスを再起動するには、インスタンスページから VM を停止して起動します。または、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

sudo service jupyter restart

Notebooks Collection Agent を再起動する

Notebooks Collection Agent サービスは、Agent Platform Workbench インスタンスのコアサービスのステータスを確認する Python プロセスをバックグラウンドで実行します。

Notebooks Collection Agent サービスを再起動するには、Google Cloud コンソールから VM を停止して起動します。あるいは、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

sudo systemctl stop notebooks-collection-agent.service

続けて次のように入力します。

sudo systemctl start notebooks-collection-agent.service

Agent Platform Workbench インスタンスでこれらのコマンドを実行するには、JupyterLab を開いて新しいターミナルを作成します。

Notebooks Collection Agent スクリプトを変更する

スクリプトにアクセスして編集するには、インスタンスでターミナルを開くか、SSH を使用して Agent Platform Workbench インスタンスに接続し、次のように入力します。

nano /opt/deeplearning/bin/notebooks_collection_agent.py

ファイルを編集したら、必ず保存してください。

次に、Notebooks Collection Agent サービスを再起動する必要があります。

インスタンスが必要な DNS ドメインを解決できることを確認する

インスタンスが必要な DNS ドメインを解決できることを確認するには、SSH を使用して Agent Platform Workbench インスタンスに接続して、次のように入力します。

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

または

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

インスタンスで Managed Service for Apache Spark が有効になっている場合は、次のコマンドを実行して、インスタンスが *.kernels.googleusercontent.com を解決することを確認できます。

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

Agent Platform Workbench インスタンスでこれらのコマンドを実行するには、JupyterLab を開いて新しいターミナルを作成します。

インスタンスのユーザーデータのコピーを作成する

インスタンスのユーザーデータを Cloud Storage にコピーするには、次の手順を完了します。

Cloud Storage バケットを作成する（省略可）

インスタンスが配置されているプロジェクトと同じプロジェクトに、ユーザーデータを保存する Cloud Storage バケットを作成します。すでに Cloud Storage バケットがある場合は、この手順をスキップします。

Cloud Storage バケットを作成します。
```
gcloud storage buckets create gs://BUCKET_NAME
```
BUCKET_NAME は、バケット名の要件を満たすバケット名に置き換えます。

ユーザーデータをコピーする

インスタンスの JupyterLab インターフェースで、[File] > [New] > [Terminal] を選択して、ターミナルウィンドウを開きます。Agent Platform Workbench インスタンスの場合は、代わりに SSH を使用してインスタンスのターミナルに接続できます。
gcloud CLI を使用して、Cloud Storage バケットにユーザーデータをコピーします。次のコマンドの例では、インスタンスの /home/jupyter/ ディレクトリから Cloud Storage バケット内のディレクトリにすべてのファイルをコピーします。
```
gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
```
次のように置き換えます。
- BUCKET_NAME: Cloud Storage バケットの名前。
- PATH: ファイルをコピーするディレクトリのパス（例: /copy/jupyter/）

gcpdiag を使用して、プロビジョニングから進まなくなっているインスタンスを調べる

gcpdiag はオープンソースツールです。正式にサポートされている Google Cloud プロダクトではありません。gcpdiag ツールを使用すると、 Google Cloudプロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。

この gcpdiag ランブックでは、Agent Platform Workbench インスタンスがプロビジョニングのステータスから先に進まなくなる原因を調査します。次の点を調べます。

ステータス: インスタンスの現在のステータスを確認し、プロビジョニングの状態で止まっていて、停止やアクティブの状態ではないことを確認します。
インスタンスの Compute Engine VM ブートディスクイメージ: カスタムコンテナ、公式の workbench-instances イメージ、Deep Learning VM イメージ、プロビジョニングステータスから進まなくなる原因となるサポート対象外のイメージのどれを使用してインスタンスが作成されたかを確認します。
カスタムスクリプト: インスタンスで、デフォルトの Jupyter ポートを変更するか、依存関係を壊すカスタムの起動スクリプトまたは起動後のスクリプトが使用されているかどうか確認します。これらは、インスタンスがプロビジョニングのステータスから進まなくなる原因になり得ます。
環境バージョン: アップグレードの可否を確認して、インスタンスで最新の環境バージョンが使用されているかどうか確認します。バージョンが古いと、インスタンスがプロビジョニングステータスから進まなくなる可能性があります。
インスタンスの Compute Engine VM のパフォーマンス: VM の現在のパフォーマンスをチェックし、正常なオペレーションの妨げとなる高い CPU 使用率、メモリ不足、ディスク容量の問題によってパフォーマンスが低下していないことを確認します。
インスタンスの Compute Engine シリアルポートまたはシステムロギング: インスタンスにシリアルポートのログがあるかどうか確認します。このログを分析して、Jupyter がポート 127.0.0.1:8080 で実行されていることを確認します。
インスタンスの Compute Engine SSH とターミナルへのアクセス: インスタンスの Compute Engine VM が実行されているかどうか確認します。実行されていれば、ユーザーは SSH を使用してターミナルを開き、「home/jupyter」の容量の使用率が 85% 未満であることを確認できます。空き容量が残っていないと、インスタンスがプロビジョニングのステータスから進まなくなる可能性があります。
外部 IP がオフになっている: 外部 IP アクセスがオフになっているかどうかを確認します。ネットワーク構成が正しくないと、インスタンスがプロビジョニングステータスから進まなくなる可能性があります。

Docker

Docker コンテナで gcpdiag を起動するラッパーを使用して gcpdiag を実行できます。Docker または Podman がインストールされている必要があります。

ローカルワークステーションで次のコマンドをコピーして実行します。
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

gcpdiag コマンドを実行します。

./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

このランブックで使用可能なパラメータを表示します。

次のように置き換えます。

PROJECT_ID: リソースを含むプロジェクトの ID。
INSTANCE_NAME: プロジェクト内のターゲット Agent Platform Workbench インスタンスの名前。
ZONE: ターゲット Agent Platform Workbench インスタンスが配置されているゾーン。

有用なフラグ:

--universe-domain: 該当する場合、リソースをホストする信頼できるパートナーのソブリンクラウドドメイン
--parameter または -p: ランブックパラメータ

gcpdiag ツールのフラグの一覧と説明については、gcpdiag の使用手順をご覧ください。

Agent Platform でサービスアカウントのロールを使用する際の権限エラー

問題

Agent Platform でサービスアカウントロールを使用すると、一般的な権限エラーが発生します。

これらのエラーは、Cloud Logging のプロダクトコンポーネントログまたは監査ログに表示されることがあります。影響を受けるプロジェクトの任意の組み合わせで表示されることもあります。

これらの問題は、次のいずれかまたは両方が原因で発生する可能性があります。

Service Account User ロールを使用すべきときに Service Account Token Creator ロールを使用した場合、またはその逆の場合。これらのロールはサービスアカウントに異なる権限を付与するため、相互に置き換えることはできません。Service Account Token Creator ロールと Service Account User ロールの違いについては、サービスアカウントのロールをご覧ください。
複数のプロジェクトにまたがってサービスアカウントに権限が付与されています。これはデフォルトでは許可されていません。

解決策

この問題を解決するには、次の対処方法をいくつか試してください。

Service Account Token Creator ロールまたは Service Account User ロールが必要かどうかを判断します。詳細については、使用している Agent Platform サービスの IAM ドキュメントと、使用している他のプロダクトインテグレーションをご覧ください。
複数のプロジェクトにサービスアカウントの権限を付与している場合は、iam.disableCrossProjectServiceAccountUsage が強制適用されていないことを確認して、プロジェクトにまたがってサービスアカウントを関連付けられるようにします。iam.disableCrossProjectServiceAccountUsage が強制適用されていないことを確認するには、次のコマンドを実行します。
```
gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=PROJECT_ID
```

Agent Platform Workbench のトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Agent Platform Workbench インスタンス

AI ツールを使用したトラブルシューティング

Cloud Assistance Investigation を使用したトラブルシューティング

Gemini CLI を使用して診断ファイルのトラブルシューティングを行う

JupyterLab への接続と起動

[JupyterLab を開く] をクリックした後、何も行われない

Agent Platform Workbench インスタンスのターミナルにアクセスできない

JupyterLab を開いたときに 502 エラーが発生する

ノートブックが応答しない

SSH を使用して Agent Platform Workbench インスタンスに接続できない

GPU 割り当てを超えた

Agent Platform Workbench インスタンスの作成

インスタンスがいつまでも保留状態になる、またはプロビジョニングのステータスから進まなくなる

共有 VPC ネットワーク内にインスタンスを作成できない

必要な権限

カスタム コンテナを使用して Agent Platform Workbench インスタンスを作成できない

Gemini CLI を使用できない

[Mount shared storage] ボタンが表示されない

Managed Service for Apache Spark の使用時に 599 エラーが発生する

サードパーティの JupyterLab 拡張機能をインストールできない

基盤となる仮想マシンを編集できない

conda 環境を追加した後に pip パッケージが利用できない

シングル ユーザー アクセスでインスタンスのデータにアクセスしたり、データをコピーしたりできない

予期しないシャットダウン

インスタンスのログに接続エラーまたはタイムアウト エラーが表示される

インスタンスのログに [Unable to contact Jupyter API]、[ReadTimeoutError] と表示される

docker0 アドレスが VPC アドレスと競合する

指定された予約が存在しない

役に立つ手順

SSH を使用して Agent Platform Workbench インスタンスに接続する

Inverting Proxy サーバーに再登録する

Docker サービスのステータスを確認する

Inverting Proxy エージェントが実行されていることを確認する

Jupyter サービスのステータスを確認してログを収集する

Jupyter の内部 API がアクティブであることを確認する

Docker サービスを再起動する

Inverting Proxy エージェントを再起動する

Jupyter サービスを再起動する

Notebooks Collection Agent を再起動する

Notebooks Collection Agent スクリプトを変更する

インスタンスが必要な DNS ドメインを解決できることを確認する

インスタンスのユーザーデータのコピーを作成する

Cloud Storage バケットを作成する（省略可）

ユーザーデータをコピーする

gcpdiag を使用して、プロビジョニングから進まなくなっているインスタンスを調べる

Docker

Agent Platform でサービス アカウントのロールを使用する際の権限エラー

Agent Platform Workbench のトラブルシューティング

カスタムコンテナを使用して Agent Platform Workbench インスタンスを作成できない

conda 環境を追加した後に `pip` パッケージが利用できない

シングルユーザーアクセスでインスタンスのデータにアクセスしたり、データをコピーしたりできない

インスタンスのログに接続エラーまたはタイムアウトエラーが表示される

`docker0` アドレスが VPC アドレスと競合する

Agent Platform でサービスアカウントのロールを使用する際の権限エラー