פתרון בעיות ב-Cloud Scheduler

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

כברירת מחדל, אם משימה ב-Cloud Scheduler לא מקבלת אישור משירות היעד שלה (ה-handler של בקשת המשימה), המשימה נחשבת כנכשלת ב-Cloud Scheduler ומתבצע ניסיון חוזר בהתאם להשהיה המעריכית לפני ניסיון חוזר (exponential backoff) שהגדרתם.

למידע על אירועים שמשפיעים על שירותי Google Cloud , קראו את המאמרים לוח הבקרה של סטטוס שירותיGoogle Cloud וכל האירועים שדווחו ב-Cloud Scheduler.

המשימה נכשלת בגלל בעיה בשירות במורד הזרם

יכול להיות שהמשימה נכשלה בגלל בעיה בשירות במורד הזרם שאליו Cloud Scheduler מטרגט (לדוגמה, Cloud Run), ולא בגלל Cloud Scheduler עצמו. סביר להניח שיש בעיה בשירות במורד הזרם אם מתקיימים התנאים הבאים:

  • ההרשאות ל-Cloud Scheduler מוגדרות בצורה נכונה.
  • ‫Cloud Scheduler יכול להגיע לשירות היעד.
  • הודעות השגיאה ביומני הביצוע של Cloud Scheduler מגיעות מהשירות במורד הזרם.

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

  1. הפעלה ישירה של השירות במורד הזרם: מוודאים שאפשר להפעיל את השירות במורד הזרם בלי Cloud Scheduler. אם ההפעלה הצליחה, כנראה שהבעיה היא ב-Cloud Scheduler. אם היא נכשלה, צריך להמשיך את ניפוי הבאגים בשירות במורד הזרם.
  2. בדיקת היומנים של שירות היעד: בודקים את היומנים של שירות היעד, מזהים את השגיאות שמופיעות בפלט ומטפלים בהן בהתאם.
  3. חיפוש פעולות שנמשכות זמן רב: כש-Cloud Scheduler מחזיר שגיאת HTTP 504 לפעולות שנמשכות זמן רב (יותר מ-30 דקות), בודקים את יומני השירות של היעד כדי לראות אם הביצוע הצליח או נכשל, כי יכול להיות שלשירות היעד יש זמן קצוב ארוך יותר לבקשה. בתרחיש הזה, הזמן הקצוב לתפוגה של Cloud Scheduler יסתיים והוא עשוי לנסות שוב להפעיל את המשימה בזמן ששירות היעד עדיין פועל. כדי למנוע הפעלות כפולות בניסיונות חוזרים, קראו את המאמר מניעת כפילויות של בקשות למשימות.

המשימה נכשלת בגלל שגיאת הרשאה

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

