פתרון בעיות ב-Agent Platform Workbench

בדף הזה מתוארים שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות במהלך השימוש ב-Gemini Enterprise Agent Platform Workbench.

במאמר פתרון בעיות ב-Agent Platform מוסבר איך להשתמש ברכיבים אחרים של Gemini Enterprise Agent Platform.

כדי לסנן את התוכן בדף הזה, לוחצים על אחד מהנושאים:

כל מכונות Agent Platform Workbench

מכונות של Agent Platform Workbench

בקטע הזה מוסבר איך לפתור בעיות במכונות של Agent Platform Workbench.

פתרון בעיות באמצעות כלים מבוססי-AI

בקטע הזה נסביר איך להשתמש בכלי AI כדי לפתור בעיות.

פתרון בעיות באמצעות Cloud Assistance Investigations

כשמחברים את Agent Platform למוצרים אחרים של Google Cloud , אפשר להיעזר ב-Gemini Cloud Assist Investigations כדי לפתור בעיות בשילוב. הוא גם יכול להאיץ את פתרון הבעיות במכונה עצמה. ‫Gemini Cloud Assist מאפשר לכם להפיק תובנות ממדדים ומיומנים שנוצרו על ידי המכונה.

• עוצרים את המכונה ולוחצים על הקישור View in Compute Engine.
• מתקינים את סוכן התפעול (מומלץ). הפעולה הזו תימשך כמה דקות
• מוסיפים שדה מטא-נתונים בהתאמה אישית 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 להקשר. מבקשים מהמודל להרחיב את הבדיקה על ידי קריאת התוכן של קובץ האבחון באמצעות הנחיות בשפה טבעית.

התחברות ל-JupyterLab ופתיחה שלו

בקטע הזה מתוארים השלבים לפתרון בעיות בחיבור ל-JupyterLab ובפתיחה שלו.

לא קורה כלום אחרי שלוחצים על Open JupyterLab

הבעיה

כשלוחצים על Open JupyterLab, לא קורה כלום.

הפתרון

מוודאים שהדפדפן לא חוסם פתיחה אוטומטית של כרטיסיות חדשות. ‫JupyterLab נפתח בכרטיסייה חדשה בדפדפן.

לא מצליחים לגשת לטרמינל במופע של Agent Platform Workbench

הבעיה

אם אתם לא מצליחים לגשת לטרמינל או לא מוצאים את חלון הטרמינל במרכז האפליקציות, יכול להיות שהגישה לטרמינל לא מופעלת במכונה של Agent Platform Workbench.

הפתרון

אתם צריכים ליצור מכונה חדשה של Agent Platform Workbench עם האפשרות Terminal access. אי אפשר לשנות את האפשרות הזו אחרי שיוצרים את המכונה.

שגיאה 502 כשפותחים את JupyterLab

הבעיה

שגיאת 502 יכולה להצביע על כך שהמכונה של Agent Platform Workbench עדיין לא מוכנה.

הפתרון

ממתינים כמה דקות, מרעננים את הכרטיסייה של מסוף Google Cloud בדפדפן ומנסים שוב.

ה-Notebook לא מגיב

הבעיה

ה-Agent Platform Workbench instance לא מריץ תאים או שהוא תקוע.

הפתרון

קודם כל, נסו להפעיל מחדש את הליבה: בתפריט העליון, לוחצים על Kernel ואז על Restart Kernel. אם זה לא עובד, אפשר לנסות את הפעולות הבאות:

• מרעננים את דף הדפדפן של JupyterLab. פלט של תאים שלא נשמר לא נשאר, ולכן צריך להריץ את התאים האלה שוב כדי ליצור מחדש את הפלט.
• אפס את המופע שלך.

לא ניתן להתחבר למכונה של Agent Platform Workbench באמצעות SSH

הבעיה

אתם לא מצליחים להתחבר למכונה באמצעות SSH דרך חלון הטרמינל.

