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

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 כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud

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
הגבלת קצב בקשות (rate limiting) שגויה ב-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 בודקת עלייה בתדירות של דוחות על חריגות תרמיות ב-GPUs שלא מראים סימנים לבעיות תרמיות בפועל.
• המלצה: לפני שמדווחים על מארח כפגום בגלל אזהרות על חום, כדאי לבדוק אם הטמפרטורות בפועל של ה-GPU חורגות מספיק מהסף הבטוח, ואם הביצועים של עומס העבודה מושפעים. אם הטמפרטורות נשארות יציבות והביצועים תקינים, מומלץ לעקוב אחרי ה-GPU במקום לדווח על תקלה.

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

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

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

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

   למידע נוסף, ראו הצגת הטופולוגיה של מופע Compute.

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

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

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

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

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

   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: האזור שבו קיימת מכונת החישוב.

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

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

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

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

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

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 של מארח פגום.