פתרון בעיות בתבניות Flex

בדף הזה מופיעים טיפים לפתרון בעיות ושיטות לניפוי באגים שיכולים לעזור לכם אם אתם משתמשים בתבניות גמישות של Dataflow. כברירת מחדל, הזמן הקצוב לתפוגה של תהליך ההפעלה של תבנית Flex הוא 12 דקות. תהליך ההפעלה הזה כולל משיכה של קובץ אימג' של קונטיינר של התבנית והרצת הקוד כדי ליצור את גרף העבודה. אם ההפעלה לא תושלם תוך 12 דקות, העבודה תיכשל ותוצג השגיאה 'Timeout in polling result file'. המידע הזה יכול לעזור לכם לזהות מצב של פסק זמן (timeout) של שליחת בקשות, לקבוע את הסיבה לפסק הזמן ולתקן את הבעיה.

שגיאה בטעינת רשימת התבניות במסוף Google Cloud

במסוף Google Cloud , כשמנסים להציג את רשימת התבניות בדף Dataflow Create job from template, מוצגת שגיאה דומה לזו:

Error retrieving templates. Custom templates can still be used.

אם הארגון שלכם משתמש במדיניות של גבולות גישה לעקרונות (PAB), יכול להיות שייחסמו עקרונות (כמו משתמשים או חשבונות שירות) ולא תהיה להם אפשרות להציג ולהפעיל תבניות שסופקו על ידי Google. כדי לפתור את הבעיה, אפשר לנסות את ההנחיות במאמר גישה לתבניות שסופקו על ידי Google באמצעות מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

שגיאות שקשורות לפסק זמן של דגימה

יכול להיות שתופיע אחת מהודעות השגיאה הבאות:

Timeout in polling result file: FILE_PATH. Possible causes are:
1. Your launch takes too long time to finish. Please check the logs on stackdriver.
2. Service account SERVICE_ACCOUNT may not have enough permissions to pull
container image IMAGE_PATH or create new objects in FILE_PATH.
3. Transient errors occurred, please try again.

Timeout in polling result file: FILE_PATH.
Service account: SERVICE_ACCOUNT
Image URL: IMAGE_PATH
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

השגיאה הזו יכולה להופיע מהסיבות הבאות:

  1. קובץ האימג' הבסיסי של Docker הוחלף.
  2. לחשבון השירות שממלא את SERVICE_ACCOUNT חסרות הרשאות נדרשות.
  3. כתובות IP חיצוניות מושבתות, ומכונות וירטואליות לא יכולות להתחבר לסט של כתובות IP חיצוניות שמשמשות את Google APIs והשירותים של Google.
  4. המכונה הווירטואלית של כלי ההפעלה לא יכולה לפתור את gcr.io או לגשת אליו.
  5. קובץ אימג' גדול של קונטיינר של תבנית Flex.
  6. התוכנית שיוצרת את הגרף נמשכת יותר מדי זמן.
  7. הקוד שפועל במכונה הווירטואלית של כלי ההפעלה נמשך יותר מדי זמן.
  8. שגיאות לסירוגין ברשת או ב-Cloud Storage.
  9. מתבצעת החלפה של אפשרויות הצינור.
  10. משתמשי Python: התקנה או הכנה של יחסי תלות אורכות יותר מדי זמן.
  11. אירעה שגיאה זמנית.

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

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

אם השלבים האלה לא פותרים את הבעיה, אפשר לנסות את השלבים הבאים לפתרון בעיות.

אופציונלי: מריצים תבניות כדי לאבחן את הבעיה

כדי לזהות איזו מהסיבות הקודמות גורמת לשגיאה הזו, אפשר להשתמש באסטרטגיות הבאות:

  1. מריצים את התבנית WordCount ש-Google סיפקה. חשוב לציין פרמטרים שייחודיים לתרחיש השימוש שלכם, כמו רשת המשנה מפרויקט VPC משותף, כתובת IP פרטית למכונות וירטואליות של עובדים וחשבון שירות של עובדי Dataflow שבו אתם רוצים להשתמש. מידע נוסף על הפרמטרים האלה זמין במאמרים gcloud Reference ו-API Reference.

    אם תצליחו להשלים את המשימה הזו, סביר להניח שהגדרתם את הרשת, את הרשאות ה-IAM ואת הגישה הפרטית ל-Google בצורה נכונה.

  2. משלימים את ההוראות שבמדריך להתחלה מהירה הרצת צינור עיבוד נתונים באמצעות הכלי ליצירת משימות, שבו מריצים את המשימה כתבנית Flex. אם העבודה נכשלת לפני הפעלת ה-VM של העובד, ניגשים ל-VM של מפעיל העבודה ומנסים להוריד תמונה לדוגמה של Docker באמצעות פקודה שדומה לפקודה הבאה:

    docker run --entrypoint /bin/bash -it gcr.io/dataflow-templates/2025-03-11-00_rc02/yaml-template

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

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

