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

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

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

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

Any Agent Platform Workbench instances

מכונות של 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.
• מתקינים את סוכן התפעול (מומלץ). הפעולה תימשך כמה דקות
• מוסיפים שדה Custom Metadata‏ notebook-enable-debug ומגדירים אותו לערך true.
• מפעילים מחדש את המופע ומשחזרים את הבעיה.
• מפעילים ומגדירים את Cloud Assist Investigations API.
• יוצרים חקירה חדשה ומתארים את הבעיה בפירוט באמצעות הנחיה בשפה טבעית.
• במהלך ההקלדה, תופיע תיבת דו-שיח עם הצעות למשאבים שאפשר להוסיף לחקירה. צריך לעיין ברשימה הזו ולוודא שמוסיפים את המופע כמשאב, וגם את כל המשאבים האחרים ברשימת המוצרים הנתמכים.
• מתחילים בחקירה ובודקים את התוצאות.

פתרון בעיות בקובצי אבחון באמצעות Gemini CLI

אפשר להשתמש בתוצאות של החקירה באמצעות Cloud Assist כדי להנחות חקירה נוספת מבוססת-AI בקובץ האבחון מהמופע.

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

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 עם האפשרות Terminal access (גישה לטרמינל) מופעלת. אי אפשר לשנות את האפשרות הזו אחרי יצירת המופע.

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

בעיה

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

הפתרון

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

ה-Notebook לא מגיב

בעיה

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

הפתרון

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

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

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

בעיה

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

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

הפתרון

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

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

הייתה חריגה מהמכסה של מעבד גרפי

בעיה

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

הפתרון

כדי לדעת כמה יחידות 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 את תפקיד ה-IAM 'משתמש ברשת Compute' (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.

הפתרון

ההרשאה storage.buckets.list נדרשת כדי שהלחצן Mount shared storage יופיע בממשק JupyterLab של מופע Agent Platform Workbench. צריך לבקש מהאדמין להעניק לחשבון השירות של מופע 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, משתמשים בשיטה 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) במשך התקופה שצוינה. לדוגמה, הפעלת תא או הדפסת פלט חדש במחברת היא פעילות שמאפסת את הטיימר של הזמן הקצוב לתפוגה של חוסר פעילות. השימוש במעבד לא מאפס את טיימר הזמן הקצוב לתפוגה של חוסר פעילות.

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

בעיה

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

הפתרון

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

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

• צריך להפעיל גישה פרטית ל-Google ברשת המשנה שנבחרה באותו אזור שבו נמצאת המכונה הווירטואלית בפרויקט המארח של ה-VPC. מידע נוסף על הגדרת גישה פרטית ל-Google זמין במסמכי התיעוד בנושא גישה פרטית ל-Google.

• אם אתם משתמשים ב-Cloud DNS, המופע צריך להיות מסוגל לפתור את הבעיה בדומיינים הנדרשים של Cloud DNS שצוינו במסמכי האפשרויות להגדרת הרשת. כדי לוודא זאת, פועלים לפי השלבים שבקטע אימות האפשרות לפתור את דומייני ה-DNS הנדרשים במופע.

ב-Instance logs מופיעה השגיאה '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 תמיד יש אפס 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 כדי לפתור את הבעיה

רישום מחדש בשרת ה-Proxy ההפוך

כדי לרשום מחדש את מופע Agent Platform Workbench בשרת ה-Inverting Proxy הפנימי, אפשר לעצור ולהפעיל את המכונה הווירטואלית מהדף Instances, או להשתמש ב-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

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

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

sudo docker restart proxy-agent

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

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

sudo service jupyter restart

הפעלה מחדש של סוכן איסוף נתונים של מחברות

שירות 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 Collection Agent

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

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

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

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

Google Cloud

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

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

• סטטוס: בודק את הסטטוס הנוכחי של המופע כדי לוודא שהוא תקוע בהקצאת הרשאות ולא מושבת או פעיל.
• תמונת דיסק האתחול של מכונת ה-VM של Compute Engine של האינסטנס: הבדיקה הזו בודקת אם האינסטנס נוצר באמצעות קונטיינר בהתאמה אישית, תמונה רשמית של workbench-instances, תמונות של מכונות וירטואליות ללמידה עמוקה או תמונות לא נתמכות שעלולות לגרום לאינסטנס להיתקע בסטטוס הקצאה.
• סקריפטים בהתאמה אישית: בדיקה אם המופע משתמש בסקריפטים מותאמים אישית להפעלה או אחרי הפעלה שמשנים את יציאת ברירת המחדל של Jupyter או שוברים תלויות שעלולות לגרום למופע להיתקע בסטטוס הקצאה.
• גרסת הסביבה: המערכת בודקת אם המופע משתמש בגרסה העדכנית ביותר של הסביבה על ידי בדיקת האפשרות לשדרוג. גרסאות קודמות עלולות לגרום למופע להיתקע במצב הקצאה.
• ביצועי המכונה הווירטואלית ב-Compute Engine: הבדיקה הזו בודקת את הביצועים הנוכחיים של המכונה הווירטואלית כדי לוודא שהם לא נפגעים בגלל שימוש גבוה במעבד, זיכרון לא מספיק או בעיות במקום בדיסק שעלולות לשבש את הפעולות הרגילות.
• היציאה הטורית של מכונת Compute Engine או רישום המערכת ביומן: המערכת בודקת אם יש למכונה יומנים של יציאות טוריות, ומנתחת אותם כדי לוודא ש-Jupyter פועל ביציאה 127.0.0.1:8080.
• גישת טרמינל ו-SSH של Compute Engine למכונה: המערכת בודקת אם המכונה הווירטואלית של Compute Engine פועלת, כדי שהמשתמש יוכל להשתמש ב-SSH ולפתוח טרמינל כדי לוודא שהשימוש במקום ב-home/jupyter נמוך מ-85%. אם לא נשאר מקום, יכול להיות שהמופע ייתקע בסטטוס הקצאה.
• כתובת IP חיצונית מושבתת: בדיקה אם הגישה לכתובת 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

הצגת הפרמטרים הזמינים של קובץ ה-runbook הזה.

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

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

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

• ‫--universe-domain: אם רלוונטי, הדומיין של Trusted Partner 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. לקבלת מידע נוסף, כדאי לקרוא את התיעוד של IAM לגבי שירותי Agent Platform שבהם אתם משתמשים, וגם לגבי שילובי מוצרים אחרים שבהם אתם משתמשים.

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

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