פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות ב-Batch.

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

מידע נוסף על פתרון בעיות שקשורות לעבודות זמין גם במאמרים הבאים:

שגיאות ביצירת עבודות

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

חריגה ממכסת הבקשות

שגיאה

אחת מהבעיות הבאות מתרחשת כשמנסים ליצור משרה:

  • כשהעבודה במצב QUEUED, הבעיה הבאה מופיעה בשדה statusEvents:

    Quota checking process decides to delay scheduling for the job JOB_UID due to inadequate quotas [Quota: QUOTA_NAME, limit: QUOTA_LIMIT, usage: QUOTA_CURRENT_USAGE, wanted: WANTED_QUOTA.].

    הבעיה הזו מציינת שהעבודה התעכבה כי השימוש הנוכחי (QUOTA_USAGE) והמגבלה (QUOTA_LIMIT) של מכסת QUOTA_NAME מנעו את השימוש המבוקש (WANT_QUOTA) של העבודה.

  • כשהעבודה נמצאת במצב QUEUED, ‏SCHEDULED או FAILED, אחת מהבעיות הבאות מופיעה בשדה statusEvents:

    RESOURCE_NAME creation failed:
Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in region REGION

    RESOURCE_NAME creation failed:
Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in zone ZONE

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

פתרון

כדי לפתור את הבעיה:

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

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

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

    • אפשר לשלוח בקשה להגדלת המכסות של הפרויקט דרך Google Cloud.

מידע נוסף זמין במאמרים מכסות ומגבלות של בקשות באצווה ועבודה עם מכסות.

אין הרשאות מספיקות לפעול בתור חשבון השירות

שגיאה

הבעיה הבאה מתרחשת כשמנסים ליצור משרה:

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

    caller does not have access to act as the specified service account: SERVICE_ACCOUNT_NAME

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

    Error: code - CODE_SERVICE_ACCOUNT_MISMATCH, description - The service account specified in the instance template INSTANCE_TEMPLATE_SERVICE_ACCOUNT doesn't match the service account specified in the job JOB_SERVICE_ACCOUNT for JOB_UID, project PROJECT_NUMBER

הבעיה הזו מתרחשת בדרך כלל כי למשתמש שיצר את העבודה אין הרשאות מספיקות לפעול בתור חשבון השירות שבו נעשה שימוש בעבודה. ההרשאה הזו נקבעת על ידי iam.serviceAccounts.actAs.

פתרון

כדי לפתור את הבעיה:

  1. אם המשימה משתמשת בתבנית של הגדרות מכונה, צריך לוודא שחשבון השירות שצוין בתבנית זהה לחשבון השירות שצוין בהגדרה של המשימה.
  2. חשוב לוודא שהמשתמש שיצר את העבודה קיבל את התפקיד Service Account User ‏ (roles/iam.serviceAccountUser) בחשבון השירות שצוין לעבודה. מידע נוסף מופיע במאמר בנושא ניהול גישה.
  3. יוצרים מחדש את המשרה.

רשתות חוזרות

שגיאה

הבעיה הבאה מתרחשת כשמנסים ליצור משרה:

Networks must be distinct for NICs in the same InstanceTemplate

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

פתרון

כדי לפתור את הבעיה, צריך ליצור מחדש את העבודה ולציין את הרשת באמצעות אחת מהאפשרויות הבאות:

מידע נוסף זמין במאמר בנושא ציון הרשת לעבודה.

רשת לא חוקית ל-VPC Service Controls

שגיאה

הבעיה הבאה מתרחשת כשמנסים ליצור משרה:

no_external_ip_address field is invalid. VPC Service Controls is enabled for the project, so external ip address must be disabled for the job. Please set no_external_ip_address field to be true

פתרון

הבעיה הזו מתרחשת כי אתם מנסים ליצור ולהריץ עבודה עם מכונות וירטואליות שיש להן כתובות IP חיצוניות בגבולות גזרה לשירות של VPC Service Controls.

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

מידע נוסף על הגדרת רשת לעבודה בגבול גזרה לשירות של VPC Service Controls זמין במאמר שימוש ב-VPC Service Controls עם Batch.

