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

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

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

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

למידע על אירועים שמשפיעים על שירותים, אפשר לעיין בGoogle Cloud Service Health Dashboard ובכל האירועים שדווחו לגבי Cloud Scheduler. Google Cloud

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

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

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

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

  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 Service Agent ‏(roles/cloudscheduler.serviceAgent). ללא התפקיד הזה, משימות Cloud Scheduler נכשלות. אתם יכולים להקצות את התפקיד לסוכן השירות של Cloud Scheduler באופן ידני. נדרשת הענקה ידנית רק אם הפעלתם את Cloud Scheduler API לפני 19 במרץ 2019, או אם הסרתם את התפקיד Cloud Scheduler Service Agent. מידע נוסף זמין במאמר הענקת התפקיד Cloud Scheduler Service Agent.

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

  • בודקים אם יש הפרות של VPC Service Controls:‏ VPC Service Controls הוא תכונה שמאפשרת להגדיר גבולות גזרה מאובטחים כדי להגן מפני זליגת נתונים. Google Cloudכדי לדעת אם השגיאה קשורה ל-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 לא כוללת טוקן אימות תקין – למשל, חסר בבקשה כותרת הרשאה או שפרטי הכניסה לא תקינים. בודקים את הגדרות האימות של העבודה. מידע נוסף זמין במאמרים אימות ל-Cloud Scheduler ושימוש באימות עם HTTP Target.

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

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

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

יעד לא נתמך כשמשתמשים בהיקף מאובטח

כש-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.

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

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

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

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

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

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