‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

קובץ האימג' הבסיסי של Docker הוחלף.
לחשבון השירות שממלא את SERVICE_ACCOUNT אין חלק מההרשאות הנדרשות.
כתובות IP חיצוניות מושבתות, והמכונות הווירטואליות לא יכולות להתחבר לקבוצת כתובות ה-IP החיצוניות שמשמשות את Google APIs והשירותים של Google.
המכונה הווירטואלית של מרכז האפליקציות לא יכולה לפתור את gcr.io או לגשת אליו.
קובץ אימג' גדול של קונטיינר בתבנית Flex.
לוקח יותר מדי זמן לתוכנית שיוצרת את התרשים לסיים את הפעולה.
לוקח יותר מדי זמן להריץ את הקוד במכונה הווירטואלית של מרכז האפליקציות.
שגיאות לסירוגין ברשת או ב-Cloud Storage.
אפשרויות הצינור מוחלפות.
משתמשי Python: ההתקנה או ההכנה של יחסי התלות נמשכת יותר מדי זמן.
הייתה שגיאה זמנית.

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

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

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

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

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

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

אם הצלחתם להשלים את המשימה, כנראה שהגדרתם נכון את הרשת, את הרשאות ה-IAM ואת הגישה הפרטית ל-Google.
מבצעים את המשימות במדריך למתחילים הפעלת צינור עיבוד נתונים באמצעות הכלי ליצירת משימות, שמפעיל את המשימה כתבנית Flex. אם המשימה נכשלת לפני הפעלת ה-worker VM, צריך לגשת ל-launcher VM ולנסות להוריד קובץ אימג' לדוגמה של Docker באמצעות פקודה שדומה לפקודה הבאה:
```
docker run --entrypoint /bin/bash -it gcr.io/dataflow-templates/2025-03-11-00_rc02/yaml-template
```
אם הפקודה הזו נכשלת, יכול להיות שיש בעיה ברשת בהורדת התמונות. במקרה כזה, צריך לעבוד עם צוות הרשתות הפנימי.
מריצים תבנית 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 של Launcher צריכות גישה אל gcr.io כדי לשלוף קונטיינר של סוכן Logging (gcr.io/dataflow-templates-base/template-launcher-logger-distroless). הסוכן הזה אחראי להעברת יומנים של Launcher אל Cloud Logging. אם ה-VM של מרכז האפליקציות לא יכול לפתור את gcr.io או להתחבר אליו, יכול להיות שתהליך ההפעלה יפסיק להגיב, מה שיוביל לזמן קצוב לתפוגה של הסקר.

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

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

הפעלת רישום ביומן של היציאה הטורית: פועלים לפי השלבים בקטע בעיות בשלב מוקדם של ההפעלה. אם התהליך cloud-init נתקע או אם יש שגיאות שקשורות ל-gcr-wait-online.service, סביר להניח שיש בעיה ב-DNS או ברשת.
התחברות ב-SSH למכונה הווירטואלית של מרכז האפליקציות: משתמשים בפקודה gcloud compute ssh כדי להתחבר למכונה הווירטואלית של מרכז האפליקציות בזמן שהיא עדיין פועלת:
```
gcloud compute ssh launcher-JOB_ID --tunnel-through-iap
```
מחליפים את JOB_ID במזהה של משימת Dataflow.
אימות פענוח ה-DNS: מריצים את הפקודות הבאות בתוך ה-VM של מרכז האפליקציות:
```
curl -I https://gcr.io
```
אם הפקודה נכשלת עם שגיאת "Could not resolve host", בהגדרת ה-DNS חסרה רשומה של gcr.io.
בדיקה אם יש שירותי הפעלה תקועים: בודקים את יומן הפלט של cloud-init:
```
sudo cat /var/log/cloud-init-output.log
```
חפשו הודעות שמציינות שהתהליך ממתין לרשת או ש-gcr.io יהיה נגיש.

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

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

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

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

כדי להאיץ את תהליך השליפה, כדאי לבצע אופטימיזציה של קובץ האימג' ולהקטין את הגודל שלו.
משתמשים בדגל --launcher-machine-type כדי לבחור סוג מכונה עם יותר ליבות מעבד (CPU), מה שעוזר לשלוף את קובץ האימג' מהר יותר ומוביל להפעלה מהירה יותר.
כדי להאריך את זמן הקצוב לתפוגה של ההפעלה מעבר למגבלת ברירת המחדל של 12 דקות (720 שניות), משתמשים בדגל --launcher-vm-timeout-secs ב-CLI של gcloud או באפשרות ההפעלה ft_launch_timeout_secs ב-API בארכיטקטורת REST וב-Managed Service for Apache Airflow. דוגמאות מופיעות במאמר הארכת הזמן הקצוב לתפוגה של הפעלת תבנית Flex.

