דיווח על מארח עם תקלה

Clustered GPUs

אם אתם מזהים בעיה במופע A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (8 GPUs) שאתם לא יכולים לפתור בעצמכם, אתם יכולים לדווח על המארח שלו כפגום. דוגמה לבעיה כזו יכולה להיות ביצועים איטיים יותר באשכול, או טמפרטורות גבוהות באופן עקבי של ה-GPU.

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

• במקרים של מכונות A4 ו-A3 Ultra, מערכת Compute Engine מנסה להעביר את המכונה למארח אחר כשהתחזוקה מתחילה, אם יש לכם קיבולת שמורה לא בשימוש או קיבולת זמינה באזור של המכונה. דיווח על מארח כפגום עוזר לצמצם את זמן ההשבתה של עומס העבודה.
• במכונות מסוג A3 Mega ו-A3 High,‏ Compute Engine מפסיק את המכונה, מבצע את התיקונים הנדרשים במארח ואז מפעיל מחדש את המכונה באותו מארח.

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

במאמר הזה מוסבר איך לדווח על מקרים של מכונות מארחות פגומות שמשמשות כחלק מאשכול Slurm או מאשכולות אחרים שמבוססים על מכונות וירטואליות, ואיך לתקן אותן. כדי לדווח על מארחים פגומים באשכול Google Kubernetes Engine ‏ (GKE), אפשר לעיין במאמר דיווח על מארחים פגומים דרך GKE.

הערה: מעבדים גרפיים כלליים לא תומכים בדיווח על מארחים פגומים. אם נתקלתם בבעיות בחומרה של מכונת GPU לשימוש כללי, אתם יכולים להשתמש בתיקון אוטומטי רגיל של צומת GKE או לפנות אל Cloud Customer Care.

זהירות: דיווח על מארח פגום היא פעולה שגורמת לשיבוש ולהפסקת פעולת מכונת ה-VM. לפני שמדווחים על מארח, חשוב לחקור ביסודיות את הסביבה כדי לזהות את שורש הבעיה. אפשר לדווח על המארח כפגום רק אם אין לכם אפשרויות אחרות לפתרון הבעיה.

מגבלות

כשמדווחים על מארח עם בעיה, חלות המגבלות הבאות:

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

  • מופע המחשוב פועל.

  • מופע המחשוב משתמש בסוג מכונה A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (8 GPUs).

  • מופע המחשוב משתמש במודל הקצאת משאבים שמוגבל למקום שמור.

    הערה: אם מופעלת מכונה מסוג A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (עם 8 יחידות GPU) שמשתמשת במודל הקצאה שונה, אבל אתם עדיין רוצים לדווח על המארח שלה כפגום, עליכם לפנות לצוות ניהול החשבון.

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

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

לפני שמתחילים

צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

המסוף

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

REST

כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות בשביל לדווח על מארח פגום, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) במכונת Compute או בפרויקט
• כדי לראות את הסטטוס של פעולת דיווח על מארח פגום באמצעות Cloud Logging: מציג היומנים (roles/logging.viewer) בפרויקט

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

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

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

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

• כדי ליצור דוח על מארח פגום: compute.instances.update במכונת החישוב
• כדי לראות רשימה של פעולות באמצעות Logging: logging.operations.list בפרויקט
• כדי לראות את פרטי הפעולה באמצעות Logging: logging.operations.get בפרויקט
• כדי לראות רשימה של פעולות ב-Compute Engine: compute.zoneOperations.list בפרויקט
• כדי לראות את פרטי הפעולה ב-Compute Engine: compute.zoneOperations.describe בפרויקט

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

הסבר על תהליך הדיווח על מארח פגום

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

	מצב קיבולת מלאה (ALL_CAPACITY)	מצב מנוהל (HIGHLY_AVAILABLE_CAPACITY)