במכונות של Agent Platform Workbench, הגישה ל-SSH מתבצעת באמצעות OS Login. כשיוצרים מכונה, כברירת מחדל, Agent Platform Workbench מפעיל את OS Login על ידי הגדרת מפתח המטא-נתונים enable-oslogin לערך TRUE. אם אתם לא מצליחים להשתמש ב-SSH כדי להתחבר למכונה, יכול להיות שצריך להגדיר את מפתח המטא-נתונים הזה לערך TRUE.

הפתרון

אי אפשר להתחבר למכונה של Agent Platform Workbench באמצעות מסוף Google Cloud . אם אתם לא מצליחים להתחבר למכונה באמצעות SSH דרך חלון הטרמינל, נסו את הפתרונות הבאים:

כדי להגדיר את מפתח המטא-נתונים enable-oslogin לערך TRUE, משתמשים ב-method‏ projects.locations.instances.patch ב-Notebooks API או בפקודה gcloud workbench instances update ב-Agent Platform SDK.

חרגת ממכסת ה-GPU

הבעיה

אי אפשר ליצור מכונה של Agent Platform Workbench עם מעבדי GPU.

הפתרון

כדי לדעת כמה מעבדי GPU זמינים בפרויקט, בודקים את דף המכסות. אם יחידות ה-GPU לא מופיעות בדף המכסות, או אם אתם צריכים מכסה נוספת, אתם יכולים לבקש הגדלה של המכסה ליחידות ה-GPU ב-Compute Engine. איך מבקשים להגדיל את המכסות

יצירת מכונות של Agent Platform Workbench

בקטע הזה מוסבר איך לפתור בעיות שקשורות ליצירת מכונות של Agent Platform Workbench.

המכונה נשארת במצב המתנה ללא הגבלת זמן או תקועה בסטטוס הקצאה

הבעיה

אחרי שיוצרים מכונה של Agent Platform Workbench, היא נשארת במצב המתנה ללא הגבלת זמן. יכול להיות שתופיע שגיאה כמו זו ביומנים של היציאה הטורית:

Could not resolve host: notebooks.googleapis.com

אם המכונה תקועה בסטטוס הקצאה, יכול להיות שהגדרת הרשת הפרטית של המכונה לא תקינה.

הפתרון

טיפ: אתם יכולים להשתמש ב-gcpdiag כדי לחקור מכונה שנתקעה בסטטוס הקצאה.

פועלים לפי השלבים בקטע ביומני המכונה מוצגות שגיאות חיבור או זמן קצוב לתפוגה.

לא ניתן ליצור מכונה ברשת VPC משותפת

הבעיה

אם תנסו ליצור מכונה ברשת VPC משותפת, תופיע הודעת שגיאה כמו זו:

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

הפתרון

הבעיה היא שחשבון השירות של Notebooks מנסה ליצור את המכונה בלי ההרשאות המתאימות.

כדי לוודא שלחשבון השירות של Notebooks יש את ההרשאות שנדרשות ליצירת מכונה של Agent Platform Workbench ברשת VPC משותפת, צריך לבקש מהאדמין לתת לחשבון השירות של Notebooks את התפקיד Compute Network User ‏ (roles/compute.networkUser) בפרויקט המארח.

חשוב: צריך להקצות את התפקיד הזה לחשבון השירות של Notebooks, ולא לחשבון המשתמש שלכם. אם לא תקצו את התפקיד לחשבון המשתמש הנכון, יכול להיות שתקבלו שגיאות הרשאה.

כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

זהו תפקיד מוגדר מראש שכולל את ההרשאות שנדרשות כדי לוודא שחשבון השירות של Notebooks יכול ליצור מכונה של Agent Platform Workbench ברשת VPC משותפת. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי לוודא שחשבון השירות של Notebooks יכול ליצור מכונה של Agent Platform Workbench ברשת VPC משותפת, צריך את ההרשאות הבאות:

• כדי להשתמש ברשתות משנה: compute.subnetworks.use

יכול להיות שהאדמין יוכל גם להעניק לחשבון השירות של Notebooks את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

