בעיות מוכרות

Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

בדף הזה מפורטות בעיות ידועות ב-Managed Airflow. למידע על תיקוני בעיות, ראו נתוני הגרסה.

הרצת ה-DAG הראשונה של קובץ DAG שהועלה כוללת כמה משימות שנכשלו

כשמעלים קובץ DAG, לפעמים כמה מהמשימות הראשונות מהרצת ה-DAG הראשונה נכשלות ומופיעה השגיאה Unable to read remote log.... הבעיה הזו קורית כי קובץ ה-DAG מסונכרן בין הקטגוריה של הסביבה, ה-workers של Airflow והמתזמנים של Airflow בסביבה. אם המתזמן מקבל את קובץ ה-DAG ומתזמן את ההפעלה שלו על ידי worker, ול-worker עדיין אין את קובץ ה-DAG, הפעלת המשימה תיכשל.

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

‫Managed Airflow לא אמור להיות מושפע מנקודת החולשה של Apache Log4j 2‏ (CVE-2021-44228)

בעקבות נקודת החולשה של Apache Log4j 2‏ (CVE-2021-44228), ביצענו בדיקה מקיפה של Managed Airflow, ואנחנו מאמינים ש-Managed Airflow לא חשוף לניצול לרעה של נקודת החולשה הזו.

לפעמים ממשק המשתמש של Airflow לא טוען מחדש פלאגין אחרי שהוא משתנה

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

שגיאה 504 כשניגשים לממשק המשתמש של Airflow

יכול להיות שתקבלו את השגיאה 504 Gateway Timeout כשתיגשו לממשק המשתמש של Airflow. יכולות להיות כמה סיבות לשגיאה הזו:

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

  • (רק ב-Managed Airflow (דור 3)) בעיה בקישוריות. אם ממשק המשתמש של Airflow לא זמין באופן קבוע, ונוצרות שגיאות של זמן קצוב לתפוגה או שגיאות 504, ודאו שלסביבה שלכם יש גישה אל *.composer.googleusercontent.com.

  • (Managed Airflow (Gen 2) בלבד) בעיה בקישוריות. אם ממשק המשתמש של Airflow לא זמין באופן קבוע, ונוצרות שגיאות של זמן קצוב לתפוגה או שגיאות 504, ודאו שלסביבה שלכם יש גישה אל *.composer.cloud.google.com. אם אתם משתמשים בגישה פרטית ל-Google ושולחים תנועה דרך כתובות IP וירטואליות של private.googleapis.com, או ב-VPC Service Controls ושולחים תנועה דרך כתובות IP וירטואליות של restricted.googleapis.com, ודאו ש-Cloud DNS מוגדר גם לשמות דומיינים של *.composer.cloud.google.com.

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

שגיאה 502 כשניגשים לממשק המשתמש של Airflow

השגיאה 502 Internal server exception מציינת שממשק המשתמש של Airflow לא יכול לטפל בבקשות נכנסות. יכולות להיות כמה סיבות לשגיאה הזו:

  • בעיה זמנית בתקשורת. נסו לגשת לממשק המשתמש של Airflow מאוחר יותר.

  • הפעלת שרת האינטרנט נכשלה. כדי להתחיל, צריך קודם לסנכרן את קובצי התצורה של שרת האינטרנט. בודקים אם יש ביומני שרת האינטרנט רשומות שדומות לאלה: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp או GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. אם השגיאות האלה מופיעות, צריך לבדוק אם הקבצים שמוזכרים בהודעות השגיאה עדיין נמצאים בקטגוריה של הסביבה.

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

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

    2. שינוי אפשרות הגדרה של Airflow. אתם יכולים להשתמש באפשרות הגדרה של Airflow שלא קיימת.

שגיאה 500 כשניגשים לממשק המשתמש של Airflow אחרי שינוי ברירת המחדל של [webserver]analytics_tool

בסביבות עם Airflow 2, אם עוקפים את אפשרות ההגדרה [webserver]analytics_tool של Airflow כדי לנתב נתוני שימוש אנונימיים בממשק המשתמש של Airflow לשירות ניתוח נתונים (כמו Google Analytics,‏ Segment,‏ MetaRouter או Matomo), יכול להיות שהגישה לממשק המשתמש של Airflow אחרי עדכון הסביבה תחזיר תגובה מסוג (500) Internal Server Error, עם אחת מהשגיאות הבאות ביומני שרת האינטרנט של Airflow:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