סוגי מכונות נתמכים	‫A4X Max ו-A4X	‫A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High
הגבלת קצב בקשות שגויה של API לדוחות מארחים	אין הגבלות על קצב יצירת הבקשות.	יכול להיות שיהיו הגבלות על קצב הקריאות ל-API.
תהליך דיווח על מארח פגום	כשמדווחים על מארח פגום עבור מופע של Compute שפועל במצב 'כל הקיבולת', קורה הדבר הבא: דיווח על מארח פגום: המופע נשאר במצב RUNNING במהלך הפעולה של דיווח על מארח פגום, שבדרך כלל נמשכת 10-12 דקות. כדי לבדוק את מצב הפעולה, אפשר לעיין בקטע בדיקת פעולות מארח פגומות בדוח במסמך הזה. תיקון המארח: אחרי שהדוח על פעולת המארח הפגומה מסתיים, פעולת התיקון של המארח מתחילה תוך דקה. כשמתחילים את פעולת התיקון של המארח, המופע נעצר והמצב שלו משתנה בהתאם להגדרה הפעלה מחדש אוטומטית (automaticRestart) שצוינה עבור המופע: אם ההפעלה מחדש האוטומטית מופעלת עבור המופע, מצב המופע משתנה ל-REPAIRING. המכונה מופעלת מחדש באופן אוטומטי כשהמארח שלה תקין, אלא אם מפסיקים את המכונה לפני כן. אם ההפעלה האוטומטית מחדש מושבתת עבור המכונה, מצב המכונה משתנה ל-TERMINATED. צריך להפעיל מחדש את המופע באופן ידני אחרי שהמארח שלו תקין. תיקון המארח הפגום יכול להימשך 3-14 ימים, ולפעמים אפילו יותר. הפעלה מחדש של המופע: אחרי שפעולת התיקון של המארח מסתיימת (בדרך כלל תוך 3-14 ימים), אחד מהדברים הבאים קורה: אם המופע במצב REPAIRING והמשאבים זמינים כשהתיקון מסתיים, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח המתוקן. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים כשהתיקון מסתיים, מצב המופע נשאר או משתנה לTERMINATED. תצטרכו להפעיל מחדש את המופע באופן ידני כשתרצו שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.	כשמדווחים על מארח פגום עבור מופע של Compute שפועל במצב מנוהל, קורה הדבר הבא: דיווח על מארח פגום: המופע נשאר במצב RUNNING במהלך הפעולה 'דיווח על מארח פגום', שבדרך כלל נמשכת 10-12 דקות. כדי לבדוק את מצב הפעולה, אפשר לעיין בקטע בדיקת פעולות מארח פגומות בדוח במסמך הזה. מתחילים לתקן את המארח: אחרי שהדוח על פעולת המארח הפגומה מסתיים, פעולת התיקון של המארח מתחילה תוך דקה. כשמתחילים את פעולת התיקון של המארח, המופע נעצר והמצב שלו משתנה בהתאם להגדרה הפעלה מחדש אוטומטית (automaticRestart) שצוינה עבור המופע: אם ההפעלה מחדש האוטומטית מופעלת עבור המופע, מצב המופע משתנה ל-REPAIRING. המכונה מופעלת מחדש באופן אוטומטי כשהמארח שלה תקין, אלא אם מפסיקים את המכונה לפני כן. אם ההפעלה האוטומטית מחדש מושבתת עבור המכונה, מצב המכונה משתנה ל-TERMINATED. צריך להפעיל מחדש את המופע באופן ידני אחרי שהמארח שלו תקין. תיקון המארח הפגום יכול להימשך 3-14 ימים, ולפעמים אפילו יותר. העברה והפעלה מחדש של המכונה: אחרי שפעולת התיקון של המארח מתחילה (בדרך כלל תוך 10-12 דקות), מערכת Compute Engine מנסה לשריין עוד מארח אחד כדי להחליף את המארח הפגום שדווח בקיבולת השמורה. אם Compute Engine מוצא מארח תקין – אם הוא מחליף בהצלחה את המארח הפגום או מוצא מארח תקין תואם בקיבולת השמורה שלכם – אז Compute Engine מעביר את המופע למארח הזה. לאחר מכן, מפעילים מחדש את המופע באחת מהדרכים הבאות: אם המופע במצב REPAIRING והמשאבים זמינים לפני או בזמן השלמת התיקון, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח תקין. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי השלמת התיקון, מצב המופע נשאר או משתנה לTERMINATED. תצטרכו להפעיל מחדש את המופע באופן ידני כשתרצו שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.

פתרון בעיות לפני דיווח על מארח פגום

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

בדיקה של בעיות בביצועים של ה-GPU ושל חריגים

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

מעקב אחרי טמפרטורות של GPU והפרות תרמיות

אם אתם רואים אזהרות על הפרות של תנאי השימוש בנושא טמפרטורה ביומנים או בדוחות של DCGM, כדאי לעיין בהנחיות הבאות:

• אזהרות לעומת שגיאות קריטיות: יכול להיות שבדוחות האבחון הנוכחיים של DCGM יופיעו הפרות של סף הטמפרטורה כאזהרות ברמת חומרה של monitor. המשמעות היא שמעבדי ה-GPU עדיין מוכנים להפעלת עומסי עבודה, אבל צריך לעקוב אחריהם.
• תוצאות חיוביות כוזבות: NVIDIA בודקת עלייה בתדירות של דוחות על חריגות תרמיות ב-GPU שלא מראים סימנים לבעיות תרמיות בפועל.
• המלצה: לפני שמדווחים על מארח כפגום בגלל אזהרות על חום, כדאי לבדוק אם הטמפרטורות בפועל של ה-GPU חורגות מספיק מהסף הבטוח, ואם הביצועים של עומס העבודה מושפעים. אם הטמפרטורות נשארות יציבות והביצועים תקינים, מומלץ לעקוב אחרי ה-GPU במקום לדווח עליו כעל רכיב פגום.

מידע נוסף על פתרון בעיות ב-GPU זמין במאמר פתרון בעיות במכונות וירטואליות עם GPU במאמרי העזרה של Compute Engine.

דיווח על מארח עם בעיה

כדי לדווח על מארח פגום, פועלים לפי השלבים הבאים:

1. בדיקת המארח שבו פועל מופע החישוב

   הוראות מפורטות מופיעות במאמר הצגת הטופולוגיה של מופע Compute.

2. אופציונלי: גיבוי נתונים ב-SSD מקומי. כשמפסיקים את המכונה, Compute Engine משליך באופן אוטומטי את הנתונים של כל דיסקי ה-SSD המקומיים שמצורפים למכונה. אי אפשר לשחזר נתונים של Local SSD אחרי ש-Compute Engine משליך אותם.

   הוראות לשמירת נתונים ב-SSD מקומי מופיעות במאמר גיבוי נתונים ב-SSD מקומי.

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

   חשוב: אחרי שמדווחים על מארח כפגום, לא שולחים בקשות נוספות עד שהפעולה מסתיימת. ‫Compute Engine דוחה בקשות נוספות בזמן שהפעולה מתבצעת.

   gcloud

   כדי לדווח על מארח פגום, משתמשים בפקודה gcloud compute instances report-host-as-faulty הבאה:

   gcloud compute instances report-host-as-faulty INSTANCE_NAME \
       --async \
       --disruption-schedule=IMMEDIATE \
       --fault-reasons=behavior=FAULT_REASON,description=DESCRIPTION \
       --zone=ZONE
   

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

   • ‫INSTANCE_NAME: השם של מכונת ה-Compute.

   • ‫FAULT_REASON: רשימה מופרדת בפסיקים של בעיות במארח שנתקל בהן מופע המחשוב, למשל, ISSUE_1,ISSUE_2. אפשר לציין את הערכים הבאים:

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

     • ‫SILENT_DATA_CORRUPTION: נתונים פגומים מופיעים במכונה, אבל המכונה ממשיכה לפעול. פגם שקט בנתונים יכול לנבוע מבעיות כמו פגמים במעבדי vCPU, באגים בתוכנה או בעיות בקרנל.

     • ‫UNRECOVERABLE_GPU_ERROR: זיהיתם שגיאת GPU שלא ניתן לשחזר עם XID.

     • ‫BEHAVIOR_UNSPECIFIED: אתם לא בטוחים מה הבעיה במופע המחשוב.

   • ‫DESCRIPTION: תיאור של הבעיה שמשפיעה על מופע המחשוב, כמו מידע על XID או בעיות ביצועים שמעוררות חשד.

   • ‫ZONE: האזור שבו קיימת מכונת ה-Compute.

   REST

   כדי לדווח על מארח פגום, שולחים את בקשת POST ל-method‏ instances.reportHostAsFaulty.

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

   POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME/reportHostAsFaulty
   
   {
     "disruptionSchedule": "IMMEDIATE",
     "faultReasons": [
       {
         "behavior": "FAULT_REASON_1",
         "description": "DESCRIPTION_1"
       },
       {
         "behavior": "FAULT_REASON_2",
         "description": "DESCRIPTION_2"
       }
     ]
   }
   

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

   • ‫PROJECT_ID: מזהה הפרויקט שבו קיימת מכונת ה-Compute.

   • ‫ZONE: האזור שבו קיימת מכונת ה-Compute.

   • ‫INSTANCE_NAME: השם של מכונת ה-Compute.

   • ‫FAULT_REASON_1 ו-FAULT_REASON_2: כל בעיה במארח שמופע המחשוב נתקל בה. אפשר לציין את הערכים הבאים:

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

     • ‫SILENT_DATA_CORRUPTION: נתונים פגומים מופיעים במכונה, אבל המכונה ממשיכה לפעול. פגם שקט בנתונים יכול לנבוע מבעיות כמו פגמים במעבדי vCPU, באגים בתוכנה או בעיות בקרנל.

     • ‫UNRECOVERABLE_GPU_ERROR: זיהיתם שגיאת GPU שלא ניתן לשחזר עם XID.

     • ‫BEHAVIOR_UNSPECIFIED: אתם לא בטוחים מה הבעיה במופע המחשוב.

   • ‫DESCRIPTION_1 ו-DESCRIPTION_2: תיאור של כל בעיה במארח שציינתם, כמו מידע על XID או בעיות ביצועים שאתם חושדים בהן.