לא ניתן ליצור מכונה של Agent Platform Workbench עם קונטיינר בהתאמה אישית

הבעיה

אי אפשר להשתמש בקונטיינר בהתאמה אישית כשיוצרים מכונה של Agent Platform Workbench במסוף Google Cloud .

הפתרון

אי אפשר להוסיף קונטיינר בהתאמה אישית למכונה של Agent Platform Workbench, ואי אפשר להוסיף קונטיינר בהתאמה אישית באמצעות מסוף Google Cloud .

מומלץ להוסיף סביבת conda במקום להשתמש בקונטיינר בהתאמה אישית.

אפשר להוסיף קונטיינר בהתאמה אישית למכונה של Agent Platform Workbench באמצעות Notebooks API, אבל היכולת הזו לא נתמכת.

לא הצלחתי להשתמש ב-Gemini CLI

הבעיה

המשבצת של Gemini CLI נמצאת במרכז האפליקציות של JupyterLab ונפתחת, אבל Gemini לא מגיב להנחיות.

הפתרון

יכול להיות שאדמין חסם את הגישה ל-Gemini CLI. איך שולטים בגישה ל-Gemini CLI

הכפתור "טעינת נפח אחסון משותף" לא מופיע

הבעיה

הלחצן Mount shared storage לא מופיע בכרטיסייה File Browser בממשק של JupyterLab.

הפתרון

כדי שהלחצן Mount shared storage יופיע בממשק JupyterLab של מכונת Agent Platform Workbench, צריך את ההרשאה storage.buckets.list. בקשו מהאדמין לתת לחשבון השירות של מכונת Agent Platform Workbench את ההרשאה storage.buckets.list בפרויקט.

שגיאה 599 כשמשתמשים ב-Managed Service for Apache Spark

הבעיה

אם תנסו ליצור מכונה שמופעל בה 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, מוסיפים רשומה של Cloud DNS לדומיין *.googleusercontent.com.

לא ניתן להתקין תוסף JupyterLab של צד שלישי

הבעיה

אם מנסים להתקין תוסף JupyterLab של צד שלישי, מופיעה ההודעה Error: 500.

הפתרון

תוספים של צד שלישי ל-JupyterLab לא נתמכים במכונות של Agent Platform Workbench.

אי אפשר לערוך את המכונה הווירטואלית הבסיסית

הבעיה

כשמנסים לערוך את המכונה הווירטואלית (VM) הבסיסית של מכונה ב-Agent Platform Workbench, יכול להיות שתופיע הודעת שגיאה דומה לזו:

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

הפתרון

השגיאה הזו מתרחשת כי אי אפשר לערוך את ה-VM הבסיסי של מכונה באמצעות מסוף Google Cloud או Compute Engine API.

כדי לערוך את המכונה הווירטואלית הבסיסית של מכונת Agent Platform Workbench, משתמשים ב-method‏ projects.locations.instances.patch ב-Notebooks API או בפקודה gcloud workbench instances update ב-Agent Platform SDK.

חבילות pip לא זמינות אחרי הוספת סביבת conda

הבעיה

חבילות pip לא זמינות אחרי שמוסיפים קרנל שמבוסס על conda.

הפתרון

כדי לפתור את הבעיה, נסו את הפתרונות הבאים, שמופיעים במאמר הוספת סביבת conda:

• מוודאים שהשתמשתם במשתנה DL_ANACONDA_ENV_HOME ושהוא מכיל את שם הסביבה.

• מוודאים שהקובץ pip נמצא בנתיב שדומה ל-opt/conda/envs/ENVIRONMENT/bin/pip. כדי לקבל את הנתיב, אפשר להריץ את הפקודה which pip.

לא ניתן לגשת לנתונים של מכונה עם גישה למשתמש יחיד או להעתיק אותם

הבעיה

אי אפשר לגשת לנתונים במכונה עם גישה למשתמש יחיד.

במכונות של Agent Platform Workbench שמוגדרות עם גישה למשתמש יחיד, רק המשתמש היחיד שצוין (הבעלים) יכול לגשת לנתונים במכונה.

