ניפוי באגים בבעיות ב-DAG שקשורות לחוסר זיכרון או לחוסר נפח אחסון

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

מבוא

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

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

WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.

או

Task exited with return code Negsignal.SIGKILL

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

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

מטרות

  • הפעלת DAG לדוגמה שנכשלת בגלל הסיבות הבאות:

    • חוסר בזיכרון של העובד
    • אין מספיק נפח אחסון לעובדים

  • אבחון הסיבות לכישלון

  • הגדלת המשאבים שהוקצו לעובדים

  • בדיקת ה-DAG עם מגבלות חדשות על משאבים

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Cloud de Confiance by S3NS, והשימוש בהם כרוך בתשלום:

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

לפני שמתחילים

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

יצירה והגדרה של פרויקט

במדריך הזה תצטרכו Cloud de Confiance by S3NS פרויקט. מגדירים את הפרויקט באופן הבא:

  1. במסוף Cloud de Confiance , בוחרים פרויקט או יוצרים פרויקט:

    מעבר לדף לבחירת הפרויקט

  2. מוודאים שהחיוב מופעל בפרויקט. איך בודקים אם החיוב מופעל בפרויקט

  3. צריך לוודא שלמשתמש בפרויקט Cloud de Confiance by S3NS יש את התפקידים הבאים כדי ליצור את המשאבים הנדרשים:

    • אדמין של סביבה ואובייקטים באחסון (roles/composer.environmentAndStorageObjectAdmin)
    • אדמין ב-Compute (roles/compute.admin)
    • עריכה של מעקב (roles/monitoring.editor)

הפעלת ממשקי API בפרויקט

מפעילים את Managed Airflow API, אם הוא עדיין לא מופעל.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

להפעלת ה-API

יצירת סביבת Managed Airflow

איך יוצרים סביבת Managed Airflow (דור 2)

.

במסגרת יצירת הסביבה, מקצים את התפקיד Cloud Composer v2 API Service Agent Extension (roles/composer.ServiceAgentV2Ext) לחשבון של סוכן השירות של Composer. ‫Managed Airflow משתמש בחשבון הזה כדי לבצע פעולות בפרויקט Cloud de Confiance by S3NS שלכם.

בדיקת מגבלות המשאבים של העובדים

בודקים את מגבלות המשאבים של העובדים ב-Airflow בסביבה שלכם:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה Environment configuration (הגדרת הסביבה).

  4. עוברים אל Resources (משאבים) > Workloads configuration (הגדרת עומסי עבודה) > Worker (תהליך עובד).

  5. בודקים שהערכים הם 0.5 vCPUs,‏ 1.875GB זיכרון ו-1GB אחסון. אלה מגבלות המשאבים של Airflow worker שבהן תשתמשו בשלבים הבאים של המדריך הזה.

דוגמה: אבחון בעיות שקשורות לחוסר בזיכרון

מעלים את ה-DAG לדוגמה הבא לסביבה שיצרתם בשלבים הקודמים. במדריך הזה, ה-DAG נקרא create_list_with_many_strings.

ה-DAG הזה מכיל משימה אחת שמבצעת את השלבים הבאים:

  1. יוצר רשימה ריקה s.
  2. מריצים מחזור כדי להוסיף את המחרוזת More לרשימה.
  3. הפונקציה מדפיסה כמה זיכרון הרשימה צורכת וממתינה שנייה אחת בכל איטרציה של דקה אחת.
import time

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import sys
from datetime import timedelta

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_list_with_many_strings',
    default_args=default_args,
    schedule=None)


def consume():
    s = []
    for i in range(120):
        for j in range(1000000):
            s.append("More")
        print(f"i={i}; size={sys.getsizeof(s) / (1000**3)}GB")
        time.sleep(1)


t1 = PythonOperator(
    task_id='task0',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0
)

הפעלת ה-DAG לדוגמה

מפעילים את ה-DAG לדוגמה, create_list_with_many_strings:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. בעמודה Airflow webserver, לוחצים על הקישור Airflow של הסביבה.

  3. בממשק המשתמש של Airflow, בדף DAGs, לוחצים על הלחצן Trigger DAG (הפעלת DAG) ליד ה-DAG הרצוי.

  4. לוחצים על Trigger (טריגר).

  5. בדף DAGs (תרשימי זרימה מכווני מחזורים), לוחצים על המשימה שהפעלתם ובודקים את יומני הפלט כדי לוודא שה-DAG התחיל לפעול.