בודקים אם תוכנת מרכז האפליקציות לא נסגרת

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

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

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

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

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

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

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

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

שגיאות לסירוגין כמו "Timeout in polling result file" או "Failed to read the result file" יכולות להתרחש בגלל זמן אחזור גבוה ברשת או בעיות זמניות ב-Cloud Storage API. תחרות כרונית על משאבי הרשת ב-VPC, במיוחד בנתיב של גישה פרטית ל-Google, גורמת לעיתים קרובות לזמן אחזור של 400-500 אלפיות השנייה.

השגיאה "Timeout in polling result file" היא בדרך כלל כשל איטי, והשגיאה "Failed to read the result file" היא כשל מהיר, אבל שתיהן בדרך כלל מצביעות על אותה בעיית קישוריות בסיסית.

כדי לאבחן את הכשלים האלה:

בדיקת זמן האחזור של הרשת: עוקבים אחרי זמן האחזור של הרשת ב-VPC. זמן אחזור גבוה לאורך זמן עלול לגרום לפסקי זמן כשה-VM של מרכז האפליקציות מנסה לכתוב או לקרוא את קובץ התוצאות של המשימה מ-Cloud Storage.
מעקב אחרי מדדי Cloud Storage API:
1. במסוף Google Cloud , נכנסים למרכז הבקרה APIs & Services.
  
  כניסה אל Enabled APIs & services
2. מסננים ובוחרים את Cloud Storage API.
3. בודקים את התרשימים Traffic (בייטים שנשלחו והתקבלו) ו-Error rate.
4. חפשו עליות חדות בשגיאות 5xx (כמו שגיאות 503) שמתרחשות בדיוק בזמן שהמשימות נכשלות.

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

איך בודקים אם אפשרויות נדרשות של צינור עיבוד נתונים מבוטלות

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

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

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

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

הארכת זמן הקצוב לתפוגה של הפעלת תבנית Flex

כברירת מחדל, Dataflow אוכף זמן קצוב לתפוגה של 720 שניות (12 דקות) בשלב ההפעלה של תבנית Flex. אם שליפת קובצי אימג' גדולים של קונטיינרים, יחסי תלות של שלב ביניים או בניית תרשימי ביצוע מורכבים נמשכים יותר מ-720 שניות, אתם יכולים להאריך את הזמן הקצוב לתפוגה על ידי הגדרת האפשרות של זמן קצוב לתפוגה של ההפעלה בשיטת ההפעלה שלכם.

‫CLI של gcloud

כדי להאריך את הזמן הקצוב לתפוגה של ה-VM להפעלה כשמריצים תבנית Flex מה-CLI של gcloud, מעבירים את הדגל --launcher-vm-timeout-secs לפקודה gcloud dataflow flex-template run:

gcloud dataflow flex-template run JOB_NAME \
  --template-file-gcs-location=TEMPLATE_GCS_PATH \
  --region=REGION \
  --launcher-vm-timeout-secs=TIMEOUT_SECONDS

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

‫JOB_NAME: השם של משימת Dataflow.
‫TEMPLATE_GCS_PATH: ה-URI של Cloud Storage של קובץ המפרט של תבנית Flex, למשל gs://my-bucket/templates/my-template.json.
‫REGION: האזור ב-Dataflow שבו המשימה פועלת.
‫TIMEOUT_SECONDS: משך הזמן הקצוב לתפוגה של המכונה הווירטואלית של מרכז האפליקציות, בשניות. צריך לציין מספר שלם חיובי בלי סיומת של יחידה. זמן הקצוב לתפוגה שמוגדר כברירת מחדל הוא 720, כלומר 12 דקות. כדי להאריך את הזמן הקצוב לתפוגה, צריך לציין מספר שלם שגדול מ-720 ועד 5400 (90 דקות), למשל 1200 ל-20 דקות או 1800 ל-30 דקות.

‫API בארכיטקטורת REST

כשמפעילים תבנית Flex באמצעות קריאה לנקודת הקצה (endpoint) של projects.locations.flexTemplates.launch ב-REST, מגדירים את המפתח ft_launch_timeout_secs במפה launchParameter.launchOptions למחרוזת שמכילה את משך הזמן הקצוב לתפוגה בשניות כמספר שלם, בלי סיומת של יחידה:

{
  "launchParameter": {
    "jobName": "JOB_NAME",
    "containerSpecGcsPath": "TEMPLATE_GCS_PATH",
    "launchOptions": {
      "ft_launch_timeout_secs": "TIMEOUT_SECONDS"
    }
  }
}

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