כשמגדירים את [webserver]analytics_tool ב-Airflow 2, שרת האינטרנט של Airflow דורש להגדיר גם אפשרויות ניתוח נתונים נלוות בקטע [webserver] כשמעבדים את ממשק המשתמש של Airflow.

ב-Airflow 3, אפשרויות ההגדרה [webserver]analytics_tool,‏ [webserver]analytics_id ו-[webserver]analytics_url הוסרו.

פתרונות:

  • מסירים את שינוי ברירת המחדל של אפשרות ההגדרה [webserver]analytics_tool של Airflow, או
  • מציינים את כל אפשרויות ההגדרה הנדרשות של Airflow ביחד:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • ‫[webserver]analytics_url (חובה ב-Airflow מגרסה 2.9 ואילך, גם אם כלי הניתוח לא משתמש בכתובת URL מותאמת אישית)

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

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

תיקיות ריקות ב-Scheduler וב-Workers

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

המלצה: התאימו את ה-DAG כך שיוכלו לדלג על תיקיות ריקות כאלה.

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

תמיכה ב-Kerberos

ב-Managed Airflow אין תמיכה בהגדרות של Airflow Kerberos.

תמיכה במחלקות מחשוב ב-Managed Airflow (דור 2) וב-Managed Airflow (דור 3)

ב-Managed Airflow (דור 3) וב-Managed Airflow (דור 2) יש תמיכה רק בסוג המחשוב למטרות כלליות. כלומר, אי אפשר להריץ Pods שמבקשים מחלקות מחשוב אחרות (כמו Balanced או Scale-Out).