בזמן שהמשימה פועלת, ביומני הפלט מודפס גודל הזיכרון ב-GB שבו משתמש ה-DAG.

אחרי כמה דקות, המשימה תיכשל כי היא חורגת ממגבלת הזיכרון של תהליך העבודה של Airflow, שהיא 1.875GB.

אבחון של DAG שנכשל

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

בדיקת יומני המשימות של Airflow

שימו לב שהמשימה מ-DAG‏ create_list_with_many_strings נמצאת במצב Failed.

בודקים את היומנים של המשימה. תופיע רשומת היומן הבאה:

```none
{local_task_job.py:102} INFO - Task exited with return code
Negsignal.SIGKILL
```

`Netsignal.SIGKILL` might be an indication of your task using more memory
than the Airflow worker is allocated. The system sends
the `Negsignal.SIGKILL` signal to avoid further memory consumption.

בדיקת עומסי עבודה

בודקים את עומסי העבודה כדי לוודא שהעומס של המשימה לא גורם לחריגה ממגבלת צריכת הזיכרון בצומת שבו פועל ה-Pod:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה Environment configuration (הגדרת הסביבה).

  4. בקטע משאבים > אשכול GKE > עומסי עבודה, לוחצים על הצגת עומסי עבודה באשכול.

  5. בודקים אם לחלק מהפודים של עומס העבודה יש סטטוסים שדומים לסטטוסים הבאים:

    Error with exit code 137 and 1 more issue.
ContainerStatusUnknown with exit code 137 and 1 more issue

    Exit code 137 פירושו שקונטיינר או Pod מנסים להשתמש בזיכרון גדול יותר מהמותר. התהליך מסתיים כדי למנוע שימוש בזיכרון.

בדיקת המצב של הסביבה ומעקב אחרי צריכת המשאבים

בדיקת תקינות הסביבה ומעקב אחרי צריכת המשאבים:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה מעקב ובוחרים באפשרות סקירה כללית.

  4. בחלונית Environment overview, מאתרים את התרשים Environment Health (Airflow Monitoring DAG). הוא מכיל אזור אדום, שמתאים לזמן שבו היומנים התחילו להדפיס שגיאות.

  5. בוחרים באפשרות תהליכי עבודה ומחפשים את התרשים השימוש הכולל בזיכרון של תהליכי העבודה. אפשר לראות שבגרף Memory usage יש עלייה חדה בזמן שהמשימה פעלה.

בקו של השימוש בזיכרון יש עלייה חדה בזמן שהמשימה פעלה.
איור 1. גרף של השימוש בזיכרון של כל העובדים (אפשר ללחוץ כדי להגדיל)

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

הגדלת מגבלת הזיכרון של העובד

כדי ש-DAG לדוגמה יפעל בהצלחה, צריך להקצות זיכרון נוסף לעובד:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה Environment configuration (הגדרת הסביבה).

  4. מחפשים את ההגדרה Resources (משאבים) > Workloads (עומסי עבודה) ולוחצים על Edit (עריכה).

  5. בקטע Worker, בשדה Memory, מציינים את מגבלת הזיכרון החדשה של עובדי Airflow. במדריך הזה נשתמש ב-3GB.

  6. שומרים את השינויים וממתינים כמה דקות עד שהעובדים של Airflow יופעלו מחדש.

בדיקת ה-DAG עם מגבלת הזיכרון החדשה

מפעילים שוב את ה-DAG‏ create_list_with_many_strings ומחכים עד שהוא מסיים לפעול.

  1. ביומני הפלט של הפעלת ה-DAG, יופיע Marking task as SUCCESS, והמצב של המשימה יהיה Success.

  2. בודקים את הקטע סקירת הסביבה בכרטיסייה מעקב ומוודאים שאין אזורים אדומים.

  3. לוחצים על הקטע Workers ומחפשים את התרשים Total workers memory usage. בשורה Memory limit (מגבלת זיכרון) יופיע השינוי במגבלת הזיכרון, והשורה Memory usage (השימוש בזיכרון) תהיה הרבה מתחת למגבלת הזיכרון בפועל שאפשר להקצות.

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

בשלב הזה מעלים שני DAG שיוצרים קבצים גדולים. ה-DAG הראשון יוצר קובץ גדול. ה-DAG השני יוצר קובץ גדול ומדמה פעולה ממושכת.

גודל הקובץ בשני ה-DAG חורג ממגבלת האחסון של העובד ב-Airflow, שהיא 1GB כברירת מחדל, אבל ל-DAG השני יש משימת המתנה נוספת כדי להאריך את משך הזמן שלו באופן מלאכותי.

