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 Assist 調查功能排解問題

將 Agent Platform 與其他 Google Cloud 產品連結時，您可能會發現 Gemini Cloud Assist 調查有助於排解整合問題，也能加快執行個體本身的疑難排解速度。Gemini Cloud Assist 可讓您從執行個體產生的指標和記錄中取得洞察資料。

停止執行個體，然後點選 View in Compute Engine 連結。
安裝 Ops Agent (建議)。這項作業需要幾分鐘時間
新增「Custom Metadata」(自訂中繼資料) 欄位 notebook-enable-debug，並將此欄位設為 true
重新啟動執行個體，然後重現問題。
啟用及設定 Cloud Assist Investigations API。
建立新的調查，並使用自然語言提示詞詳細說明問題。
輸入時，系統會顯示對話方塊，建議您將資源新增至調查。請查看這份清單，務必將執行個體新增為資源，以及這份支援產品清單中的任何其他資源
開始調查並查看結果。

使用 Gemini CLI 解決診斷檔案問題

您可以根據 Cloud Assistance 調查結果，對執行個體的診斷檔案進行進一步的 AI 輔助調查。

執行診斷工具，並指定要上傳結果的 Cloud Storage bucket。

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

將診斷檔案下載到工作站，然後安裝及設定 Gemini CLI。
啟動應用程式，然後說明問題。在脈絡中加入 Cloud Assistance 調查的假設。使用自然語言提示，要求模型讀取診斷檔案內容，以擴大調查範圍。

連線及開啟 JupyterLab

本節說明如何排解連線至 JupyterLab 和開啟 JupyterLab 的問題。

按一下「Open JupyterLab」後沒有任何反應

問題

按一下「Open 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 登入功能啟用 SSH 存取權。建立執行個體時，Agent Platform Workbench 會將中繼資料鍵 enable-oslogin 設為 TRUE，預設啟用 OS 登入。如果無法使用 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

如果執行個體停滯在佈建狀態，可能是因為執行個體的私人網路設定無效。

解決方案

請按照「執行個體記錄顯示連線或逾時錯誤」一節中的步驟操作。

無法在共用虛擬私有雲網路中建立執行個體

問題

嘗試在共用虛擬私有雲網路中建立執行個體時，會收到類似以下的錯誤訊息：

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

解決方案

問題在於Notebooks 服務帳戶嘗試建立執行個體，但沒有正確權限。

為確保 Notebooks 服務帳戶具備必要權限，能在共用虛擬私有雲網路中建立 Agent Platform Workbench 執行個體，請要求管理員將主專案的 Compute 網路使用者角色 (roles/compute.networkUser) IAM 角色授予 Notebooks 服務帳戶。

如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

這個預先定義的角色具備所需權限，可確保 Notebooks 服務帳戶能在共用 VPC 網路中建立 Agent Platform Workbench 執行個體。如要查看確切的必要權限，請展開「Required permissions」(必要權限) 部分：

所需權限

如要確保 Notebooks 服務帳戶可以在共用虛擬私有雲網路中建立 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 的存取權」。

沒有「掛接共用儲存空間」按鈕

問題

JupyterLab 介面的「File Browser」(檔案瀏覽器) 分頁中沒有「Mount shared storage」(掛接共用儲存空間) 按鈕。

解決方案

您必須具備 storage.buckets.list 權限，才能在 Agent Platform Workbench 執行個體的 JupyterLab 介面中看到「掛接共用儲存空間」按鈕。請管理員授予專案的 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 訊息。

解決方案

Agent Platform Workbench 執行個體不支援第三方 JupyterLab 擴充功能。

無法編輯基礎虛擬機器

問題

嘗試編輯 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，且使用私人虛擬私有雲網路，請務必按照網路設定選項說明文件操作。請考量下列事項：