הפתרון

כדי לגשת לנתונים או להעתיק אותם כשאתם לא הבעלים של המכונה, פתחו בקשת תמיכה.

כיבוי לא צפוי

הבעיה

מכונת Agent Platform Workbench מושבתת באופן לא צפוי.

הפתרון

אם המכונה שלכם נכבית באופן בלתי צפוי, יכול להיות שזה בגלל שהופעלה השבתה במצב חוסר פעילות.

אם הפעלתם את ההשבתה במצב חוסר פעילות, המכונה תושבת כשלא תהיה פעילות ליבה (kernel) במשך פרק הזמן שצוין. לדוגמה, הפעלת תא או הדפסת פלט חדש ל-notebook היא פעילות שמאפסת את טיימר הזמן הקצוב לתפוגה במצב חוסר פעילות. השימוש במעבד (CPU) לא מאפס את הטיימר של הזמן הקצוב לתפוגה במצב חוסר פעילות.

ביומני המכונה מופיעות שגיאות חיבור או שגיאות של זמן קצוב לתפוגה

הבעיה

ביומנים של המכונה של Agent Platform Workbench מופיעות שגיאות שקשורות לחיבור או לזמן הקצוב לתפוגה.

הפתרון

אם אתם מבחינים בשגיאות חיבור או בשגיאות של זמן קצוב לתפוגה ביומנים של המכונה, ודאו ששרת Jupyter פועל ביציאה 8080. פועלים לפי השלבים בקטע אימות שה-API הפנימי של Jupyter פעיל.

אם השבתתם את External IP ואתם משתמשים ברשת VPC פרטית, ודאו שפעלתם לפי המסמכים בנושא אפשרויות להגדרת הרשת. כמה נקודות שכדאי לחשוב עליהן:

• צריך להפעיל את "גישה פרטית ל-Google" ברשת המשנה שנבחרה באותו אזור שבו נמצא המכונה בפרויקט המארח של ה-VPC. מידע נוסף על הגדרת גישה פרטית ל-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 נוצר עם כתובת ה-IP‏ 172.17.0.1/16. יכול להיות שהמצב הזה יתנגש עם כתובות ה-IP ברשת ה-VPC, כך שהמכונה לא תוכל להתחבר לנקודות קצה אחרות עם כתובות 172.17.0.1/16.

הפתרון

כדי לאלץ את הממשק docker0 להיווצר עם כתובת IP שלא מתנגשת עם רשת ה-VPC, אתם יכולים להשתמש בסקריפט לטעינה בזמן ההפעלה הבא ולהגדיר את ההתנהגות של הסקריפט לטעינה בזמן ההפעלה ל-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

ההזמנות שצוינו לא קיימות

הבעיה

הפעולה ליצירת המכונה גורמת להודעת השגיאה 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 מינימלית. אם בהזמנה מוגדרת פלטפורמה ספציפית, צריך להגדיר את min_cpu_platform בהתאם כשיוצרים מכונות של Agent Platform Workbench.
• במכונות של Agent Platform Workbench, מספר כונני ה-SSD המקומיים תמיד מוגדר לערכי ברירת המחדל בהתאם לסוג המכונה. לדוגמה, ל-a2-ultragpu-1g תמיד יש כונן 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: מזהה הפרויקט
• ‫ZONE: האזור ( Google Cloud ) שבו נמצאת המכונה
• ‫INSTANCE_NAME: השם של המכונה

אפשר גם להתחבר למכונה על ידי פתיחת דף הפרטים של המכונה ב-Compute Engine, ואז לחיצה על הלחצן SSH.

טיפ: אם אתם לא מצליחים להשתמש ב-SSH כדי להתחבר למכונה, אתם יכולים להשתמש ב-gcpdiag כדי לפתור את הבעיה

רישום מחדש בשרת Inverting Proxy

כדי לרשום מחדש את המכונה של Agent Platform Workbench בשרת proxy הפנימי של 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 של ה-Notebook פועל, השתמשו ב-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