אם המשימה של Cloud Scheduler נכשלת בגלל שגיאת הרשאה, יכול להיות שביומני הביצוע תופיע הודעה כמו "debugInfo":"URL_ERROR-ERROR_OTHER. Original HTTP response code number = 403".

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

  • אימות התפקידים של ניהול הזהויות והרשאות הגישה (IAM) שניתנו לסוכן השירות: סוכן השירות של Cloud Scheduler דורש את התפקיד סוכן השירות של Cloud Scheduler‏ (roles/cloudscheduler.serviceAgent). בלי התפקיד הזה, המשימות של Cloud Scheduler ייכשלו. אתם יכולים להקצות את התפקיד באופן ידני לסוכן השירות של Cloud Scheduler. צריך להעניק את התפקיד באופן ידני רק אם הפעלתם את Cloud Scheduler API לפני 19 במרץ 2019, או אם הסרתם את התפקיד Cloud Scheduler Service Agent. מידע נוסף זמין במאמר הקצאת התפקיד "סוכן שירות של Cloud Scheduler".

  • אימות ההרשאות של חשבון השירות: ודאו שלחשבון השירות שמצורף למשימה יש את ההרשאות וההיקף הנכונים להפעלת שירות היעד. זה כולל תרחישים שבהם היעד נמצא בפרויקט אחר או שהוא היעד הסופי של שירות ביניים. אם היעד נמצא ב- Google Cloud, ודאו שהקציתם את התפקידים הנדרשים לחשבון השירות. כל שירות ב- Google Cloud דורש תפקיד ספציפי, והשירות המקבל מאמת באופן אוטומטי את האסימון שנוצר. לדוגמה, ב-Cloud Run ובפונקציות Cloud Run, צריך להקצות את התפקיד Cloud Run Invoker ‏(roles/run.invoker). כשהיעד נמצא מחוץ ל- Google Cloud, השירות המקבל צריך לאמת את האסימון באופן ידני. למידע נוסף, קראו את המאמרים אימות ב-Cloud Scheduler ושימוש באימות עם יעדי HTTP.

  • בדיקה אם יש הפרות של VPC Service Controls: VPC Service Controls הוא מאפיין שלGoogle Cloud שמאפשר להגדיר מתחם אבטחה היקפית כדי להגן מפני זליגת נתונים. כדי לקבוע אם שגיאה קשורה ל-VPC Service Controls, צריך לבדוק אם הפעלתם את VPC Service Controls והחלתם אותו על הפרויקטים והשירותים שבהם אתם משתמשים. כדי לוודא שהפרויקטים והשירותים מוגנים על ידי VPC Service Controls, צריך לבדוק את המדיניות של VPC Service Controls ברמה הזו של היררכיית המשאבים.

    כדי להבין את היקף הבעיה, אתם יכולים לאחזר שגיאות של VPC Service Controls מיומני הביקורת:

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

      נכנסים ל-Logs Explorer.

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

    2. מריצים שאילתה ביומני הביקורת לפי הקריטריונים הבאים:

      severity="ERROR" AND protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"

      באופן ספציפי, הודעות השגיאה עשויות לכלול את הטקסט הבא:

      • Request is prohibited by organization's policy
      • Request violates VPC Service Controls

    למידע נוסף על בעיות שאתם עשויים להיתקל בהן כשאתם מגדירים את VPC Service Controls, קראו את המאמר פתרון בעיות נפוצות.

  • אימות של נקודות קצה פרטיות: Cloud Scheduler יכול להפעיל רק נקודות קצה פרטיות נתמכות, כמו Cloud Run, פונקציות Cloud Run וממשקי API של Google Cloud בתוך היקף השירות של VPC Service Controls. בודקים את הגדרות התעבורה הנכנסת של שירות היעד (לדוגמה, הגבלת התעבורה הנכנסת ברשת ב-Cloud Run) ואת ההרשאות של חשבון השירות המצורף. יכול להיות שתופיע הודעת השגיאה URL_ERROR-ERROR_DNS. למידע נוסף, ראו העברה נכשלת כי אי אפשר להגיע ליעד.

המשימה נכשלת כי אי אפשר להגיע ליעד