您必須在虛擬私有雲主機專案中，於執行個體所在的相同區域，對所選子網路啟用 Private Google Access。如要進一步瞭解如何設定 Private Google Access，請參閱Private Google Access 說明文件。
如果您使用 Cloud DNS，執行個體必須能夠解析網路設定選項說明文件中指定的必要 Cloud DNS 網域。如要驗證這點，請按照「確認執行個體可以解析必要的 DNS 網域」一節中的步驟操作。

執行個體記錄顯示「無法與 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)，藉此驗證要求是否因呼叫回應時間過長或無法連上要求的網址而失敗。

`docker0` 與虛擬私有雲位址發生位址衝突

問題

根據預設，docker0 介面會以 172.17.0.1/16 的 IP 位址建立。這可能會與虛擬私有雲網路中的 IP 位址衝突，導致執行個體無法使用 172.17.0.1/16 位址連線至其他端點。

解決方案

您可以透過下列開機後指令碼，並將開機後指令碼行為設為 run_once，強制建立 docker0 介面，並使用與虛擬私有雲網路不衝突的 IP 位址。

#!/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 執行個體

在 Cloud Shell 或任何已安裝 Google Cloud CLI 的環境中，輸入下列指令，透過 SSH 連線至執行個體。

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」SSH按鈕，連線至執行個體。

透過反向 Proxy 伺服器重新註冊

如要向內部反向 Proxy 伺服器重新註冊 Agent Platform Workbench 執行個體，請從「Instances」(執行個體) 頁面停止並啟動 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

確認反向 Proxy 代理程式是否正在運作

如要確認筆記本反向 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 上執行。如要確認這點，請檢查執行個體的系統記錄，是否有類似下列的項目：

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 服務，請從「Instances」(執行個體) 頁面停止並啟動 VM，或是使用 SSH 連線至 Agent Platform Workbench 執行個體，然後輸入：

sudo service docker restart

重新啟動反向 Proxy 代理程式

如要重新啟動 Inverting Proxy 代理程式，請從「Instances」(執行個體) 頁面停止並啟動 VM，或是使用 SSH 連線至 Agent Platform Workbench 執行個體，然後輸入：

sudo docker restart proxy-agent

重新啟動 Jupyter 服務

如要重新啟動 Jupyter 服務，請從「Instances」(執行個體) 頁面停止並啟動 VM，或是使用 SSH 連線至 Agent Platform Workbench 執行個體，然後輸入以下內容：

sudo service jupyter restart

重新啟動 Notebooks Collection Agent

Notebooks Collection Agent 服務會在背景執行 Python 程序，驗證 Agent Platform Workbench 執行個體核心服務的狀態。

如要重新啟動 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 bucket (選用)

在執行個體所在的專案中，建立 Cloud Storage bucket，用於儲存使用者資料。如果已有 Cloud Storage bucket，請略過這個步驟。

建立 Cloud Storage bucket：
```
gcloud storage buckets create gs://BUCKET_NAME
```
將 BUCKET_NAME 替換為符合值區命名規定的值區名稱。

複製使用者資料

在執行個體的 JupyterLab 介面中，依序選取「File」>「New」>「Terminal」，開啟終端機視窗。如果是 Agent Platform Workbench 執行個體，則可以使用 SSH 連線至執行個體的終端機。
使用 gcloud CLI 將使用者資料複製到 Cloud Storage bucket。以下範例指令會將執行個體 /home/jupyter/ 目錄中的所有檔案，複製到 Cloud Storage bucket 的目錄。
```
gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
```
更改下列內容：
- BUCKET_NAME：Cloud Storage bucket 的名稱
- PATH：要複製檔案的目錄路徑，例如：/copy/jupyter/

使用 gcpdiag 檢查卡在佈建程序的執行個體

gcpdiag 是開放原始碼工具，並非官方支援的 Google Cloud 產品。您可以使用 gcpdiag 工具找出並修正專案問題 Google Cloud。詳情請參閱 GitHub 上的 gcpdiag 專案。

