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

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

היומנים של 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. מידע נוסף זמין במאמר הקצאת התפקיד "סוכן שירות של Cloud Scheduler".

  • אימות ההרשאות של חשבון השירות: ודאו שלחשבון השירות שמצורף למשימה יש את ההרשאות וההיקף הנכונים להפעלת שירות היעד. זה כולל תרחישים שבהם היעד נמצא בפרויקט אחר, או שהוא היעד הסופי של שירות ביניים. אם היעד נמצא ב- Google Cloud, ודאו שהקציתם את התפקידים הנדרשים לחשבון השירות. כל שירות ב- Google Cloud דורש תפקיד ספציפי, והשירות המקבל מאמת באופן אוטומטי את האסימון שנוצר. לדוגמה, ב-Cloud Run ובפונקציות Cloud Run, צריך להקצות את התפקיד Cloud 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. נכנסים לדף Logs Explorer ב- במסוף Google Cloud :

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

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

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

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

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

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

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

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

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

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