בשלבים הבאים תבדקו את ההבדלים בהתנהגות של שני ה-DAG.

העלאה של DAG שיוצר קובץ גדול

מעלים את ה-DAG לדוגמה הבא לסביבה שיצרתם בשלבים הקודמים. במדריך הזה, ה-DAG נקרא create_large_txt_file_print_logs.

ה-DAG הזה מכיל משימה אחת שמבצעת את השלבים הבאים:

  1. כתיבת קובץ בנפח 1.5GB‏ localfile.txt לאחסון של Airflow worker.
  2. מדפיס את הגודל של הקובץ שנוצר באמצעות מודול Python‏ os.
  3. הפונקציה מדפיסה את משך ההפעלה של ה-DAG כל דקה.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_large_txt_file_print_logs',
    default_args=default_args,
    schedule=None)


def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    print("Success!")


t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

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

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

ה-DAG הזה מכיל משימה אחת שמבצעת את השלבים הבאים:

  1. כתיבת קובץ בנפח 1.5GB‏ localfile.txt לאחסון של Airflow worker.
  2. מדפיס את הגודל של הקובץ שנוצר באמצעות מודול Python‏ os.
  3. ההמתנה היא של שעה ו-15 דקות כדי לדמות את הזמן שנדרש לפעולות בקובץ, למשל קריאה מהקובץ.
  4. הפונקציה מדפיסה את משך ההפעלה של ה-DAG כל דקה.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'long_running_create_large_txt_file_print_logs',
    default_args=default_args,
    schedule=None)


def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    for k in range(75):
        time.sleep(60)
        print(f"{k+1} minute")

    print("Success!")


t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

הפעלת DAG לדוגמה

מפעילים את ה-DAG הראשון, create_large_txt_file_print_logs:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. בעמודה Airflow webserver, לוחצים על הקישור Airflow של הסביבה.

  3. בממשק המשתמש של Airflow, בדף DAGs, לוחצים על הלחצן Trigger DAG (הפעלת DAG) ליד ה-DAG הרצוי.

  4. לוחצים על Trigger (טריגר).

  5. בדף DAGs (תרשימי זרימה מכווני מחזורים), לוחצים על המשימה שהפעלתם ובודקים את יומני הפלט כדי לוודא שה-DAG התחיל לפעול.

  6. מחכים עד שהמשימה שיצרתם באמצעות create_large_txt_file_print_logs DAG תסתיים. הפעולה עשויה להימשך כמה דקות.

  7. בדף DAGs, לוחצים על הרצת ה-DAG. המשימה תופיע עם הסטטוס Success, גם אם חרגתם ממכסת האחסון.

בודקים את יומני Airflow של המשימה:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

    1. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

    2. עוברים לכרטיסייה Logs (יומנים), ואז אל All logs (כל היומנים) > Airflow logs (יומני Airflow) > Workers (תהליכי עבודה) > View in Logs Explorer (הצגה ב-Logs Explorer).

    3. מסננים את היומנים לפי סוג: הצגת הודעות שגיאה בלבד.

ביומנים יופיעו הודעות דומות לאלה:

Worker: warm shutdown (Main Process)

או

A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

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

כדי להמחיש את המושג של תקופת החסד לסיום, כדאי לעיין בתוצאה של ה-DAG השני לדוגמה, long_running_create_large_txt_file_print_logs.

מפעילים את ה-DAG השני, long_running_create_large_txt_file_print_logs:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. בעמודה Airflow webserver, לוחצים על הקישור Airflow של הסביבה.

  3. בממשק המשתמש של Airflow, בדף DAGs, לוחצים על הלחצן Trigger DAG (הפעלת DAG) ליד ה-DAG הרצוי.

  4. לוחצים על Trigger (טריגר).

  5. בדף DAGs (תרשימי זרימה מכווני מחזורים), לוחצים על המשימה שהפעלתם ובודקים את יומני הפלט כדי לוודא שה-DAG התחיל לפעול.

  6. מחכים עד שהרצת ה-DAG‏ long_running_create_large_txt_file_print_logs תיכשל. התהליך יימשך כשעה.