הבעיה הזו מתרחשת כשמשימה ב-Cloud Scheduler נכשלת כי אי אפשר להגיע ליעד. ביומני ההרצה מוצגות שגיאות שמתחילות ב-URL_ERROR או ב-URL_UNREACHABLE.

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

  • ‫URL_ERROR-ERROR_AUTHENTICATION: מוחזרת שגיאת HTTP 401 (Unauthorized) או HTTP 407 (Proxy Authentication Required). היעד דורש אימות, אבל הבקשה של Cloud Scheduler לא כוללת אסימון אימות תקין. לדוגמה, בבקשה חסרה כותרת הרשאה או שפרטי הכניסה לא תקינים. בודקים את הגדרות האימות של המשימה. אם נקודת הקצה (endpoint) של היעד דורשת מפתח API ב-request header, ודאו ששם הכותרת תואם למה ששירות היעד מצפה לו, כמו x-api-key או X-Goog-Api-Key, ולא api_key. למידע נוסף, ראו אימות ל-Cloud Scheduler ושימוש באימות עם יעדי HTTP.

  • ‫URL_ERROR-ERROR_DNS: מציין שאחזור כתובת ה-URL נכשל כי לא ניתן היה לפענח את שם המארח באמצעות מערכת שמות הדומיינים (DNS). לדוגמה, שם המארח לא קיים או שאין לו כתובת IP משויכת. יכול להיות שהודעת השגיאה תכלול את הטקסט Original HTTP response code number = 0. צריך לבדוק את תקינות שם המארח, וכשמפעילים נקודת קצה פרטית, לוודא שהיא נתמכת על ידי Cloud Scheduler ולבדוק את הגדרות ה-ingress שלה.

  • ‫URL_ERROR-ERROR_NOT_FOUND: שרת האינטרנט מחזיר שגיאת HTTP‏ 404 Not Found. בודקים אם כתובת היעד נכונה ואם המשאב קיים.

  • ‫URL_ERROR-ERROR_OTHER: מתייחס לשגיאת HTTP 4xx כללית שלא פורטה קודם. בודקים את היומנים כדי לאחזר את קוד תגובת ה-HTTP המקורי. אם קיבלתם שגיאת HTTP 403, עיינו בקטע העבודה נכשלה בגלל שגיאת הרשאה במסמך הזה.

  • ‫URL_UNREACHABLE-UNREACHABLE_5xx: היעד מחזיר שגיאת HTTP מסוג 5xx או 429. יכול להיות שמדובר במצב זמני, כמו עומס יתר בשרת. כדי לפתור את הבעיה, בודקים את היומנים של יעד ההעברה.

  • ‫URL_UNREACHABLE-UNREACHABLE_CONNECTION_RESET: החיבור אופס על ידי הרשת. בודקים אם יש בעיה בצד של השרת החיצוני.

  • ‫URL_UNREACHABLE-UNREACHABLE_ERROR: מציין שגיאה בחיבור לרשת. בודקים אם כתובת ה-URL של היעד נכונה ואם יש כללים של חומת אש שחוסמים את הגישה.

יעד לא נתמך כשמשתמשים בפרימטר מאובטח

כש-Cloud Scheduler הוא שירות מוגבל בהיקף של VPC Service Controls, כל ניסיון ליצור או לעדכן משימה עם יעד לא נתמך נכשל עם קוד השגיאה TARGET_TYPE_NOT_PERMITTED_FOR_VPC. מידע נוסף זמין במאמר אבטחת משימות cron באמצעות VPC Service Controls.

בעיות בהפעלת משימות

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

משימה שפעלה בעבר מפסיקה לפעול

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

resource.type="audited_resource" AND
protoPayload.serviceName="cloudscheduler.googleapis.com" AND
operation.producer="serviceusage.googleapis.com" AND
protoPayload.authorizationInfo.permission="serviceusage.services.disable"

כדי לפתור את הבעיה, צריך להפעיל את Cloud Scheduler API.

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

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

ברשומות היומן, מאתרים את הרשומה האחרונה של type.googleapis.com/google.cloud.scheduler.logging.AttemptStarted ואת הרשומה התואמת של type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished. אם הרשומה AttemptFinished חסרה או מופיעה אחרי ההפעלה המתוזמנת הבאה של המשימה, הפעלות אחרות בהמתנה נחסמות ולא מתחילות. בהתאם לתזמון של המשימה, יכול להיות שהפעולה הזו תמנע את ההפעלה של כמה משימות. כדי לבדוק את הנושא לעומק, צריך לאמת את הזמן הקצוב לתפוגה ביעד של המשימה ולבדוק אם היו בעיות ביעד.

הפעלת משימה הופכת ללא סדירה בגלל שעון קיץ

כשיוצרים משימה ב-Cloud Scheduler באמצעות מסוף Google Cloud , צריך לציין אזור זמן. כשמשתמשים ב-Google Cloud CLI, אפשר לציין אזור זמן באמצעות הדגל --time-zone. אם לא מציינים אזור זמן, ברירת המחדל היא זמן אוניברסלי מתואם (UTC).

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

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

מידע נוסף זמין במאמר פורמט ואזור זמן של משימת Cron.

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

אם לא מצאתם פתרון לבעיה במסמכי התיעוד של Cloud Scheduler, תוכלו להיעזר באפשרויות הבאות:

מידע נוסף מופיע במאמר תמיכה ב-Cloud Scheduler.