בעיות בעבודות ושגיאות שגורמות לכשל

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

אין יומנים ב-Cloud Logging

שגיאה

אתם צריכים לנפות באגים בעבודה, אבל לא מופיעים יומנים לגבי העבודה ב-Cloud Logging.

הבעיה הזו מתרחשת בדרך כלל בגלל הסיבות הבאות:

  • ה-Cloud Logging API לא מופעל בפרויקט. גם אם תגדירו נכון את כל שאר הדברים ביומני העבודות, לא ייווצרו יומנים אם השירות לא מופעל בפרויקט.
  • לחשבון השירות של העבודה אין הרשאה לכתוב יומנים. משימה לא יכולה ליצור יומנים ללא הרשאות מספיקות.
  • המשימה לא הוגדרה ליצירת יומנים. כדי ליצור יומנים ב-Cloud Logging, צריך להפעיל את Cloud Logging בעבודה. בנוסף, צריך להגדיר את הרכיבים הניתנים להפעלה של המשימה כך שיכתבו כל מידע שרוצים שיופיע ביומנים לזרמי הפלט הרגיל (stdout) ולשגיאה הרגילה (stderr). מידע נוסף מופיע במאמר ניתוח של משימה באמצעות יומנים.
  • המשימות לא הופעלו. אי אפשר ליצור יומנים עד שהוקצו משאבים למשימות והן מתחילות לפעול.
  • הוגדר ב-Cloud Logging להחריג אוטומטית את היומנים של העבודה. יומנים מעבודות Batch לא יכולים להופיע אם הגדרתם מסנני החרגה ל-Cloud Logging שגורמים להחרגה של יומנים מעבודות Batch.

פתרון

כדי לפתור את הבעיה:

  1. מוודאים שהיומנים לא נכללו אוטומטית ב-Cloud Logging על ידי השבתה של מסנני ההחרגה הנוכחיים של Cloud Logging.
  2. מוודאים ש-Cloud Logging API מופעל בפרויקט.
  3. מוודאים שלחשבון השירות של העבודה יש את תפקיד ה-IAM‏ Logs Writer (roles/logging.logWriter). מידע נוסף זמין במאמר הפעלת Batch בפרויקט.
  4. צפייה בפרטי העבודה באמצעות ה-CLI של gcloud או Batch API פרטי המשימה יכולים לעזור לכם להבין למה המשימה לא יצרה יומנים, ועשויים לספק מידע שקיוויתם לקבל מהיומנים. לדוגמה, אפשר לבצע את הפעולות הבאות:
    1. כדי לוודא שהרישום ביומן מופעל, בודקים את השדה logsPolicy של המשימה.
    2. כדי לוודא שההרצה של העבודה הסתיימה בהצלחה, בודקים את השדה status של העבודה.

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

אין דיווח של סוכני שירות

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents לגבי משימה שלא פועלת כמו שצריך או שנכשלה לפני יצירת מכונות וירטואליות:

No VM has agent reporting correctly within time window NUMBER_OF_SECONDS seconds, VM state for instance VM_NAME is TIMESTAMP,agent,start

הבעיה מציינת שאף אחת מהמכונות הווירטואליות של המשימה לא מדווחת לסוכן השירות של Batch.

הבעיה הזו מתרחשת בדרך כלל בגלל הסיבות הבאות:

  • למכונות הווירטואליות של העבודה אין הרשאות מספיקות. למכונות הווירטואליות של משימה מסוימת נדרשות הרשאות ספציפיות כדי לדווח על המצב שלהן לסוכן השירות של Batch. כדי לתת את ההרשאות האלה למכונות הווירטואליות של עבודה, צריך להקצות לחשבון השירות של העבודה את התפקיד Batch Agent Reporter (roles/batch.agentReporter).
  • יש בעיות ברשת של מכונות ה-VM של העבודה. למכונות הווירטואליות של עבודה מסוימת נדרשת גישה לרשת כדי לתקשר עם סוכן שירות Batch.
  • המכונות הווירטואליות של העבודה משתמשות בקובץ אימג' מיושן של מערכת הפעלה של מכונה וירטואלית ב-Batch, או בקובץ אימג' של מערכת הפעלה של מכונה וירטואלית עם תוכנת סוכן מיושנת של שירות Batch. המכונות הווירטואליות של העבודה צריכות תוכנה בקובץ האימג' של מערכת ההפעלה של המכונה הווירטואלית, שמספקת את התלות הנוכחית לצורך דיווח לסוכן של שירות Batch.

