בעיות מוכרות

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

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

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

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

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

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

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

יכול להיות שממשק המשתמש של Airflow לא יטען מחדש תוסף אחרי שמשנים אותו

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

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

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

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

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

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

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

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

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

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

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

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

תמיכה ב-Kerberos

‫Managed Airflow לא תומך בהגדרת Kerberos ב-Airflow.

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

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

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

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

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

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

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

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

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

מדד השימוש בדיסק של מסד הנתונים לא יורד אחרי שמסירים רשומות מ-Cloud SQL

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

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

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

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

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

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

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

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

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

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

פתרון אפשרי:

  • מסירים את ההחלפה של אפשרות ההגדרה הזו, או מגדירים את הערך שלה ל-False.

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

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

תסמינים:

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

Got error while removing Network Attachment: <error code>

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

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

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

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

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

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

גרסאות של 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

גרסאות של Managed Airflow (Gen 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

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

  • ‫composer-3-airflow-3.1.7-build.7 ואילך
  • ‫composer-3-airflow-2.11.1-build.3 ואילך
  • ‫composer-3-airflow-2.10.5-build.36 ואילך
  • composer-3-airflow-2.9.3-build.54 (contains 2.27.0)
  • ‫composer-2.17.0-airflow-2.11.1 ואילך
  • ‫composer-2.17.0-airflow-2.10.5 ואילך
  • composer-2.16.11-airflow-2.11.1 (contains 2.27.0)
  • ‫composer-2.16.11-airflow-2.10.5 (מכיל 2.27.0)
  • composer-2.16.11-airflow-2.9.3 (contains 2.27.0)

כפתרון עקיף, אפשר להתקין באופן ידני גרסה מאוחרת יותר של חבילת google-api-core בסביבה מושפעת על ידי ציון >=2.30.3 כגרסה הנדרשת.

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

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

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

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

  • שגיאה 404 Not Found: תהליכי העבודה של Airflow מאבדים את המעקב אחרי מופעי המשימות במהלך הפעלה מחדש של לולאת המתזמן הרגילה, שמתרחשת אחרי שהמתזמן מגיע ל-[scheduler]num_runs. השינוי הזה משנה את מזהי המופעים הקיימים של המשימות ויוצר שגיאות 404 עוקבות מעובד שלא מודע לשינוי (#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 לא נמצא: מתזמן שהופעל מחדש מאבד את מצבי המשימות ונכשל בבדיקות הדופק של העובד הפעיל:

    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 או צריכת זיכרון ומעבד גבוהה על ידי מתזמנים.

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

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

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

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