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

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

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

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

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. התוכנית שיוצרת את הגרף נמשכת יותר מדי זמן.
  6. הקוד שפועל במכונה הווירטואלית של מרכז הבקרה לוקח יותר מדי זמן כדי להסתיים.
  7. שגיאות לסירוגין ברשת או ב-Cloud Storage.
  8. מתבצעת החלפה של אפשרויות הצינור.
  9. משתמשי Python: התקנה או הכנה של יחסי תלות אורכות יותר מדי זמן.
  10. אירעה שגיאה חולפת.

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

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

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

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

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

  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, יש לגשת ל-launcher 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.

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

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

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

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

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

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

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

    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 פרטיים.

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

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

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

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

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

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

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

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

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

כדי להפעיל רישום ביומן עבור תבניות 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.

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

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Go

  • runner
  • project
  • job_name
  • template_location
  • region

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

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

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

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

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

השגיאה הזו יכולה להיגרם גם בגלל חביון רשת לסירוגין או בעיות ב-Cloud Storage API. מידע נוסף זמין במאמר שגיאות לסירוגין ברשת או ב-Cloud Storage.

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

כשמנסים להפעיל עבודה מתבנית 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

השגיאה הזו נגרמת בגלל בעיה מוכרת בגרסאות 2.47.0 ומטה של Apache Beam Go SDK. כדי לפתור את הבעיה, צריך לשדרג לגרסה 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.

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

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

  • כוללים את חבילת ה-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.

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

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

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

מיצוי משאבים במכונה וירטואלית של Launcher

כשמנסים להריץ ג'וב מתבנית 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 הוא n1-standard-1, בלי קשר לערך של 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.

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

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

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

--template-file-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.