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

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

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

מבוא

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

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

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

מטרות

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

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

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

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

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

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

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

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

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

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

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

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

לוח הבקרה Monitoring במסוףGoogle Cloud מכיל מגוון מדדים ותרשימים שמאפשרים לעקוב אחרי מגמות בסביבה שלכם ולזהות בעיות ברכיבי Airflow ובמשאבי Managed Airflow.

לכל סביבת Managed Airflow יש לוח בקרה משלה למעקב.

כדאי להכיר את מדדי המפתח שבהמשך ולמצוא כל מדד בלוח הבקרה 'מעקב':

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

    מעבר אל Environments

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

  3. עוברים לכרטיסייה מעקב.

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

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

    • כל כמה דקות, Managed Airflow מפעיל DAG של בדיקת פעילות בשם airflow_monitoring. אם הפעלת ה-DAG של בדיקת הפעילות מסתיימת בהצלחה, סטטוס תקינות המערכת הוא True. אם הפעלת ה-DAG של בדיקת הפעילות נכשלת (לדוגמה, בגלל הוצאת Pod, סיום תהליך חיצוני או תחזוקה), סטטוס תקינות המערכת הוא False.

  5. בקטע SQL database, מאתרים את הפריט Database health בלוח הבקרה ומעיינים במדד Database health.

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

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

  6. בפריט Database health (תקינות מסד הנתונים), בודקים את המדדים Database CPU usage (שימוש במעבד של מסד הנתונים) ו-Database memory usage (שימוש בזיכרון של מסד הנתונים).

    • בתרשים השימוש במעבד של מסד הנתונים מוצג השימוש בליבות המעבד על ידי מופעי מסד הנתונים של Cloud SQL בסביבה שלכם, לעומת המגבלה הכוללת של המעבד הזמין של מסד הנתונים.

    • בתרשים 'השימוש בזיכרון של מסד הנתונים' מוצג השימוש בזיכרון על ידי מכונות מסד הנתונים של Cloud SQL בסביבה שלכם, לעומת מגבלת הזיכרון הכוללת שזמינה למסד הנתונים.

  7. בוחרים בקטע Schedulers, מאתרים את הפריט Scheduler heartbeat בלוח הבקרה ומתבוננים במדד Scheduler heartbeat.

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

    • המתזמן נחשב לא תקין אם הפעימה האחרונה התקבלה יותר מ-30 שניות (ערך ברירת המחדל) לפני השעה הנוכחית.

  8. בקטע DAG statistics, מאתרים את הפריט Zombie tasks killed בלוח הבקרה ומעיינים במדד Zombie tasks killed.

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

    • מתזמן המשימות של Airflow מפסיק מדי פעם משימות זומבי, וזה משתקף בתרשים הזה.

  9. בוחרים בקטע Workers (עובדים), מאתרים את הפריט Worker container restarts (הפעלה מחדש של מאגר העובדים) בלוח הבקרה, ומעיינים במדד Worker container restarts (הפעלה מחדש של מאגר העובדים).

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

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

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

  • תקינות הסביבה (DAG של ניטור Airflow)

    • יחס הצלחה של פחות מ-90% במהלך חלון זמן של 4 שעות

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

  • תקינות מסד הנתונים

    • שיעור הצלחה של פחות מ-95% בחלון זמן של 4 שעות

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

  • שימוש במעבד (CPU) ובזיכרון של מסד נתונים

    • יותר מ-80% בממוצע של שימוש במעבד (CPU) או בזיכרון בחלון זמן של 12 שעות

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

  • פעימת לב של מתזמן

    • יחס הצלחה של פחות מ-90% במהלך חלון זמן של 4 שעות

    • מקצים יותר משאבים למתזמן או מגדילים את מספר המתזמנים מ-1 ל-2 (מומלץ).

  • משימות זומבי שהופסקו

    • יותר ממשימת זומבי אחת כל 24 שעות

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

  • הפעלה מחדש של מאגר תגים מסוג Worker

יצירת ערוצי התראות