סוג המכונה למטרות כלליות מאפשר להריץ Pods שמבקשים עד 110GB של זיכרון ועד 30 מעבדי CPU (כפי שמתואר בקטע בקשות מקסימליות לסוגי מכונות Compute.

אם אתם רוצים להשתמש בארכיטקטורה שמבוססת על ARM או שאתם צריכים יותר מעבד וזיכרון, אתם צריכים להשתמש בסוג אחר של משאבי מחשוב שלא נתמך באשכולות של Managed Airflow (דור 3) ו-Managed Airflow (דור 2).

המלצה: כדאי להשתמש ב-GKEStartPodOperator כדי להריץ פודים של Kubernetes באשכול אחר שתומך במחלקת המחשוב שנבחרה. אם אתם מריצים Pods בהתאמה אישית שדורשים מחלקת מחשוב אחרת, גם הם צריכים לפעול באשכול שלא מנוהל על ידי Managed Airflow.

אי אפשר להקטין את נפח האחסון ב-Cloud SQL

ב-Managed Airflow נעשה שימוש ב-Cloud SQL כדי להריץ את מסד הנתונים של Airflow. עם הזמן, נפח האחסון בדיסק של מכונת Cloud SQL עשוי לגדול כי הדיסק מותאם לנתונים שמאוחסנים על ידי פעולות של Cloud SQL כשמסד הנתונים של Airflow גדל.

אי אפשר להקטין את גודל הדיסק של Cloud SQL.

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

המדד Database Disk usage לא יורד אחרי הסרת רשומות מ-Cloud SQL

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

גם ב-MySQL וגם ב-Postgres יש מנגנונים להחזרת נפח אחסון אחרי מחיקת רשומות.

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

הגישה חסומה: שגיאת הרשאה

אם הבעיה הזו משפיעה על משתמש, תיבת הדו-שיח הגישה חסומה: שגיאת הרשאה מכילה את ההודעה Error 400: admin_policy_enforced.

אם האפשרות פקדי API > אפליקציות צד שלישי שלא הוגדרו > המשתמשים לא יכולים להיכנס לאפליקציות צד שלישי מופעלת ב-Google Workspace, והאפליקציה Apache Airflow in Managed Airflow לא מורשית באופן מפורש, המשתמשים לא יכולים לגשת לממשק המשתמש של Airflow אלא אם הם מאשרים את האפליקציה באופן מפורש.

כדי לאפשר גישה, מבצעים את השלבים שמפורטים במאמר מתן גישה לממשק המשתמש של Airflow ב-Google Workspace.

לולאת התחברות כשניגשים לממשק המשתמש של Airflow

הסיבות האפשריות לבעיה:

התיקייה ‎/data לא זמינה בשרת האינטרנט של Airflow

ב-Managed Airflow (דור 2) וב-Managed Airflow (דור 3), שרת האינטרנט של Airflow מיועד להיות רכיב לקריאה בלבד, ו-Managed Airflow לא מסנכרן את התיקייה data/ עם הרכיב הזה.

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

הפתרון:

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

  • מוסיפים קבצים לתיקייה plugins/. התיקייה הזו מסונכרנת עם שרת האינטרנט של Airflow.

תרשימים לא רציפים של זמני ניתוח DAG וגודל תיק DAG במעקב

אם בלוח הבקרה למעקב מופיעים תרשימים לא רציפים של זמני הניתוח של ה-DAG ושל גודל ה-DAG bag, סימן שיש בעיות שקשורות לזמני ניתוח ארוכים של ה-DAG (יותר מ-5 דקות).

תרשימים של זמני הניתוח של Airflow DAG וגודל ה-DAG bag, שמציגים סדרה של מרווחים לא רציפים
תרשים 1. תרשימים לא רציפים של זמני ניתוח DAG וגודל תיק DAG (לחצו כדי להגדיל)

פתרון: מומלץ שזמן הניתוח הכולל של ה-DAG יהיה פחות מ-5 דקות. כדי לקצר את זמן הניתוח של DAG, כדאי לפעול לפי ההנחיות לכתיבת DAG.

יומני המשימות מופיעים באיחור

התסמין:

  • ב-Managed Airflow (דור 3), יומני המשימות של Airflow לא מופיעים מיד, אלא בעיכוב של כמה דקות.
  • יכול להיות שיופיעו הודעות Logs not found for Cloud Logging filter ביומני Airflow

הסיבה:

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

פתרונות:

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

זמני הפעלה ארוכים יותר של KubernetesPodOperator ו-KubernetesExecutor

פודים שנוצרו באמצעות KubernetesPodOperator ומשימות שבוצעו באמצעות KubernetesExecutor חווים זמני הפעלה ארוכים יותר. צוות Managed Airflow פועל כדי לפתור את הבעיה ויודיע כשהיא תיפתר.

פתרונות עקיפים:

  • הפעלת Pods עם יותר מעבד (CPU).
  • אם אפשר, כדאי לבצע אופטימיזציה של התמונות (פחות שכבות, גודל קטן יותר).

הסביבה נמצאת במצב שגיאה אחרי שהחשבון לחיוב של הפרויקט נמחק או הושבת, או אחרי שהושבת Cloud Composer API

אי אפשר לשחזר סביבות Managed Airflow שמושפעות מהבעיות האלה:

  • אחרי שהחשבון לחיוב של הפרויקט נמחק או הושבת, גם אם חשבון אחר קושר מאוחר יותר.
  • אחרי ש-Cloud Composer API הושבת בפרויקט, גם אם הוא הופעל מאוחר יותר.

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

  • עדיין אפשר לגשת לנתונים שמאוחסנים בקטגוריות של הסביבה, אבל אי אפשר להשתמש בסביבות עצמן. אתם יכולים ליצור סביבת Managed Airflow חדשה ואז להעביר את ה-DAG והנתונים.

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

יומנים של משימות Airflow לא נאספים אם [core]execute_tasks_new_python_interpreter מוגדר כ-True

ב-Managed Airflow לא נאספים יומנים של משימות Airflow אם אפשרות ההגדרה [core]execute_tasks_new_python_interpreter של Airflow מוגדרת ל-True.

פתרון אפשרי:

שגיאה בהסרת חיבור הרשת כשסביבה נמחקת

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

תסמינים:

השגיאה הבאה נוצרת:

Got error while removing Network Attachment: <error code>

קוד השגיאה שדווח יכול להיות Bad request: <resource> is not ready או Precondition failed: Invalid fingerprint.

פתרונות עקיפים אפשריים:

  • מוחקים את הסביבות שמשתמשות באותו מחבר רשת, אחת אחרי השנייה.

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

ביצועי סביבה ירודים בכמה גרסאות של חבילת google-api-core

גרסאות מ-2.28.0 עד 2.30.2

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

גרסאות build של Managed Airflow (דור 3) שמושפעות:

  • ‫composer-3-airflow-3.1.7-build.0 עד composer-3-airflow-3.1.7-build.5
  • ‫composer-3-airflow-3.1.0-build.5 עד composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • ‫composer-3-airflow-2.10.5-build.22 עד composer-3-airflow-2.10.5-build.33
  • ‫composer-3-airflow-2.9.3-build.42 עד composer-3-airflow-2.9.3-build.53

גרסאות build מושפעות של Managed Airflow (דור 2):

  • composer-2.16.10-airflow-2.11.1
  • מ-composer-2.16.0-airflow-2.10.5 ל-composer-2.16.10-airflow-2.10.5
  • ‫composer-2.16.0-airflow-2.9.3 ל-composer-2.16.10-airflow-2.9.3

לשדרג את הסביבה לאחד מה-builds הבאים, שכוללים את גרסה 2.27.0 של google-api-core שמותקנת מראש ולא מושפעים מהבעיה הזו:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

לחלופין, שדרגו לתמונה שכוללת את google-api-core בגרסה 2.43.1 ואילך, או התקינו ידנית גרסה תואמת.

ב-Python 3.11, גרסאות 2.30.3 עד 2.43.0 של google-api-core גורמות לבעיה נפרדת בביצועים החל מ-24 באוקטובר 2026. אם בסביבה שלכם פועלת גרסה 3.11 של Python, אתם צריכים להשתמש באחד מהפתרונות החלופיים שמפורטים בקטע גרסאות 2.30.3 עד 2.43.0 ב-Python 3.11.

גרסאות 2.30.3 עד 2.43.0 ב-Python 3.11

החל מ-24 באוקטובר 2026, גרסאות 2.30.3 עד 2.43.0 של חבילת google-api-core מריצות בדיקה של הוצאה משימוש של Python 3.11, שסורקת את המטא-נתונים של החבילה המותקנת בכל פעם שספריית לקוח של Google Cloud מיובאת לתהליך משנה חדש של Python.

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

התסמינים כוללים:

  • זמני ניתוח ארוכים יותר של DAG ושימוש גבוה יותר ב-CPU במעבדי Airflow DAG.
  • זמני ביצוע ארוכים יותר של משימות ושימוש גבוה יותר במעבד (CPU) ב-Airflow workers.
  • רשומות יומן תכופות של FutureWarning מ-google/api_core/_python_version_support.py, שבהן מצוין שהתמיכה ב-Python 3.11 תסתיים ב-24 באוקטובר 2027.

הבעיה הזו משפיעה על כל סביבת Python 3.11 שבה גרסה 2.30.3 עד 2.43.0 של google-api-core מותקנת מראש או מותקנת באופן ידני, כולל ה-builds הבאים.

הבעיה משפיעה על הגרסאות הבאות של Managed Airflow (דור 3):

  • ‫composer-3-airflow-3.3.1-build.0 עד composer-3-airflow-3.3.1-build.5
  • ‫composer-3-airflow-3.2.2-build.0 עד composer-3-airflow-3.2.2-build.9
  • ‫composer-3-airflow-3.1.8-build.0 עד composer-3-airflow-3.1.8-build.4
  • ‫composer-3-airflow-3.1.7-build.7 עד composer-3-airflow-3.1.7-build.13
  • ‫composer-3-airflow-2.11.1-build.3 עד composer-3-airflow-2.11.1-build.22
  • ‫composer-3-airflow-2.10.5-build.36 עד composer-3-airflow-2.10.5-build.52

גרסאות build מושפעות של Managed Airflow (דור 2):

  • ‫composer-2.17.0-airflow-2.11.1 עד composer-2.17.16-airflow-2.11.1
  • ‫composer-2.17.0-airflow-2.10.5 עד composer-2.17.13-airflow-2.10.5

פתרונות עקיפים:

בוחרים באחת מהאפשרויות הבאות, בהתאם לגרסת קובץ האימג' של הסביבה:

  • אפשרות 1. גרסאות Managed Airflow (דור 3) תואמות עם Airflow 3 בלבד: מתקינים את חבילת PyPI של google-api-core עם אילוץ הגרסה >=2.43.1.

    גרסאות build תואמות של Managed Airflow (דור 3):

    • ‫composer-3-airflow-3.3.1-build.0 עד composer-3-airflow-3.3.1-build.5
    • ‫composer-3-airflow-3.2.2-build.1 עד composer-3-airflow-3.2.2-build.9
    • ‫composer-3-airflow-3.1.8-build.3 ל-composer-3-airflow-3.1.8-build.4

    אל תשתמשו באפשרות הזו בגרסאות build של Airflow 2 או בגרסאות build קודמות של Airflow 3, כולל composer-3-airflow-3.2.2-build.0 ו-composer-3-airflow-3.1.8-build.0 עד build.2. בגרסאות האלה, גרסה 2.43.1 של google-api-core גורמת להתנגשויות בין יחסי תלות כי היא דורשת את opentelemetry-api>=1.44.0. בגרסאות האלה, צריך להשתמש באפשרות 2.

  • אפשרות 2. כל גרסאות ה-build המושפעות של Managed Airflow (דור 3) ו-Managed Airflow (דור 2): צריך להחיל תיקון בזמן הריצה של sitecustomize.py.

    1. מורידים את sitecustomize.py מ-GitHub.

    2. מעלים את sitecustomize.py לתיקייה dags/patches בקטגוריה של הסביבה.

    3. מגדירים את משתנה הסביבה PYTHONPATH לערך /home/airflow/gcs/dags/patches.

      אם PYTHONPATH כבר מוגדר, צריך להוסיף את /home/airflow/gcs/dags/patches: לפני הערך הקיים. לדוגמה: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    ניקוי אחרי שדרוג: בגרסאות עתידיות של Managed Airflow, חבילת google-api-core בגרסה 2.43.1 ואילך תותקן מראש. אחרי שמשדרגים לתמונה עם google-api-core בגרסה 2.43.1 ואילך, אפשר להסיר את השינוי של PYTHONPATH ולמחוק את dags/patches/sitecustomize.py.

‫TI כבר לא במצב ריצה, המשימה אמורה להסתיים ומופיעות שגיאות Task Not Found ב-Airflow 3

ב-Airflow 3 יש שתי בעיות שקשורות למצב שבו המתזמן מאבד את מצב המשימה במהלך הפעלה מחדש של המתזמן:

  • סטטוס 409 Conflict: מרוץ תהליכים במתזמנים גורם לתזמון מופעים כפולים של משימות (‎#59378, נפתר ב-‎#60330).

    הבעיה הזו תוקנה ב-Airflow 3.2.2.

  • שגיאת 404 Not Found: ה-workers של Airflow מאבדים את המעקב אחרי מופעי המשימות במהלך הפעלה מחדש של לולאת התזמון הרגילה, שמתרחשת אחרי שהתזמון מגיע ל-[scheduler]num_runs. הפעולה הזו משנה את המזהים הקיימים של מופעי המשימות ויוצרת שגיאות 404 עוקבות מ-worker שלא מודע לשינוי (#53140,‏ #60330, נפתר ב-#61631).

    הבעיה הזו תוקנה ב-Airflow 3.3.1.

תסמינים

  • ‫409 Conflict: מצב ניקוי היתומים של מתזמן שהופעל מחדש מסמן משימות פעילות כ-FAILED, מה שגורם לסיום חריג של ה-workers:

    Server indicated the task shouldn't be running anymore [supervisor]
detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')

  • שגיאת 404: מתזמן שהופעל מחדש מאבד את מצבי המשימות ונכשל בבדיקות הדופק של ה-worker הפעיל:

    Server indicated the task shouldn't be running anymore [detail={'detail':
{'reason': 'not_found', 'message': 'Task Instance not found'}}]
[status_code=404] [ti_id=...]

הפתרון:

  • שתי הבעיות תוקנו ב-Airflow מגרסה 3.3.1 ואילך. לשדרג את הסביבה לגרסה שמשתמשת ב-Airflow 3.3.1.

פתרונות עקיפים אפשריים:

  • אי אפשר לצמצם את הבעיה באופן מלא בגרסאות של Airflow שקודמות ל-3.3.1. כל אירוע חיצוני שגורם להפעלה מחדש בלתי צפויה של מתזמן יחיד יפעיל את השגיאות 404 ו-409 (בגרסאות Airflow שקודמות ל-3.2.2). דוגמאות לאירועים כאלה: שדרוגים אוטומטיים של צמתים באשכול של הסביבה, תנאי OOM ב-Pods או צריכה גבוהה של זיכרון ו-CPU על ידי מתזמנים.

  • כדי לצמצם את הגורם למרוצי תהליכים במתזמנים, אפשר להקטין את הסביבה למתזמן אחד ולהגדיר את אפשרות ההגדרה [scheduler]num_runs לערך -1.

    בסביבה עם זמינות גבוהה, אי אפשר להפחית את מספר המתזמנים לאחד. עדיין אפשר להגדיר את [scheduler]num_runs לערך -1.

  • חשוב לוודא שצריכת הזיכרון והמעבד (CPU) של המתזמן נמצאת בטווח מגבלות המשאבים הזמינים.

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