אימות נקודת הכניסה של Docker

כדאי לנסות את השלב הזה אם מריצים תבנית מקובץ אימג' מותאם אישית של Docker ולא משתמשים באחת מהתבניות שסופקו.

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

docker inspect $TEMPLATE_IMAGE

הפלט הצפוי:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

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

בדיקת ההרשאות של חשבון שירות

בודקים שלחשבון השירות שמוזכר בהודעה יש את ההרשאות הבאות:

  • הוא צריך להיות מסוגל לקרוא ולכתוב את הנתיב של Cloud Storage שמופיע ב-${file_path} בהודעה.
  • הוא צריך להיות מסוגל לקרוא את תמונת Docker שממלאת את ${image_url} בהודעה.

הגדרת גישה פרטית ל-Google

אם כתובות IP חיצוניות מושבתות, צריך לאפשר למכונות וירטואליות ב-Compute Engine להתחבר לסט של כתובות IP חיצוניות שמשמשות את ממשקי ה-API והשירותים של Google. מפעילים את גישה פרטית ל-Google ברשת המשנה שבה נעשה שימוש בממשק הרשת של המכונה הווירטואלית.

פרטים על ההגדרה מופיעים במאמר בנושא הגדרת גישה פרטית ל-Google.

כברירת מחדל, כשמכונה וירטואלית ב-Compute Engine לא מקבלת כתובת IP חיצונית שמוקצית לממשק הרשת שלה, היא יכולה לשלוח חבילות רק לכתובות IP פנימיות אחרות.

בעיות גישה ל-GCR.io

מכונות וירטואליות להפעלת תבניות Flex צריכות גישה אל gcr.io כדי לשלוף קונטיינר של סוכן רישום ביומן (gcr.io/dataflow-templates-base/template-launcher-logger-distroless). הסוכן הזה אחראי להעברת יומני ההפעלה אל Cloud Logging. אם מכונת ה-VM של מרכז ההפעלה לא מצליחה לפתור את הבעיה או להתחבר אל gcr.io, יכול להיות שתהליך ההפעלה יפסיק להגיב, מה שיוביל לזמן קצוב לתפוגה של הסקר.

הבעיה הזו יכולה להתרחש גם אם תמונת התבנית המותאמת אישית שלכם מאוחסנת ב-Artifact Registry, כי סוכן הרישום תמיד נשלף מ-gcr.io.

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

  1. הפעלת רישום ביומן של יציאה טורית: פועלים לפי השלבים בקטע בעיות בהפעלה מוקדמת. אם התהליך נתקע או אם יש שגיאות שקשורות ל-cloud-init gcr-wait-online.service, סביר להניח שיש בעיה ב-DNS או ברשת.

  2. מתחברים ב-SSH למכונה הווירטואלית של כלי ההפעלה: משתמשים בפקודה gcloud compute ssh כדי להתחבר למכונה הווירטואלית של כלי ההפעלה בזמן שהיא עדיין פועלת:

    gcloud compute ssh launcher-JOB_ID --tunnel-through-iap

    מחליפים את JOB_ID במזהה של משימת Dataflow.

  3. אימות פענוח ה-DNS: מריצים את הפקודות הבאות ב-VM של מרכז הבקרה:

    curl -I https://gcr.io

    אם הפקודה נכשלת עם שגיאה "Could not resolve host", חסר בהגדרת ה-DNS רשומה עבור gcr.io.

  4. בדיקה אם יש שירותים תקועים בהפעלה: בודקים את יומן הפלט cloud-init:

    sudo cat /var/log/cloud-init-output.log

    מחפשים הודעות שמציינות שהתהליך ממתין לרשת או לכך ש-gcr.io יהיה נגיש.

בנוסף, צריך לוודא שהגדרות ה-DNS של ה-VPC מאפשרות את הרזולוציה של gcr.io. בהגדרות מסוימות של רשתות פרטיות, יכול להיות שתצטרכו להוסיף רשומת DNS ספציפית של Agcr.io שמפנה לטווחי כתובות ה-IP של Google APIs מוגבלים או של Google APIs פרטיים.