כדי ליצור ערוץ התראות באימייל, פועלים לפי ההוראות שמפורטות במאמר יצירת ערוץ התראות.

מידע נוסף על ערוצי התראות זמין במאמר בנושא ניהול ערוצי התראות.

יצירת כללי מדיניות התראות

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

המסוף

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

יצירת התראה למדד שמוצג בלוח הבקרה של Monitoring
איור 1. יצירת התראה למדד שמוצג בלוח הבקרה של Monitoring (לחצו להגדלה)

  1. במרכז הבקרה 'מעקב', מאתרים כל מדד שרוצים לעקוב אחריו ולוחצים על סמל הפעמון בפינה של פריט המדד. ייפתח הדף Create alerting policy.

  2. בקטע Transform data (טרנספורמציה של נתונים):

    1. מגדירים את הקטע Within each time series (בכל סדרת זמן) כמו שמתואר בהגדרת מדיניות ההתראות למדד.

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

  3. לוחצים על הבא.

  4. מגדירים את ההתראות. מרחיבים את התפריט Notification channels ובוחרים את ערוצי ההתראות שיצרתם בשלב הקודם.

  5. לוחצים על OK.

  6. בקטע Name the alert policy, ממלאים את השדה Alert policy name. כדאי להשתמש בשם תיאורי לכל אחד מהמדדים. משתמשים בערך של 'מתן שם למדיניות ההתראות' כפי שמתואר בהגדרת מדיניות ההתראות למדד.

  7. לוחצים על הבא.

  8. בודקים את מדיניות ההתראות ולוחצים על Create policy.

מדד של תקינות הסביבה (DAG של מעקב אחרי Airflow) – הגדרות של מדיניות התראות

  • שם המדד: Cloud Composer Environment - Healthy
  • ‫API: composer.googleapis.com/environment/healthy

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון נע: בהתאמה אישית
    • ערך מותאם אישית: 4
    • יחידות בהתאמה אישית: שעה/שעות
    • פונקציית חלון נע: שבר נכון

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מתחת לסף
    • ערך הסף: 90
    • שם התנאי: מצב תקינות הסביבה

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראות: Airflow Environment Health

מדד תקינות של מסד נתונים – הגדרות של מדיניות התראות

  • שם המדד: סביבת Cloud Composer – מסד נתונים תקין
  • ‫API: composer.googleapis.com/environment/database_health

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון מתגלגל: בהתאמה אישית
    • ערך מותאם אישית: 4
    • יחידות בהתאמה אישית: שעה/שעות
    • פונקציית חלון נע: שבר נכון

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מתחת לסף
    • ערך הסף: 95
    • שם התנאי: מצב מסד הנתונים

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראות: Airflow Database Health

מדד השימוש במעבד של מסד הנתונים – הגדרות של מדיניות התראות

  • שם המדד: Cloud Composer Environment - Database CPU Utilization
  • ‫API: composer.googleapis.com/environment/database/cpu/utilization

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון נע: בהתאמה אישית
    • ערך מותאם אישית: 12
    • יחידות בהתאמה אישית: שעה/שעות
    • פונקציית חלון נע: ממוצע

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מעל הסף
    • ערך הסף: 80
    • שם התנאי: תנאי השימוש ביחידת העיבוד המרכזית (CPU) של מסד הנתונים

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים למדיניות ההתראות את השם: Airflow Database CPU Usage

מדד השימוש בזיכרון של מסד הנתונים – הגדרות של מדיניות התראות

  • שם המדד: Cloud Composer Environment - Database Memory Utilization
  • ‫API: composer.googleapis.com/environment/database/memory/utilization

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון נע: בהתאמה אישית
    • ערך מותאם אישית: 12
    • יחידות בהתאמה אישית: שעה/שעות
    • פונקציית חלון נע: ממוצע

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מעל הסף
    • ערך הסף: 80
    • שם התנאי: תנאי לשימוש בזיכרון של מסד נתונים

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראה: Airflow Database Memory Usage