פתרון

כדי לפתור את הבעיה:

  1. מוודאים שלמכונות הווירטואליות של העבודה יש את ההרשאות הנדרשות לדיווח על הסטטוס שלהן לסוכן השירות של Batch.

    1. כדי לזהות את חשבון השירות של העבודה, מעיינים בפרטי העבודה באמצעות ה-CLI של gcloud או Batch API. אם לא מופיע חשבון שירות, המשימה משתמשת בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

    2. מוודאים שלחשבון השירות של העבודה יש הרשאות לתפקיד Batch Agent Reporter ‏(roles/batch.agentReporter). מידע נוסף זמין במאמרים ניהול גישה והגבלת השימוש בחשבון שירות.

      לדוגמה, כדי לתת לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine את ההרשאות הנדרשות, משתמשים בפקודה הבאה:

      gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/batch.agentReporter \
  --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com

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

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

    1. אם הפעלתם את Cloud Logging עבור העבודה, תוכלו לזהות את הבעיה הזו על ידי בדיקה של אחד מיומני הסוכן הבאים (batch_agent_logs). מידע נוסף זמין במאמר ניתוח עבודה באמצעות יומנים.

      • יומן שגיאות של תוכנת סוכן שירות מיושנת של Batch:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_AGENT_VERSION: outdated Batch agent version used.

        ‫BATCH_AGENT_VERSION היא גרסת התוכנה לתקשורת עם סוכן שירות Batch שבה נעשה שימוש בעבודה – לדוגמה, cloud-batch-agent_20221103.00_p00.

      • יומן שגיאות לגבי תמונת מערכת הפעלה מיושנת של מכונת VM של Batch:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_VM_OS_IMAGE_NAME: outdated Batch image version.

        ‫BATCH_VM_OS_IMAGE_NAME היא הגרסה הספציפית של תמונת מערכת ההפעלה של מכונה וירטואלית מ-Batch שבה נעשה שימוש בעבודה – לדוגמה, batch-debian-11-20220909-00-p00.

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

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

  4. יוצרים מחדש את המשרה.

מדדי משאבים חסרים ב-Cloud Monitoring

שגיאה

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

הבעיה הזו מתרחשת בדרך כלל בגלל הסיבות הבאות:

  • ממשק ה-API לא הופעל בפרויקט. גם אם תגדירו את כל שאר הדברים בפרויקט בצורה נכונה, יכול להיות שהמדדים של המשאבים לא יופיעו עד שתפעילו את Cloud Monitoring API. בנוסף, כדי להשתמש בסוכן תפעול, צריך להפעיל את Cloud Logging API.
  • אין לך הרשאות מספיקות כדי לצפות במדדים. אי אפשר לראות את המדדים בלי הרשאות מספיקות.
  • המכונות הווירטואליות של העבודה לא הופעלו. אי אפשר ליצור מדדים למשימה עד שלפחות אחת מהמכונות הווירטואליות של המשימה פועלת.
  • ההגדרות או ההרשאות של העבודה לא תמכו במדדים של סוכן תפעול. חלק ממדדי המשאבים יכולים להינתן רק על ידי סוכן תפעול. כדי לתמוך במדדים של Ops Agent, המשימה צריכה לעמוד בדרישות של Ops Agent, להתקין את Ops Agent ולהשתמש בחשבון שירות שיכול לכתוב מדדים ל-Monitoring.
  • צריך להשתמש בשיטה או במסנן אחרים כדי להציג את המדדים. בחלק מהשיטות להצגת מדדים, המדדים של מכונות וירטואליות לא מוצגים אחרי שהמכונות הווירטואליות נמחקות. בנוסף, מדדים לא יופיעו אם הם לא נכללים במסננים או בתקופת הזמן שמוצגת. בנוסף, לגרפים של מדדים יש רזולוציות שניתנות להתאמה, ולכן יכול להיות שיהיו כמויות קטנות של נתונים שלא יוצגו.
  • המדדים נמחקו. אי אפשר לראות מדדים אחרי שהם נמחקים. המחיקה מתבצעת אוטומטית אחרי תקופות השמירה של הנתונים ב'מעקב'.

