בעיות מוכרות

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

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

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

כשמעלים קובץ DAG, לפעמים כמה מהמשימות הראשונות מהרצת ה-DAG הראשונה נכשלות עם השגיאה Unable to read remote log.... הבעיה הזו קורית כי קובץ ה-DAG מסונכרן בין הקטגוריה של הסביבה, ה-Airflow workers וה-Airflow schedulers של הסביבה. אם המתזמן מקבל את קובץ ה-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 (דור שני)) בעיה בקישוריות. אם ממשק המשתמש של 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 (דור 2) וב-Managed Airflow (דור 3) יש תמיכה רק בסוג המחשוב למטרות כלליות. כלומר, אי אפשר להריץ 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 ב-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 bag (לחצו כדי להגדיל)

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

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

גרסאות 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 (דור שני):

  • 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

פתרונות:

כדי לפתור את הבעיה בסביבה קיימת, צריך לשדרג לתמונה שפורסמה ב-6 בנובמבר 2026 או אחרי התאריך הזה (שכוללת את google-api-core בגרסה 2.43.1), לשדרג לאחד מה-builds הבאים (שכוללים את google-api-core בגרסה 2.27.0) או לפעול לפי השלבים לפתרון הבעיה בשירות עצמי שמפורטים בקטע גרסאות מ-2.30.3 עד 2.43.0 ב-Python 3.11:

  • 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

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

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

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

סטטוס:

  • הבעיה תוקנה בגרסאות שפורסמו ב-6 בנובמבר 2026 ואילך: הגרסה google-api-core 2.43.1 מותקנת מראש בתמונות composer-3-airflow-3.3.1-build.6,‏ composer-3-airflow-3.2.2-build.10,‏ composer-3-airflow-2.11.1-build.23,‏ composer-2.17.17-airflow-2.11.1 ובתמונות מאוחרות יותר, והיא מתקנת את הבעיה הזו.
  • קובצי אימג' בסיסיים עם תיקונים לגרסאות build קודמות: קובצי אימג' בסיסיים של קונטיינרים לכל גרסאות ה-build המושפעות שמפורטות בקטע הזה תוקנו בכל האזורים. סביבות שנוצרו לאחרונה לא מושפעות, גם אם יוצרים אותן באמצעות גרסה קודמת.
  • סביבות קיימות: סביבות שנוצרו לפני 5 בנובמבר 2026 ממשיכות להשתמש בקובצי אימג' של קונטיינרים שנשמרו במטמון, עד שהן מתרעננות באמצעות תחזוקה מתוזמנת או אחד משלבי ההפחתה שמפורטים בקטע הזה.

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

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

גרסאות 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.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 (דור שני):

  • ‫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

הפחתת הסיכון בסביבות קיימות:

  • נתיב מהיר ב-asia-east1, asia-northeast2, europe-central2, me-central1, northamerica-northeast1 ו-us-south1: אם הסביבה שלכם כבר השלימה חלון זמן מתוזמן לתחזוקה, הגדירו או עדכנו משתנה סביבה של placeholder כדי להפעיל מחדש את עומסי העבודה של Airflow בתשתית מחשוב מתוקנת:

    gcloud composer environments update ENVIRONMENT_NAME \
  --location LOCATION \
  --update-env-variables=COMPOSER_RELOAD=1

    אחרי שהפעולה מסתיימת, בודקים את יומני הסביבה. אם רשומות של FutureWarning מ-google/api_core/_python_version_support.py ממשיכות להופיע בעומסי עבודה חדשים (לדוגמה, אם התחזוקה המתוזמנת עדיין לא הופעלה או שהפרויקט משתמש ב-VPC Service Controls), צריך להחיל את אחת מהאפשרויות על כל האזורים.

  • כל האזורים: בוחרים אחת מהאפשרויות הבאות:

    • אפשרות 1: שדרוג הסביבה. משדרגים לגרסה שלא מושפעת, כמו composer-3-airflow-3.3.1-build.6,‏ composer-3-airflow-3.2.2-build.10,‏ composer-3-airflow-2.11.1-build.23 או כל גרסה חדשה יותר עם תיקון.

    • אפשרות 2: הפעלת עדכון של חבילת PyPI (נדרשת גישה למאגר PyPI). מעדכנים חבילת PyPI קיימת בהתאמה אישית או מתקינים חבילה נוספת כדי ליצור מחדש את קובץ האימג' של הסביבה מקובץ האימג' הבסיסי המתוקן, ומפעילים מחדש את כל עומסי העבודה של Airflow.

      במכשירים עם גרסאות composer-3-airflow-3.3.1-build.0 עד build.5, composer-3-airflow-3.2.2-build.1 עד build.9 ו-composer-3-airflow-3.1.8-build.3 עד build.4, אפשר להתקין את google-api-core>=2.43.1. אל תתקינו את google-api-core>=2.43.1 בגרסאות קודמות של Airflow 3 (3.2.2-build.0, 3.1.8-build.0 עד build.2, 3.1.7, 3.1.0) או בגרסאות קודמות של Airflow 2, כי נדרש opentelemetry-api>=1.44.0 וזה גורם להתנגשויות בין יחסי תלות. במקום זאת, הפעילו עדכון אחר של חבילת PyPI.

  • אפשרות 3 (פתרון עקיף חלופי בלי לשדרג או לשנות חבילות PyPI): החלת תיקון sitecustomize.py בזמן ריצה. לדוגמה, אם בסביבה שלכם נעשה שימוש ב-VPC Service Controls בלי גישה למאגר PyPI, ואי אפשר לשדרג באופן מיידי:

    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

    ניקוי: אחרי שמשדרגים את הסביבה או בונים מחדש את קובץ האימג' שלה באמצעות השלבים הקודמים, אפשר להסיר את שינוי ברירת המחדל של 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, מה שגורם לעובדים להסתיים באופן חריג:

    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) של המתזמן נמצאת בטווח של מגבלות המשאבים הזמינים.

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