מדד פעימות הלב של מתזמן המשימות – הגדרות של כללי מדיניות התראות

  • שם המדד: Cloud Composer Environment - Scheduler Heartbeats
  • ‫API: composer.googleapis.com/environment/scheduler_heartbeat_count

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון מתגלגל: בהתאמה אישית
    • ערך מותאם אישית: 4
    • יחידות בהתאמה אישית: שעה/שעות
    • פונקציה אנליטית (window function): ספירה

  • הגדרת טריגר להתראה:

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

    • ערך הסף: 216

      1. אפשר לקבל את המספר הזה על ידי הפעלת שאילתה שמצטברת לערך _scheduler_heartbeat_count_mean בMetrics Explorer.

    • שם התנאי: תנאי לבדיקת תקינות של הכלי לתזמון

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראות: Airflow Scheduler Heartbeat

מדד של משימות זומבי שהופסקו – הגדרות של מדיניות התראות

  • שם המדד: Cloud Composer Environment - Zombie Tasks Killed
  • ‫API: ‏ composer.googleapis.com/environment/zombie_task_killed_count

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]

  • שינוי נתונים > בכל סדרת זמן:

    • חלון מתגלגל: יום אחד
    • פונקציה אנליטית (window function): סכום

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מעל הסף
    • ערך הסף: 1
    • שם התנאי: Zombie tasks condition

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראה: Airflow Zombie Tasks

מדד של הפעלה מחדש של מאגר עובדים – הגדרות של מדיניות התראות

  • שם המדד: Kubernetes Container - Restart Count
  • ‫API: kubernetes.io/container/restart_count

  • מסננים:

    environment_name = [ENVIRONMENT_NAME]
location = [CLUSTER_LOCATION]
pod_name =~ airflow-worker-.*|airflow-k8s-worker-.*
container_name =~ airflow-worker|base
cluster_name = [CLUSTER_NAME]

    ‫CLUSTER_NAME הוא שם האשכול בסביבה שלכם, שאפשר למצוא אותו בקטע Environment Configuration (הגדרת הסביבה) > Resources (משאבים) > GKE cluster (אשכול GKE) במסוף Google Cloud .

  • שינוי נתונים > בכל סדרת זמן:

    • חלון מתגלגל: יום אחד
    • פונקציה אנליטית (window function): שיעור

  • הגדרת טריגר להתראה:

    • סוגי התנאים: ערך סף
    • הפעלת התראה: בכל פעם שסדרת נתונים מבוססת זמן מפרה
    • מיקום הסף: מעל הסף
    • ערך הסף: 1
    • שם התנאי: תנאי להפעלה מחדש של קונטיינר של עובד

  • הגדרת התראות וסיום ההגדרה של ההתראה:

    • נותנים שם למדיניות ההתראות: Airflow Worker Restarts

Terraform

מריצים סקריפט של Terraform שיוצר ערוץ התראות באימייל ומעלה מדיניות התראות לגבי המדדים העיקריים שמופיעים במדריך הזה, על סמך נקודות ההשוואה המתאימות:

  1. שומרים את קובץ Terraform לדוגמה במחשב המקומי.

  2. מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט של הפרויקט. לדוגמה, example-project.
    • ‫EMAIL_ADDRESS: כתובת האימייל שצריך לשלוח אליה הודעה אם מופעלת התראה.
    • ‫ENVIRONMENT_NAME: השם של סביבת Managed Airflow. לדוגמה, example-composer-environment.
    • ‫CLUSTER_NAME: שם האשכול של הסביבה, שאפשר למצוא בקטע Environment Configuration (הגדרת סביבה) > Resources (משאבים) > GKE cluster (אשכול GKE) במסוף Google Cloud .
resource "google_monitoring_notification_channel" "basic" {
  project      = "PROJECT_ID"
  display_name = "Test Notification Channel"
  type         = "email"
  labels = {
    email_address = "EMAIL_ADDRESS"
  }
  # force_delete = false
}

resource "google_monitoring_alert_policy" "environment_health_metric" {
  project      = "PROJECT_ID"
  display_name = "Airflow Environment Health"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Environment health condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/healthy\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 0.9
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_FRACTION_TRUE"
      }
    }
  }

}