פתרון

אם רק מדדים של Ops Agent חסרים, קודם נסו לפתור את הבעיה באמצעות הפעולות הבאות:

  1. כדי לאמת את הגדרות העבודה:
    1. כדי לראות את פרטי ההגדרה המלאים של העבודה, צריך להציג את פרטי העבודה באמצעות ה-CLI של gcloud או Batch API. משתמשים בפלט בשלבים הנותרים.
    2. מוודאים שלחשבון השירות של הג'וב יש הרשאות לכתיבת מדדים של סוכן תפעול.
    3. מוודאים שהמשימה עומדת בכל הדרישות של סוכן תפעול.
    4. מוודאים שהסוכן תפעול מותקן בצורה נכונה. אפשר להתקין את סוכן תפעול באופן ידני ב-runnable, אבל השיטה המומלצת היא להתקין את סוכן תפעול באופן אוטומטי על ידי הגדרת השדה installOpsAgent לערך true.
  2. אם הבעיה נמשכת, אפשר לעיין במאמר פתרון בעיות ב-Ops Agent במסמכי Google Cloud Observability.

אם לא, צריך לפתור את הבעיה באופן הבא:

  1. מוודאים ש-Monitoring API מופעל בפרויקט:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    להפעלת ה-API

  2. מוודאים שהמכונות הווירטואליות של העבודה התחילו לפעול ושהזמן שחלף מאז ההפעלה עדיין נמצא בטווח של תקופות השמירה של המעקב. אפשר לראות את זמן הריצה של המשימה על ידי הצגת פרטי המשימה.
  3. כדי לוודא שאין בעיות בשיטות שבהן אתם משתמשים כדי להציג מדדים, מבצעים את הפעולות הבאות:
    1. אלא אם רוצים לראות מדדים רק של משאבים פעילים, צריך לוודא שאתם רואים את המדדים באמצעות Metrics Explorer או לוח בקרה בהתאמה אישית שנוצר מתרשימים של Metrics Explorer. בשיטות אחרות, כמו לוחות בקרה של Compute Engine, לא מוצגים מדדים של משאבים שנמחקו.
    2. חשוב לוודא שתקופת ההצגה כוללת את זמן הריצה של העבודה. במקרה של תרשימים, חשוב לוודא שהרזולוציה של התרשים מתאימה לנתונים.
    3. מוודאים שאין מסננים שמסתירים את הנתונים.
  4. אם הבעיה נמשכת, אפשר לעיין בדפים בנושא פתרון בעיות ב-Cloud Monitoring במסמכי התיעוד של Google Cloud Observability.

ההגבלה הופרה לגבי כתובות IP חיצוניות של מכונות וירטואליות

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה שנכשלה:

Instance VM_NAME creation failed: Constraint constraints/compute.vmExternalIpAccess violated for project PROJECT_NUMBER.
Add instance VM_NAME to the constraint to use external IP with it.

הבעיה הזו מתרחשת כי בפרויקט, בתיקייה או בארגון שלכם מוגדר compute.vmExternalIpAccess אילוץ של מדיניות הארגון כך שרק מכונות VM שנכללות ברשימת ההיתרים יכולות להשתמש בכתובות IP חיצוניות.

פתרון

כדי לפתור את הבעיה, צריך ליצור מחדש את העבודה ולבצע אחת מהפעולות הבאות:

ההגבלה הופרה לגבי תמונות מהימנות

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה שנכשלה:

Instance VM_NAME creation failed: Constraint constraints/compute.trustedImageProjects violated for project PROJECT_ID. Use of images from project batch-custom-image is prohibited.

