בעיות מוכרות

‫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 דקות בין הניסיונות.

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

בתגובה לנקודת החולשה ב-Apache Log4j 2‏ (CVE-2021-44228), ערכנו חקירה מפורטת של 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 ושולחים תעבורה דרך 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 בסביבות לפני שמוחקים אותן. אנחנו ממליצים על הפתרון העקיף הזה למחיקה אוטומטית של סביבות.

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