resource "google_monitoring_alert_policy" "database_health_metric" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database Health"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database health condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database_health\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 0.95
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_FRACTION_TRUE"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_database_cpu_usage" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database CPU Usage"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database CPU usage condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/cpu/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 80
      aggregations {
        alignment_period   = "43200s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_database_memory_usage" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database Memory Usage"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database memory usage condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/memory/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 80
      aggregations {
        alignment_period   = "43200s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_scheduler_heartbeat" {
  project      = "PROJECT_ID"
  display_name = "Airflow Scheduler Heartbeat"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Scheduler heartbeat condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/scheduler_heartbeat_count\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 216 // Threshold is 90% of the average for composer.googleapis.com/environment/scheduler_heartbeat_count metric in an idle environment
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_COUNT"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_zombie_task" {
  project      = "PROJECT_ID"
  display_name = "Airflow Zombie Tasks"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Zombie tasks condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/zombie_task_killed_count\" AND  resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 1
      aggregations {
        alignment_period   = "86400s"
        per_series_aligner = "ALIGN_SUM"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_worker_restarts" {
  project      = "PROJECT_ID"
  display_name = "Airflow Worker Restarts"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Worker container restarts condition"
    condition_threshold {
      filter     = "resource.type = \"k8s_container\" AND (resource.labels.cluster_name = \"CLUSTER_NAME\" AND resource.labels.container_name = monitoring.regex.full_match(\"airflow-worker|base\") AND resource.labels.pod_name = monitoring.regex.full_match(\"airflow-worker-.*|airflow-k8s-worker-.*\")) AND metric.type = \"kubernetes.io/container/restart_count\""

      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 1
      aggregations {
        alignment_period   = "86400s"
        per_series_aligner = "ALIGN_RATE"
      }
    }
  }
}

בדיקת כללי מדיניות התראות

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

העלאה של DAG לדוגמה

ה-DAG לדוגמה memory_consumption_dag.py שמופיע במדריך הזה מחקה ניצול אינטנסיבי של זיכרון העובד. ה-DAG מכיל 4 משימות, וכל אחת מהמשימות כותבת נתונים למחרוזת לדוגמה, וצורכת 380MB של זיכרון. ה-DAG לדוגמה מתוזמן להפעלה כל 2 דקות, והוא יתחיל לפעול אוטומטית אחרי שתעלו אותו לסביבת Composer.

מעלים את ה-DAG לדוגמה הבא לסביבה שיצרתם בשלבים הקודמים:

from datetime import datetime
import sys
import time

from airflow import DAG
from airflow.operators.python import PythonOperator


def ram_function():
    data = ""
    start = time.time()
    for i in range(38):
        data += "a" * 10 * 1000**2
        time.sleep(0.2)
        print(f"{i}, {round(time.time() - start, 4)}, {sys.getsizeof(data) / (1000 ** 3)}")
    print(f"Size={sys.getsizeof(data) / (1000 ** 3)}GB")
    time.sleep(30 - (time.time() - start))
    print(f"Complete in {round(time.time() - start, 2)} seconds!")


with DAG(
    dag_id="memory_consumption_dag",
    start_date=datetime(2023, 1, 1, 1, 1, 1),
    schedule="1/2 * * * *",
    catchup=False,
) as dag:
    for i in range(4):
        PythonOperator(
            task_id=f"task_{i+1}",
            python_callable=ram_function,
            retries=0,
            dag=dag,
        )

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

ממתינים כ-10 דקות אחרי הפעלת ה-DAG לדוגמה ומעריכים את תוצאות הבדיקה:

  1. צריך לבדוק בתיבת הדואר הנכנס אם קיבלתם התראה מ-Google Cloud Alerting עם שורת הנושא שמתחילה ב-[ALERT]. התוכן של ההודעה הזו מכיל את פרטי האירוע של מדיניות ההתראות.

  2. לוחצים על הכפתור הצגת האירוע בהתראה באימייל. תועברו אוטומטית אל Metrics Explorer. בודקים את פרטי האירוע שהפעיל את ההתראה:

    פרטים על האירוע שהפעיל את ההתראה
    איור 2. פרטים על האירוע שהפעיל את ההתראה (לחצו כדי להגדיל)

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

  3. בסביבת Managed Airflow, עוברים לכרטיסייה Monitoring, פותחים את הקטע DAG statistics ומחפשים את התרשים Zombie tasks killed:

    תרשים של משימות עם ביקוש נמוך
    איור 3. גרף של משימות זומבי (לחצו כדי להגדיל)

    הגרף מראה ש-Airflow הפסיק כ-20 משימות זומבי תוך 10 דקות בלבד מהרצת ה-DAG לדוגמה.

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

    פותחים את הקטע Workers (עובדים) בלוח הבקרה Monitoring (מעקב) ובודקים את מדדי השימוש במעבד ובשימוש בזיכרון של העובד:

    מדדים של שימוש במעבד (CPU) ובזיכרון של העובד
    איור 4. מדדי השימוש ב-CPU ובזיכרון של העובד (לחצו כדי להגדיל)

    התרשים Total workers CPU usage (השימוש במעבד של כל העובדים) מצביע על כך שהשימוש במעבד של העובדים היה מתחת ל-50% מהמגבלה הכוללת הזמינה בכל זמן נתון, ולכן המעבד הזמין מספיק. הגרף 'שימוש בזיכרון של העובדים הכולל' מראה שהרצת ה-DAG לדוגמה הובילה להגעה למגבלת הזיכרון שניתן להקצות, ששווה לכמעט 75% ממגבלת הזיכרון הכוללת שמוצגת בגרף (GKE שומר 25% מ-4 הגיגה-בייט הראשונים של הזיכרון ועוד 100 מגה-בייט של זיכרון בכל צומת כדי לטפל בהוצאה של Pod).

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

אופטימיזציה של הסביבה והערכת הביצועים שלה

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

  1. בסביבת Composer, פותחים את הכרטיסייה DAGs, לוחצים על השם של ה-DAG לדוגמה (memory_consumption_dag) ואז לוחצים על Pause DAG.

  2. הקצאת זיכרון נוסף לעובד:

    1. בכרטיסייה Environment configuration (הגדרת הסביבה), מוצאים את ההגדרה Resources (משאבים) > Workloads (עומסי עבודה) ולוחצים על Edit (עריכה).

    2. בפריט Worker, מגדילים את מגבלת הזיכרון. במדריך הזה, נשתמש ב-3.25GB.

    3. שומרים את השינויים וממתינים כמה דקות עד שהתהליך יופעל מחדש.

  3. פותחים את הכרטיסייה DAGs, לוחצים על השם של ה-DAG לדוגמה (memory_consumption_dag) ולוחצים על Unpause DAG.

עוברים אל Monitoring ומוודאים שלא הופיעו משימות זומבי חדשות אחרי שעדכנתם את מכסות המשאבים של העובדים:

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

סיכום

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

הסרת המשאבים

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

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

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

    כניסה לדף Manage resources

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

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

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

המסוף

  1. מחיקת סביבת Managed Airflow במהלך התהליך הזה, נמחק גם הדלי של הסביבה.
  2. מוחקים כל אחת ממדיניות ההתראות שיצרתם ב-Cloud Monitoring.

Terraform

  1. מוודאים שתסריט Terraform לא מכיל רשומות של משאבים שעדיין נדרשים לפרויקט. לדוגמה, יכול להיות שתרצו להשאיר כמה ממשקי API מופעלים והרשאות IAM עדיין מוקצות (אם הוספתם הגדרות כאלה לסקריפט Terraform).
  2. מריצים את terraform destroy.
  3. מוחקים ידנית את הקטגוריה של הסביבה. ‫Managed Airflow לא מוחק אותו באופן אוטומטי. אפשר לעשות את זה דרך מסוף Google Cloud או Google Cloud CLI.

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