פתרון

הבעיה הזו מתרחשת כי בפרויקט שלכם הוגדר אילוץ המדיניות trusted images (compute.trustedImageProjects) כך שאסור להשתמש בתמונות מ-Batch שנמצאות בפרויקט התמונות batch-custom-image.

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

המשימה נכשלה במהלך השימוש בתבנית של הגדרות מכונה

שגיאה

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

INVALID_FIELD_VALUE,BACKEND_ERROR

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

פתרון

כדי לבצע ניפוי באגים נוסף:

  1. יוצרים קבוצת מופעי מכונה מנוהלים (MIG) באמצעות תבנית של הגדרות מכונה ובודקים אם מתרחשות שגיאות עם פרטים נוספים.

  2. אופציונלי: כדי לנסות למצוא מידע נוסף, אפשר לעיין בפעולה ארוכת טווח שיוצרת את ה-MIG במסוף Google Cloud .

    מעבר אל Compute Engine Operations

קודי יציאה של כשל במשימה

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

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

הפסקת פעולה של מכונה וירטואלית (50001)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Spot Preemption with exit code 50001.

הבעיה הזו מתרחשת כשמכונה וירטואלית (VM) מסוג VM במודל Spot של העבודה מפסיקה לפני הזמן במהלך זמן הריצה.

פתרון

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

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

פסק זמן לדיווח על מכונה וירטואלית (50002)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Batch no longer receives VM updates with exit code 50002.

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

פתרון

כדי לפתור את הבעיה:

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

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

    • מומלץ: אפשר לקבל תמיכה דרך Google Cloud התמיכה או דרך התווית Batch בפורומים של Cloud.

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

      1. כדי לזהות את השמות של מכונות ה-VM של העבודה:

        1. צפייה ביומנים של המשימה.
        2. סינון היומנים כדי למצוא רשומות שמכילות את הביטוי report agent state:.

        3. בודקים את היומנים כדי לזהות את המכונה הווירטואלית בכל ניסיון של כל משימה. כל יומן דומה ליומן הבא, שבו יש ביטוי instance: אחד וביטוי task_id: אחד או יותר.

          report agent state: ... instance:"INSTANCE_NAME" ... task_id:"task/JOB_UID-group0-TASK_INDEX/TASK_RETRIES/0 ..."

          היומן הזה כולל את הערכים הבאים:

          • ‫INSTANCE_NAME: שם המכונה הווירטואלית.
          • ‫JOB_UID: המזהה הייחודי (UID) של העבודה.
          • ‫TASK_INDEX: האינדקס של המשימה.
          • ‫TASK_RETRIES: הניסיון של המשימה שהופעלה במכונה הווירטואלית הזו, בפורמט של מספר הניסיונות החוזרים. לדוגמה, הערך הזה הוא 0 בניסיון הראשון של משימה. המערכת מנסה לבצע כל משימה רק פעם אחת, אלא אם מפעילים את האפשרות ניסיונות חוזרים אוטומטיים לביצוע משימות.

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

ה-VM הופעל מחדש במהלך ההרצה (50003)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is rebooted during task execution with exit code 50003.

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

פתרון

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

המכונה הווירטואלית והמשימה לא מגיבות (50004)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to tasks cannot be canceled with exit code 50004.

הבעיה הזו מתרחשת כשמשימה מגיעה למגבלת הזמן של חוסר תגובה ואי אפשר לבטל אותה.

פתרון

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

המשימה פועלת מעבר לזמן הריצה המקסימלי (50005)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to task runs over the maximum runtime with exit code 50005.

הבעיה הזו מתרחשת במקרים הבאים:

  • זמן הריצה של משימה חורג ממגבלת הזמן שצוינה בשדה maxRunDuration
  • זמן הריצה של קובץ הפעלה חורג ממגבלת הזמן שצוינה בשדה timeout

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

פתרון

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

ה-VM נוצר מחדש במהלך ההרצה (50006)

שגיאה

הבעיה הבאה מופיעה בשדה statusEvents של משרה:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is recreated during task execution with exit code 50006.

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

פתרון

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

המאמרים הבאים