Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

排解 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 (建議)。這項作業會在幾分鐘內完成
新增「自訂中繼資料」欄位 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 的疑難排解步驟。

點選「Open JupyterLab」後沒有反應

問題

點選「Open JupyterLab」後，系統沒有任何反應。

解決方案

確認瀏覽器不會封鎖自動開啟的新分頁。 JupyterLab 會在新的瀏覽器分頁中開啟。

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

問題

如果無法存取終端機，或在啟動器中找不到終端機視窗，可能是因為 Agent Platform Workbench 執行個體未啟用終端機存取權。

解決方案

您必須建立新的 Agent Platform Workbench 執行個體，並啟用「Terminal access」(終端機存取權) 選項。執行個體建立後即無法變更這個選項。

開啟 JupyterLab 時發生 502 錯誤

問題

502 錯誤可能表示 Agent Platform Workbench 執行個體尚未準備就緒。

解決方案

請稍候幾分鐘，重新整理 Google Cloud 控制台瀏覽器分頁，然後再試一次。

Notebook 沒有回應

問題

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

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

解決方案

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

無法在 Shared VPC 網路中建立執行個體

問題

嘗試在 Shared VPC 網路中建立執行個體時，會出現類似下列的錯誤訊息：

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

解決方案

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

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

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

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

所需權限

您必須具備下列權限，才能確保 Notebooks 服務帳戶可在 Shared 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

問題

JupyterLab 啟動器中有 Gemini CLI 圖塊，且可成功開啟，但 Gemini 不會回應提示。

解決方案

管理員可能已封鎖 Gemini CLI 的存取權。請參閱「控管 Gemini CLI 的存取權」。

找不到「掛接共用儲存空間」按鈕

問題

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

解決方案

您必須具備 storage.buckets.list 權限，Agent Platform Workbench 執行個體的 JupyterLab 介面才會顯示「Mount shared storage」(掛接共用儲存空間) 按鈕。請要求管理員將專案的 storage.buckets.list 權限授予 Agent Platform Workbench 執行個體的服務帳戶。

使用 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 網域」一節中的步驟操作。

執行個體記錄顯示「Unable to contact Jupyter API」(無法連上 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 收集代理程式指令碼，將 HTTP_TIMEOUT_SESSION 變更為較大的值 (例如 60)，確認要求失敗的原因是否為呼叫回應時間過長，或無法連上要求的網址。

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

問題

根據預設，系統會使用 172.17.0.1/16 的 IP 位址建立 docker0 介面。這可能會與虛擬私有雲網路中的 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 執行個體，您可以從「執行個體」頁面停止並啟動 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 收集代理程式

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 替換為符合 bucket 命名規定的 bucket 名稱。

複製使用者資料

在執行個體的 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，在 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 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 Assist 調查功能排解問題

使用 Gemini CLI 疑難排解診斷檔案問題

連線並開啟 JupyterLab

點選「Open JupyterLab」後沒有反應

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

開啟 JupyterLab 時發生 502 錯誤

Notebook 沒有回應

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

已超過 GPU 配額

建立 Agent Platform Workbench 執行個體

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

無法在 Shared VPC 網路中建立執行個體

所需權限

無法建立含有自訂容器的 Agent Platform Workbench 執行個體

無法使用 Gemini CLI

找不到「掛接共用儲存空間」按鈕

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

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

無法編輯基礎虛擬機器

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

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

意外關機

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

執行個體記錄顯示「Unable to contact Jupyter API」(無法連上 Jupyter API) 和「ReadTimeoutError」

docker0 位址與虛擬私有雲定址衝突

指定的預留項目不存在

實用程序

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

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

確認 Docker 服務狀態

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

驗證 Jupyter 服務狀態並收集記錄

確認 Jupyter 內部 API 是否正在運作

重新啟動 Docker 服務

重新啟動反向 Proxy 代理程式

重新啟動 Jupyter 服務

重新啟動 Notebooks 收集代理程式

修改 Notebooks Collection Agent 指令碼

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

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

建立 Cloud Storage bucket (選用)

複製使用者資料

使用 gcpdiag 調查停滯在佈建狀態的執行個體

Docker

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

排解 Agent Platform Workbench 問題

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

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