קובץ אימג' גדול של קונטיינר

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

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

  • כדי לזרז את תהליך השליפה, כדאי לבצע אופטימיזציה של התמונה כדי להקטין את הגודל שלה.
  • משתמשים בדגל --launcher-machine-type כדי לבחור סוג מכונה עם יותר ליבות CPU, מה שעוזר לשלוף את התמונה מהר יותר ומוביל להפעלה מהירה יותר.
  • משתמשים בדגל --launcher-vm-timeout-secs כדי לציין משך זמן ארוך יותר להמתנה (timeout) של המכונה הווירטואלית של מרכז האפליקציות, וכך מאפשרים לה לחרוג מהמגבלה של 12 דקות שמוגדרת כברירת מחדל.

בודקים אם תוכנית ההפעלה לא יוצאת

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

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

  • מוודאים שאין שרשורים שמונעים מהתוכנית לצאת. יכול להיות שחלק מהלקוחות ייצרו שרשורים משלהם, ואם הלקוחות האלה לא יושבתו, התוכנית תחכה לנצח עד שהשרשורים האלה יצטרפו.
  • בקוד שמגדיר את צינור עיבוד הנתונים, אל תשתמשו ב-waitUntilFinish (ל-Java) או ב-wait_until_finish (ל-Python). הפונקציות האלה חוסמות את היציאה מהתוכנית, ולכן התבנית הגמישה לא יכולה להפעיל את צינור העיבוד.

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

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

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

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

שגיאות לסירוגין ברשת או ב-Cloud Storage

יכולות להתרחש שגיאות לסירוגין כמו 'פסק זמן בבדיקת קובץ התוצאות' או 'הקריאה של קובץ התוצאות נכשלה' בגלל חביון גבוה ברשת או בעיות זמניות ב-Cloud Storage API. התנגשות כרונית ברשת ה-VPC, במיוחד בנתיב של גישה פרטית ל-Google, גורמת לעיתים קרובות לזמני אחזור של 400 עד 500 אלפיות השנייה.

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

כדי לאבחן את הכשלים לסירוגין האלה:

  1. בדיקת זמן האחזור ברשת: עוקבים אחרי זמן האחזור ברשת ב-VPC. חביון גבוה מתמשך עלול לגרום לפסק זמן כשמכונת ה-VM של מפעיל התהליך מנסה לכתוב או לקרוא את קובץ התוצאות של העבודה מ-Cloud Storage.

  2. מעקב אחרי מדדים של Cloud Storage API:

    1. במסוף Google Cloud , עוברים למרכז הבקרה APIs & Services.

      כניסה אל Enabled APIs & services

    2. מסננים ובוחרים את Cloud Storage API.

    3. בודקים את התרשימים של תנועה (בייטים שנשלחו ונתקבלו) ושל שיעור השגיאות.

    4. מחפשים עליות חדות בשגיאות 5xx (כמו שגיאות 503) שחלות בדיוק בזמן הכשלים בעבודות.

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

לבדוק אם אפשרויות הפייפליין הנדרשות מושבתות

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

משתמשי Python: ניהול יחסי תלות

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

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

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

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

ההרשאה נדחתה במהלך טעינת קובץ תבנית

כשמנסים להריץ תבנית שסופקה על ידי Google באמצעות ה-CLI של gcloud, מוצגת שגיאה שדומה לזו:

ERROR: (gcloud.dataflow.flex-template.run) PERMISSION_DENIED: Template file
failed to load: TEMPLATE_PATH. Permissions denied.
USER does not have storage.objects.get access to the Google
Cloud Storage object. Operations on resource are denied due to an IAM
Principal Access Boundary Policy.

‫TEMPLATE_PATH הוא נתיב לתבנית בקטגוריה של Cloud Storage שמכילה את התבניות שסופקו על ידי Google, כמו gs://dataflow-templates או gs://dataflow-templates-REGION_NAME.

אם הארגון שלכם משתמש במדיניות של גבולות גישה לעקרונות (PAB), יכול להיות שייחסמו עקרונות (כמו משתמשים או חשבונות שירות) ולא תהיה להם אפשרות להציג ולהפעיל תבניות שסופקו על ידי Google. כדי לפתור את הבעיה, אפשר לנסות את ההנחיות במאמר גישה לתבניות שסופקו על ידי Google באמצעות מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

בעיות בהפעלה מוקדמת

אם תהליך ההפעלה של התבנית נכשל בשלב מוקדם, יכול להיות שלא יהיו יומני רישום רגילים של Flex Template. כדי לבדוק בעיות בהפעלה, צריך להפעיל רישום ביומן של יציאה טורית במכונת ה-VM של מפעיל התבניות.