‫JOB_NAME: השם של משימת Dataflow.
‫TEMPLATE_GCS_PATH: ה-URI של Cloud Storage של קובץ המפרט של תבנית Flex, למשל gs://my-bucket/templates/my-template.json.
‫TIMEOUT_SECONDS: משך הזמן הקצוב לתפוגה של המכונה הווירטואלית של מרכז האפליקציות, בשניות. צריך לציין מספר שלם חיובי כמחרוזת בלי סיומת של יחידה. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל הוא "720", כלומר 12 דקות. כדי להאריך את הזמן הקצוב לתפוגה, מציינים מספר שלם שגדול מ-720 ועד 5400 (90 דקות), למשל "1200" ל-20 דקות או "1800" ל-30 דקות.

Managed Airflow

כשמתזמרים משימות של תבניות Flex ב-Managed Airflow או ב-Apache Airflow באמצעות האופרטור DataflowStartFlexTemplateOperator, צריך לכלול את המפתח ft_launch_timeout_secs בקטע launchParameter.launchOptions במילון body:

from airflow.providers.google.cloud.operators.dataflow import (
    DataflowStartFlexTemplateOperator,
)

start_flex_template = DataflowStartFlexTemplateOperator(
    task_id="start_flex_template",
    project_id="PROJECT_ID",
    location="REGION",
    body={
        "launchParameter": {
            "jobName": "JOB_NAME",
            "containerSpecGcsPath": "TEMPLATE_GCS_PATH",
            "launchOptions": {
                "ft_launch_timeout_secs": "TIMEOUT_SECONDS",
            },
        }
    },
)

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

‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫REGION: האזור ב-Dataflow שבו המשימה פועלת.
‫JOB_NAME: השם של משימת Dataflow.
‫TEMPLATE_GCS_PATH: ה-URI של Cloud Storage של קובץ המפרט של תבנית Flex, למשל gs://my-bucket/templates/my-template.json.
‫TIMEOUT_SECONDS: משך הזמן הקצוב לתפוגה של המכונה הווירטואלית של מרכז האפליקציות, בשניות. צריך לציין מספר שלם חיובי כמחרוזת בלי סיומת של יחידה. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל הוא "720", כלומר 12 דקות. כדי להאריך את הזמן הקצוב לתפוגה, מציינים מספר שלם שגדול מ-720 ועד 5400 (90 דקות), למשל "1200" ל-20 דקות או "1800" ל-30 דקות.

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

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

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

כשמנסים להריץ תבנית ש-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.

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

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

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

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

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

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

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

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

השגיאה הזאת מתרחשת כי ה-VM לא יכול להוריד את חבילת 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.

כדי לפתור את הבעיה, מוסיפים את השורה הבאה לקובץ ה-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 בוחר סוג מכונה כברירת מחדל למכונה הווירטואלית של מרכז האפליקציות, בדרך כלל e2-standard-2. הבחירה הזו לא תלויה ב-machineType של ה-worker. שגיאות של ניצול יתר של משאבים יכולות לקרות אם סוג המכונה שמוגדר כברירת מחדל לא זמין באזור או ב-zone של המשימה. כדי להשתמש בסוג מכונה ספציפי, מגדירים את launcherMachineType.

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

מעדכנים את סוג המכונה של מרכז האפליקציות לסוג מכונה אחר ומנסים שוב להפעיל את המשימה.
- ‫API בארכיטקטורת REST: מגדירים את launchParameter.environment.launcherMachineType ב-method‏ flexTemplates.launch.
- ‫ה-CLI של gcloud: מגדירים את הדגל --launcher-machine-type בפקודה gcloud dataflow flex-template run.
אם הגדרתם את הפרמטר zone, הסירו אותו כדי ש-Dataflow יוכל למקם את ה-VM של מרכז האפליקציות באזור עם קיבולת.
מפעילים את תבנית Flex מאזור אחר.

עיכוב בהפעלה של תבנית 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 ב-GitHub.

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

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

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

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

שגיאות של זמן קצוב לתפוגה של דגימה

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

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

Java

Python

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

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

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

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

בודקים אם תוכנת מרכז האפליקציות לא נסגרת

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

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

איך בודקים אם אפשרויות נדרשות של צינור עיבוד נתונים מבוטלות

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

הארכת זמן הקצוב לתפוגה של הפעלת תבנית Flex

‫CLI של gcloud

‫API בארכיטקטורת REST

Managed Airflow

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

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

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

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

Java

Python

המשך

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

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

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

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

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

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

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

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

תבניות Flex

תבניות מותאמות אישית

ביומני מרכז האפליקציות של תבניות Flex מוצגת רמת חומרה שגויה

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