這本gcpdiag執行手冊會調查 Agent Platform Workbench 執行個體停滯在佈建狀態的可能原因，包括以下領域：

狀態：檢查執行個體的目前狀態，確保執行個體停滯在佈建程序中，而非已停止或處於有效狀態。
執行個體的 Compute Engine VM 開機磁碟映像檔：檢查執行個體是否使用自訂容器、官方 workbench-instances 映像檔、深度學習 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

您可以使用啟動 gcpdiag 的 wrapper，在 Docker 容器中執行 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

查看這本 Runbook 的可用參數。

更改下列內容：

PROJECT_ID：包含資源的專案 ID。
INSTANCE_NAME：專案中目標 Agent Platform Workbench 執行個體的名稱。
ZONE：目標 Agent Platform Workbench 執行個體所在的可用區。

實用旗標：

--universe-domain：如果適用，則為代管資源的信任合作夥伴 Sovereign Cloud網域
--parameter 或 -p：Runbook 參數

如需所有 gcpdiag 工具旗標的清單和說明，請參閱 gcpdiag 使用說明。

使用 Agent Platform 的服務帳戶角色時發生權限錯誤

問題

使用 Agent Platform 的服務帳戶角色時，會發生一般權限錯誤。

這些錯誤可能會出現在 Cloud Logging 的產品元件記錄或稽核記錄中，也可能出現在受影響專案的任何組合中。

這些問題可能是由下列一或多項原因所致：

使用 Service Account Token Creator 角色，但應該使用 Service Account User 角色，反之亦然。這些角色會授予服務帳戶不同的權限，且無法互換。如要瞭解 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 Assist 調查功能排解問題

使用 Gemini CLI 解決診斷檔案問題

連線及開啟 JupyterLab

按一下「Open JupyterLab」後沒有任何反應

無法存取 Agent Platform Workbench 執行個體中的終端機

開啟 JupyterLab 時發生 502 錯誤

筆電沒有回應

無法使用 SSH 連線至 Agent Platform Workbench 執行個體

已超過 GPU 配額

建立 Agent Platform Workbench 執行個體

執行個體無限期處於待處理狀態，或卡在佈建狀態

無法在共用虛擬私有雲網路中建立執行個體

所需權限

無法使用自訂容器建立 Agent Platform Workbench 執行個體

無法使用 Gemini CLI

沒有「掛接共用儲存空間」按鈕

使用 Managed Service for Apache Spark 時發生 599 錯誤

無法安裝第三方 JupyterLab 擴充功能

無法編輯基礎虛擬機器

新增 conda 環境後，pip 套件無法使用

無法存取或複製僅限單一使用者存取的執行個體資料

意外關機

執行個體記錄檔顯示連線或逾時錯誤

執行個體記錄顯示「無法與 Jupyter API 聯絡」和「ReadTimeoutError」

docker0 與虛擬私有雲位址發生位址衝突

指定的預訂不存在

實用程序

使用 SSH 連線至 Agent Platform Workbench 執行個體

透過反向 Proxy 伺服器重新註冊

確認 Docker 服務狀態

確認反向 Proxy 代理程式是否正在運作

確認 Jupyter 服務狀態並收集記錄

確認 Jupyter 內部 API 是否已啟動

重新啟動 Docker 服務

重新啟動反向 Proxy 代理程式

重新啟動 Jupyter 服務

重新啟動 Notebooks Collection Agent

修改 Notebooks Collection Agent 指令碼

確認執行個體可以解析必要的 DNS 網域

複製執行個體上的使用者資料

建立 Cloud Storage bucket (選用)

複製使用者資料

使用 gcpdiag 檢查卡在佈建程序的執行個體

Docker

使用 Agent Platform 的服務帳戶角色時發生權限錯誤

排解 Agent Platform Workbench 問題

新增 conda 環境後，`pip` 套件無法使用

`docker0` 與虛擬私有雲位址發生位址衝突