בדיקת פעולות מארח שגויות בדוח

אחרי שמדווחים על מארח פגום, Compute Engine מתחיל סדרה של פעולות כדי לסמן את המארח כפגום ולהכין אותו לתיקון. באופן ספציפי, במהלך דיווח על פעולה פגומה של מארח, מתרחש התהליך הבא:

1. סימון המארח כפגום. ‫Compute Engine יוצר את הדוח faulty host operation. הפעולה report faulty host יוצרת רצף של פעולות משנה. פעולות המשנה האלה מסמנות את המארח הבסיסי כפגום.

2. הכנת המארח לתיקונים אחרי שכל פעולות המשנה מסתיימות, מתחילה הפעולה report faulty host. מערכת Compute Engine מפסיקה את מכונת החישוב ומתחילה את פעולת התיקון של המארח הפגום. בהתאם למצב ההפעלה של ההזמנה שצוין בהזמנה שבה נעשה שימוש במופע של Compute, ואם יש מארחים תקינים זמינים, מערכת Compute Engine משאירה את המופע של Compute במצב מושבת או מנסה להעביר אותו באופן אוטומטי ולהפעיל אותו מחדש.

3. השלמת הדיווח ותיקון המארח מערכת Compute Engine משלימה את הפעולה של דיווח על מארח פגום, והפעולה של תיקון המארח מופעלת.

כדי לעקוב אחרי הסטטוס של פעולות הדיווח על מארח פגום (compute.instances.reportHostAsFaulty) בפרויקט, בוחרים באחת מהאפשרויות הבאות. מידע נוסף על פעולות אחרות שאפשר להשתמש בהן כדי לעקוב אחרי תיקונים, העברות והפעלה מחדש אוטומטית זמין במאמרים התנהגויות של תחזוקה והפעלה מחדש ומעקב ותכנון של אירוע תחזוקה של מארח במסמכי התיעוד של Compute Engine.

מסוף (פעולות במופע)

1. נכנסים לדף Operations במסוף Google Cloud .

   מעבר אל 'פעולות'

2. בטבלה שמופיעה, מאתרים את מופע המחשוב שדיווחתם עליו.

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

4. אופציונלי: כדי לוודא שמכונת החישוב הופעלה מחדש על ידי Compute Engine, צופים בפרטי המכונה.

המסוף (יומנים של מופע Compute)

1. נכנסים לדף Logs Explorer במסוף Google Cloud .

   כניסה לדף Logs Explorer

2. מוודאים שהמתג הצגת השאילתה מופעל.

3. בעורך השאילתות, מזינים את השאילתה הבאה:

   resource.type="gce_instance" AND protoPayload.methodName=~"compute\.instances\.reportHostAsFaulty"
   

4. לוחצים על Run query. בחלונית Query results מוצגות תוצאות השאילתה.

gcloud

1. כדי לראות את הסטטוס של פעולות המארח הפגומות בדוח בפרויקט, משתמשים בפקודה gcloud compute operations list עם הדגל --filter שמוגדר לערך operationType:reportHostAsFaulty:

   gcloud compute operations list --filter="operationType:reportHostAsFaulty"
   

2. כדי לראות את הפרטים של פעולה ספציפית של מארח עם שגיאה, משתמשים בפקודה gcloud compute operations describe:

   gcloud compute operations describe OPERATION_NAME \
       --zone="ZONE"
   

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

   • ‫OPERATION_NAME: שם הפעולה.

   • ‫ZONE: האזור שבו הפעולה מתבצעת.

REST

כדי לראות את הסטטוס של פעולות המארח הפגומות בדוח בפרויקט, שולחים בקשת GET לשיטה zoneOperations.list. בכתובת ה-URL של הבקשה, כוללים את פרמטר השאילתה filter שמוגדר לערך items.operationType:reportHostAsFaulty.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/operations&filter=items.operationType:reportHostAsFaulty

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

• ‫PROJECT_ID: שם הפעולה.

• ‫ZONE: האזור שבו הפעולות מתבצעות.

מה השלב הבא?

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