מוודאים שה-API הפנימי של Jupyter פעיל

‫Jupyter API צריך תמיד לפעול ביציאה 8080. כדי לוודא שהמכונה הופעלה מחדש, אפשר לבדוק אם ביומני המערכת של המכונה מופיעה רשומה שדומה לזו:

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

כדי לוודא שה-API הפנימי של Jupyter פעיל, אתם יכולים גם להשתמש ב-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, אפשר לעצור ולהפעיל את המכונה הווירטואלית מדף המכונות, או להשתמש ב-SSH כדי להתחבר למכונה של Agent Platform Workbench ולהזין:

sudo docker restart proxy-agent

הפעלה מחדש של שירות Jupyter

כדי להפעיל מחדש את שירות Jupyter, אתם יכולים לעצור ולהפעיל את המכונה הווירטואלית מדף המכונות, או להשתמש ב-SSH כדי להתחבר למכונה של Agent Platform Workbench ולהזין:

sudo service jupyter restart

הפעלה מחדש של סוכן האיסוף של Notebooks

השירות Notebooks Collection Agent מריץ ברקע תהליך Python שמאמת את הסטטוס של שירותי הליבה של המכונה של Agent Platform Workbench.

כדי להפעיל מחדש את שירות Notebooks Collection Agent, אתם יכולים לעצור ולהפעיל את המכונה הווירטואלית מGoogle Cloud מסוף או להשתמש ב-SSH כדי להתחבר למכונה של Agent Platform Workbench ולהזין:

sudo systemctl stop notebooks-collection-agent.service

ואז:

sudo systemctl start notebooks-collection-agent.service

כדי להריץ את הפקודות האלה במכונה של Agent Platform Workbench, פותחים את JupyterLab ויוצרים טרמינל חדש.

שינוי הסקריפט של סוכן האיסוף של Notebooks

הערה: אל תשנו את הסקריפט של סוכן איסוף הנתונים של Notebooks, אלא אם צריך לפתור בעיה במכונה.

כדי לגשת לסקריפט ולערוך אותו, פותחים טרמינל במכונה או משתמשים ב-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 בשם קטגוריה שעומד בקריטריונים לשמות של קטגוריות.

העתקת נתוני המשתמשים

1. בממשק JupyterLab של המכונה, לוחצים על File > New > Terminal כדי לפתוח את חלון הטרמינל. במכונות של Agent Platform Workbench, אתם יכולים להתחבר למסוף של המכונה באמצעות SSH.

2. משתמשים ב-ה-CLI של gcloud כדי להעתיק את נתוני המשתמשים לקטגוריה של Cloud Storage. פקודת הדוגמה הבאה מעתיקה את כל הקבצים מהספרייה /home/jupyter/ של המכונה לספרייה בקטגוריה של Cloud Storage.

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

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BUCKET_NAME: השם של הקטגוריה ב-Cloud Storage
   • ‫PATH: הנתיב לספרייה שאליה רוצים להעתיק את הקבצים, לדוגמה: /copy/jupyter/

איך משתמשים ב-gcpdiag כדי לבדוק מכונה שנתקעה בהקצאה

הערה: כשמשתמשים בפלטפורמת הסוכנים עם גישה פרטית ל-Google כדי לגשת לממשקי API של Google Cloudולשרתי proxy לאינטרנט לצורך גישה יוצאת, צריך להגדיר את המכונות כך שיעקפו את שרתי ה-proxy לאינטרנט או מכשירים אחרים לבדיקה או לסינון של תנועה ברשת (לדוגמה, חומות אש מהדור הבא) לכל שם מארח בדומיינים שמפורטים במסמכי התיעוד של גישה פרטית ל-Google.

‫gcpdiag הוא כלי בקוד פתוח. זה לא מוצר של Google Cloud שנתמך באופן רשמי. אתם יכולים להשתמש בכלי gcpdiag כדי לזהות ולתקן בעיות בפרויקט Google Cloud. מידע נוסף זמין בפרויקט gcpdiag ב-GitHub.