מעיינים בתוצאות של הרצת ה-DAG:

  1. בדף DAGs (תרשימי DAG), לוחצים על long_running_create_large_txt_file_print_logs הרצת DAG. אפשר לראות שהמשימה במצב Failed, ומשך ההרצה היה בדיוק שעה ו-5 דקות, שזה פחות מתקופת ההמתנה של המשימה (שעה ו-15 דקות).

  2. בודקים את היומנים של המשימה. אחרי ש-DAG יוצר את הקובץ localfile.txt במאגר של Airflow worker, ביומן מודפס ש-DAG התחיל להמתין, ומשך ההרצה מודפס ביומני המשימות כל דקה. בדוגמה הזו, ה-DAG מדפיס את היומן localfile.txt size: והגודל של הקובץ localfile.txt יהיה 1.5GB.

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

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

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

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

אבחון של DAG שנכשל

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

בודקים את יומני המשימות של ה-DAG השני, long_running_create_large_txt_file_print_logs:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה Logs (יומנים), ואז אל All logs (כל היומנים) > Airflow logs (יומני Airflow) > Workers (תהליכי עבודה) > View in Logs Explorer (הצגה ב-Logs Explorer).

  4. מסננים את היומנים לפי סוג: הצגת הודעות שגיאה בלבד.

ביומנים יופיעו הודעות דומות לאלה:

Container storage usage of worker reached 155.7% of the limit.

This likely means that the total size of local files generated by your DAGs is
close to the storage limit of worker.

You may need to decrease the storage usage or increase the worker storage limit
in your Cloud Composer environment configuration.

או

Pod storage usage of worker reached 140.2% of the limit.
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

This eviction likely means that the total size of dags and plugins folders plus
local files generated by your DAGs exceeds the storage limit of worker.

Please decrease the storage usage or increase the worker storage limit in your
Cloud Composer environment configuration.

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

בדיקת תקינות הסביבה ומעקב אחרי צריכת המשאבים:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה מעקב ובוחרים באפשרות סקירה כללית.

  4. בחלונית Environment overview, מאתרים את התרשים Environment Health (Airflow Monitoring DAG). הוא מכיל אזור אדום, שמתאים לזמן שבו היומנים התחילו להדפיס שגיאות.

  5. בוחרים באפשרות Workers ומחפשים את התרשים Total workers disk usage. שימו לב שבשורה Disk usage יש עלייה חדה והיא חורגת מהשורה Disk limit בזמן שהמשימה פעלה.

בזמן שהמשימה פעלה, הקו Disk usage (שימוש בדיסק) הגיע לנקודת שיא ועבר את הקו Disk limit (מגבלת הדיסק)
איור 2. גרף של השימוש בדיסק של כל העובדים (לחצו כדי להגדיל)

הגדלת מגבלת האחסון של העובד

כדי שדוגמת ה-DAG תצליח, צריך להקצות עוד נפח אחסון לעובד Airflow:

  1. נכנסים לדף Environments במסוף Cloud de Confiance .

    מעבר אל Environments

  2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details נפתח.

  3. עוברים לכרטיסייה Environment configuration (הגדרת הסביבה).

  4. מחפשים את ההגדרה Resources (משאבים) > Workloads (עומסי עבודה) ולוחצים על Edit (עריכה).

  5. בקטע Worker, בשדה Storage, מציינים את מגבלת האחסון החדשה לעובדי Airflow. במדריך הזה, מגדירים את הערך ל-2GB.

  6. שומרים את השינויים וממתינים כמה דקות עד שהעובדים של Airflow יופעלו מחדש.

בדיקת ה-DAG עם מגבלת האחסון החדשה

מפעילים שוב את long_running_create_large_txt_file_print_logs DAG ומחכים שעה ו-15 דקות עד לסיום ההפעלה.

  1. בפלט של יומני ההפעלה של ה-DAG, יופיע Marking task as SUCCESS, והמצב של המשימה יהיה Success, עם משך של שעה ו-15 דקות, ששווה לזמן ההמתנה שהוגדר בקוד ה-DAG.

  2. בודקים את הקטע סקירת הסביבה בכרטיסייה מעקב ומוודאים שאין אזורים אדומים.

  3. לוחצים על הקטע Workers ומחפשים את התרשים Total workers disk usage. אפשר לראות שהשינוי במגבלת האחסון משתקף בשורה Disk limit, והשורה Disk usage נמצאת בטווח המותר.

סיכום

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

הסרת המשאבים

כדי להימנע מחיובים בחשבון Cloud de Confiance by S3NS על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים הספציפיים.

מחיקת הפרויקט

  1. במסוף Cloud de Confiance , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת משאבים בודדים

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

מחיקת סביבת Managed Airflow במהלך התהליך הזה, נמחק גם הדלי של הסביבה.

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