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

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

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

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

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 פרטית למכונות וירטואליות של Worker וחשבון שירות של Worker ב-Dataflow שבו אתם רוצים להשתמש. מידע נוסף על הפרמטרים האלה זמין במאמרים gcloud Reference ו-API Reference.

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

  2. משלימים את ההפעלה המהירה Run a pipeline by using the job builder (הפעלת צינור באמצעות הכלי ליצירת משימות), שמפעילה את המשימה כתבנית Flex. אם העבודה נכשלת לפני הפעלת worker 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 ברשת המשנה שבה נעשה שימוש בממשק הרשת של מכונת ה-VM.

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

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

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

מכונות וירטואליות להפעלת תבניות גמישות צריכות גישה אל 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 למכונת ה-VM של כלי ההפעלה: משתמשים בפקודה gcloud compute ssh כדי להתחבר למכונת ה-VM של כלי ההפעלה בזמן שהיא עדיין פועלת:

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

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

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

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

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

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

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

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

כדי להפעיל רישום ביומן עבור תבניות Java, מגדירים את האפשרות enableLauncherVmSerialPortLogging לערך true. כדי להפעיל את הרישום ביומן עבור תבניות Python ו-Go, מגדירים את האפשרות enable_launcher_vm_serial_port_logging לערך true. במסוף Google Cloud , הפרמטר מופיע בפרמטרים אופציונליים בתור הפעלת רישום ביומן של יציאה טורית של מכונת VM במרכז האפליקציות.

אפשר לראות את יומני הפלט של היציאה הטורית של מכונת ה-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 תופעל.

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

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

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

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

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

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

  • כוללים את חבילת Apache Beam Java בספרייה המקומית כדי שהעבודה תוכל לגשת אליה באופן מקומי. מעבירים את הקובץ לספרייה הבאה: /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, וקובץ האימג' של הקונטיינר לא מכיל התקנה של Java.

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

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.