במדריך ההפעלה הזה של gcpdiag נבדקות סיבות אפשריות לכך שמכונה של Agent Platform Workbench נתקעת בסטטוס הקצאת משאבים, כולל התחומים הבאים:

• ‫Status: בדיקת הסטטוס הנוכחי של המכונה כדי לוודא שהיא תקועה בהקצאה ולא נעצרה או פעילה.
• תמונת דיסק האתחול של המכונה הווירטואלית ב-Compute Engine: בודקת אם המכונה נוצרה עם קונטיינר בהתאמה אישית, תמונה רשמית של workbench-instances, תמונות VM של למידה עמוקה (Deep Learning) או תמונות לא נתמכות שעלולות לגרום למכונה להיתקע בסטטוס הקצאה.
• סקריפטים מותאמים אישית: בדיקה אם המכונה משתמשת בסקריפטים לטעינה בזמן ההפעלה או לאחר ההפעלה, שמשנים את יציאת ברירת המחדל של Jupyter או משבשים יחסי תלות שעלולים לגרום למכונה להיתקע בסטטוס הקצאה.
• גרסת הסביבה: בדיקה אם המכונה משתמשת בגרסת הסביבה העדכנית ביותר, על ידי בדיקת האפשרות לשדרוג. גרסאות קודמות עלולות לגרום למכונה להיתקע בסטטוס הקצאה.
• ביצועי המכונה הווירטואלית של המכונה ב-Compute Engine: בדיקת הביצועים הנוכחיים של המכונה הווירטואלית כדי לוודא שהם לא נפגעים משימוש גבוה במעבד (CPU), מזיכרון לא מספיק או מבעיות במקום בכונן שעלולות לשבש את הפעולות הרגילות.
• היציאה הטורית של המכונה ב-Compute Engine או רישום ביומן המערכת: בדיקה אם למכונה יש יומנים של היציאה הטורית, שמנותחים כדי לוודא ש-Jupyter פועל ביציאה 127.0.0.1:8080.
• גישה ל-SSH ולטרמינל של Compute Engine במכונה: בדיקה אם המכונה הווירטואלית של Compute Engine פועלת, כדי שהמשתמש יוכל להשתמש ב-SSH ולפתוח טרמינל כדי לוודא שהשימוש בנפח האחסון ב-"home/jupyter" נמוך מ-85%. אם לא נשאר מקום, יכול להיות שהמכונה תיתקע בסטטוס הקצאה.
• ‫External IP turned off: בדיקה אם הגישה לכתובת IP חיצונית מושבתת. הגדרה שגויה של הרשת עלולה לגרום למכונה להיתקע בסטטוס הקצאה.

Docker

אתם יכולים להריץ את gcpdiag באמצעות wrapper שמפעיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.

1. מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית.

   curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag

2. מפעילים את הפקודה gcpdiag.

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

הפרמטרים הזמינים למדריך ההפעלה הזה.

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: מזהה הפרויקט שמכיל את המשאב.
• ‫INSTANCE_NAME: השם של מכונת היעד של Agent Platform Workbench בפרויקט.
• ‫ZONE: האזור שבו נמצאת מכונת היעד של Agent Platform Workbench.

דגלים שימושיים:

• ‫--universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב
• ‫--parameter או -p: פרמטרים של מדריך הפעלה

רשימה ותיאור של כל הדגלים של הכלי 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. למידע נוסף, קראו את מסמכי התיעוד של IAM לשירותי Agent Platform שבהם אתם משתמשים, וגם את כל שילובי המוצרים האחרים שבהם אתם משתמשים.

• אם נתתם לחשבון שירות הרשאות בכמה פרויקטים, אתם יכולים לאפשר צירוף של חשבונות שירות בין פרויקטים. כדי לעשות את זה, צריך לוודא ש-iam.disableCrossProjectServiceAccountUsage. לא נאכף. כדי לוודא שהמדיניות iam.disableCrossProjectServiceAccountUsage לא נאכפת, מריצים את הפקודה הבאה:

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