כדי להפעיל רישום ביומן עבור תבניות Java, מגדירים את האפשרות enableLauncherVmSerialPortLogging לערך true. כדי להפעיל את הרישום ביומן עבור תבניות Python ו-Go, מגדירים את האפשרות enable_launcher_vm_serial_port_logging לערך true. במסוף Google Cloud , הפרמטר מופיע בOptional parameters בתור Enable Launcher VM Serial Port Logging.

אפשר לראות את יומני הפלט של היציאה הטורית של מכונת ה-VM של כלי ההפעלה של התבניות ב-Cloud Logging. כדי למצוא את היומנים של מכונת VM מסוימת של Launcher, משתמשים בשאילתה resource.type="gce_instance" "launcher-number" כאשר number מתחיל בתאריך הנוכחי בפורמט YYYMMDD.

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

קריאת קובץ המשרה נכשלה

כשמנסים להריץ ג'וב מתבנית Flex, יכול להיות שהג'וב ייכשל עם השגיאה הבאה:

Failed to read the job file : gs://dataflow-staging-REGION-PROJECT_ID/staging/template_launches/TIMESTAMP/job_object...

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

כדי להימנע מהבעיה הזו, במהלך האתחול של צינור העיבוד, אל תשנו את אפשרויות צינור העיבוד הבאות בקוד המשתמש או בקובץ metadata.json:

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

המשך

  • runner
  • project
  • job_name
  • template_location
  • region

הייתה בעיה בקריאת קובץ התוצאות

כשמנסים להריץ ג'וב מתבנית Flex, יכול להיות שהג'וב ייכשל עם השגיאה הבאה:

Failed to read the result file : gs://BUCKET_NAME...

השגיאה הזו מתרחשת כשחשבון השירות שמשמש כברירת המחדל של Compute Engine לא כולל את כל ההרשאות שנדרשות להפעלת תבנית Flex.

רשימת ההרשאות הנדרשות זמינה במאמר הרשאות להרצת תבנית Flex.

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

ההרשאה נדחתה במשאב

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

Permission "MISSING_PERMISSION" denied on resource "projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME" (or it may not exist).

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

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

הדגל סופק אבל לא הוגדר

כשמנסים להפעיל תבנית Go Flex עם האפשרות worker_machine_type pipeline, הצינור נכשל עם השגיאה הבאה:

flag provided but not defined: -machine_type

השגיאה הזו נגרמת בגלל בעיה מוכרת בגרסאות Apache Beam Go SDK‏ 2.47.0 ואילך. כדי לפתור את הבעיה, צריך לשדרג לגרסה 2.48.0 ואילך של Apache Beam Go.

לא ניתן לאחזר את קובץ ה-JAR של שרת המשרות המרוחק

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

Unable to fetch remote job server jar at
https://repo.maven.apache.org/maven2/org/apache/beam/beam-sdks-java-io-expansion-service/VERSION/beam-sdks-java-io-expansion-service-VERSION.jar:
\u003curlopen error [Errno 101] Network is unreachable\u003e

השגיאה הזו מתרחשת כי ל-VM אין אפשרות להוריד את חבילת Java של Apache Beam מהאינטרנט. החבילה הזו נדרשת כשמריצים עבודה בכמה שפות באמצעות תבנית Flex.

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

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

  • צריך לכלול את חבילת ה-Java של Apache Beam בספרייה המקומית כדי שהעבודה תוכל לגשת אליה באופן מקומי. מכניסים את הקובץ לספרייה הבאה: /root/.apache_beam/cache/jars/. לדוגמה, /root/.apache_beam/cache/jars/beam-sdks-java-io-expansion-service-SDK_VERSION.jar.

לא ניתן לקבל את מערכת הקבצים מהנתיב שצוין

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

ValueError: Unable to get filesystem from specified path, please use
the correct path or ensure the required dependency is installed, e.g., pip
install apache-beam[gcp]. Path specified: PATH

השגיאה הזו מתרחשת כשהעבודה משתמשת בקובץ אימג' של קונטיינר של Flex Template, וקובץ האימג' של הקונטיינר לא מכיל התקנה של Java.

כדי לפתור את הבעיה, מוסיפים את השורה הבאה לקובץ Dockerfile:

sh RUN apt-get update && apt-get install -y openjdk-17-jdk

הפקודה הזו מתקינה את Java בסביבת הקונטיינר.

מיצוי משאבים של מכונה וירטואלית במרכז האפליקציות

כשמנסים להריץ עבודה מתבנית Flex, יכול להיות שהעבודה תיכשל עם השגיאה הבאה:

Failed to start the VM, launcher-ID, used for launching because of status code: INTERNAL, reason: Unknown error in operation 'OPERATION_ID': [ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS] 'The zone 'projects/PROJECT_ID/zones/ZONE_ID' does not have enough resources available to fulfill the request.

השם של המכונה הווירטואלית launcher-ID מייצג את השם של המכונה הווירטואלית של כלי ההפעלה. המכונה הווירטואלית של כלי ההפעלה אחראית לאיסוף משאבים של משימות, כמו קוד התבנית והתמונה, לפני בניית גרף המשימות ושליחתו לשירות Dataflow כדי להתחיל את העבודה.

אם לא מציינים את הפרמטר launcherMachineType, ‏ Dataflow בוחר סוג מכונה שמוגדר כברירת מחדל למכונת ה-VM של המפעיל. הבחירה הזו לא תלויה בעובד machineType. שגיאות של מיצוי משאבים יכולות לקרות אם סוג המכונה שמוגדר כברירת מחדל לא זמין באזור או באזור הזמינות של העבודה.

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

השהיה בהפעלת תבנית Flex

כששולחים משימה של תבנית Flex, בקשת המשימה נכנסת לתור של Spanner. הכלי להפעלת תבניות שולף את העבודה מתור Spanner ומריץ את התבנית. אם יש ב-Spanner הצטברות של הודעות שלא טופלו, יכול להיות שיהיה עיכוב משמעותי בין הזמן שבו שולחים את העבודה לבין הזמן שבו העבודה מתחילה.

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

הפרמטרים של התבנית לא תקינים

כשמנסים להשתמש ב-CLI של gcloud כדי להריץ עבודה שמשתמשת בתבנית שסופקה על ידי Google, מתקבלת השגיאה הבאה:

ERROR: (gcloud.beta.dataflow.flex-template.run) INVALID_ARGUMENT: The template
parameters are invalid. Details: defaultSdkHarnessLogLevel: Unrecognized
parameter defaultWorkerLogLevel: Unrecognized parameter

השגיאה הזו מתרחשת כי חלק מהתבניות ש-Google מספקת לא תומכות באפשרויות defaultSdkHarnessLog ו-defaultWorkerLog.

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

תבניות Flex

בתבניות Flex, משתמשים בדגל --additional-pipeline-options כדי להעביר את אפשרויות הצינור כמחרוזת. לדוגמה, באמצעות הפקודה gcloud dataflow flex-template run:

gcloud dataflow flex-template run JOB_NAME \
--template-file-gcs-location=GCS_TEMPLATE_PATH \
--additional-pipeline-options=defaultSdkHarnessLogLevel=WARN,defaultWorkerLogLevel=WARN

מחליפים את הערכים הבאים:

  • ‫JOB_NAME: השם של משימת Dataflow
  • ‫GCS_TEMPLATE_PATH: הנתיב ב-Cloud Storage לקובץ התבנית
תבניות קלאסיות

בתבניות קלאסיות, הפתרון העקיף הוא להעתיק את קובץ הגדרות התבנית לקטגוריה של Cloud Storage ולהוסיף לקובץ את הפרמטרים הנוספים הבאים.

"metadata": {
    ...
    "parameters": [
      ...,
      {
        "name": "defaultSdkHarnessLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      },
      {
        "name": "defaultWorkerLogLevel",
        "isOptional": true,
        "paramType": "TEXT"
      }
    ]
  }

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

--gcs-location=gs://BUCKET_NAME/FILENAME

מחליפים את הערכים הבאים:

  • ‫BUCKET_NAME: שם הקטגוריה של Cloud Storage
  • ‫FILENAME: השם של קובץ מפרט התבנית

יומני ההפעלה של תבניות Flex מציגים חומרה שגויה

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

ERROR: Error occurred in the launcher container: Template launch failed. See console logs.

שורש הבעיה של כשל בהשקה מופיע בדרך כלל ביומנים לפני ההודעה הזו, עם רמת החומרה INFO. יכול להיות שרמת היומן הזו לא נכונה, אבל זה צפוי כי למפעיל של תבנית Flex אין דרך לחלץ פרטים על חומרת הבעיה מהודעות היומן שנוצרות על ידי אפליקציית Apache Beam.

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

{
  "message": "The original log message",
  "severity": "DEBUG/INFO/WARN/ERROR"
}

ב-Java, אפשר להשתמש ב-Logback logger עם הטמעה מותאמת אישית של appender בפורמט JSON. מידע נוסף אפשר למצוא בדוגמה להגדרת Logback ובדוגמה לקוד של JSON appender ב-GitHub.

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

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