Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)
בדף הזה מוסבר איך לעקוב אחרי התקינות והביצועים הכוללים של סביבת Managed Airflow באמצעות מדדים מרכזיים בלוח הבקרה Monitoring.
מבוא
המדריך הזה מתמקד במדדי המעקב המרכזיים של Managed Airflow, שיכולים לספק סקירה כללית טובה של הבריאות והביצועים ברמת הסביבה.
Managed Airflow מציע מדדים רבים שמתארים את המצב הכללי של הסביבה. ההנחיות למעקב במדריך הזה מבוססות על המדדים שמוצגים במרכז הבקרה למעקב של סביבת Managed Airflow שלכם.
במדריך הזה נסביר על המדדים העיקריים שמשמשים כאינדיקטורים העיקריים לבעיות בביצועים ובמצב של הסביבה, וגם על ההנחיות לתרגום כל מדד לפעולות מתקנות כדי לשמור על תקינות הסביבה. תגדירו גם כללי התראה לכל מדד, תפעילו את ה-DAG לדוגמה ותשתמשו במדדים ובהתראות האלה כדי לבצע אופטימיזציה של הביצועים בסביבה שלכם.
מטרות
עלויות
במדריך הזה השתמשנו ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להימנע מחיובים נוספים אחרי שסיימתם את המדריך, תוכלו למחוק את המשאבים שיצרתם. פרטים נוספים זמינים במאמר בנושא הסרת המשאבים.
לפני שמתחילים
בקטע הזה מתוארות פעולות שצריך לבצע לפני שמתחילים את המדריך.
יצירה והגדרה של פרויקט
במדריך הזה תצטרכו Google Cloud פרויקט. מגדירים את הפרויקט באופן הבא:
במסוף Google Cloud , בוחרים פרויקט או יוצרים פרויקט:
מוודאים שהחיוב מופעל בפרויקט. איך בודקים אם החיוב מופעל בפרויקט
כדי ליצור את המשאבים הנדרשים, צריך לוודא שלמשתמש בפרויקט יש את התפקידים הבאים: Google Cloud
- אדמין של סביבה ואובייקטים באחסון
(
roles/composer.environmentAndStorageObjectAdmin) - אדמין ב-Compute (
roles/compute.admin) - עריכה של מעקב (
roles/monitoring.editor)
- אדמין של סביבה ואובייקטים באחסון
(
הפעלת ממשקי API בפרויקט
מפעילים את Managed Airflow API.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים
יצירת סביבת 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 יש לוח בקרה משלה למעקב.
כדאי להכיר את מדדי המפתח שמופיעים בהמשך ולמצוא כל מדד במרכז הבקרה של המעקב:
נכנסים לדף Environments במסוף Google Cloud .
ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details ייפתח.
עוברים לכרטיסייה מעקב.
בוחרים בקטע סקירה כללית, מאתרים את הפריט סקירת הסביבה בלוח הבקרה ומתבוננים במדד תקינות הסביבה (DAG של מעקב אחרי Airflow).
ציר הזמן הזה מציג את תקינות הסביבה של Managed Airflow. הצבע הירוק של סרגל הבריאות של הסביבה מציין שהסביבה תקינה, והצבע האדום מציין שהסביבה לא תקינה.
כל כמה דקות, Managed Airflow מפעיל DAG של בדיקת פעילות שנקרא
airflow_monitoring. אם הפעלת ה-DAG של בדיקת הפעילות מסתיימת בהצלחה, סטטוס תקינות המערכת הואTrue. אם הפעלת ה-DAG של בדיקת הפעילות נכשלת (לדוגמה, בגלל הוצאת Pod, סיום תהליך חיצוני או תחזוקה), סטטוס תקינות המערכת הואFalse.
בוחרים בקטע SQL database, מאתרים את הפריט Database health בלוח הבקרה ומתבוננים במדד Database health.
ציר הזמן הזה מציג את סטטוס החיבור למכונת Cloud SQL של הסביבה שלכם. העמודה הירוקה Database health מציינת קישוריות, ושגיאות בחיבור מצוינות בצבע אדום.
ה-Pod של ניטור Airflow שולח פינג למסד הנתונים באופן תקופתי ומדווח על סטטוס תקינות כ-
Trueאם אפשר ליצור חיבור, או כ-Falseאם אי אפשר.
בפריט Database health (תקינות מסד הנתונים), בודקים את המדדים Database CPU usage (שימוש במעבד של מסד הנתונים) ו-Database memory usage (שימוש בזיכרון של מסד הנתונים).
בתרשים השימוש במעבד של מסד הנתונים מוצג השימוש בליבות המעבד במכונות מסד הנתונים של Cloud SQL בסביבה שלכם, לעומת המגבלה הכוללת של המעבד שזמינה למסד הנתונים.
בתרשים 'השימוש בזיכרון של מסד הנתונים' מוצג השימוש בזיכרון על ידי מכונות מסד הנתונים של Cloud SQL בסביבה שלכם, לעומת מגבלת הזיכרון הכוללת שזמינה למסד הנתונים.
בוחרים בקטע Schedulers, מאתרים את הפריט Scheduler heartbeat בלוח הבקרה ומתבוננים במדד Scheduler heartbeat.
ציר הזמן הזה מציג את התקינות של מתזמן Airflow. כדי לזהות בעיות בתזמון של Airflow, בודקים אם יש אזורים אדומים. אם בסביבה שלכם יש יותר מתזמן אחד, סטטוס פעימת הלב יהיה תקין כל עוד לפחות אחד מהתזמנים מגיב.
המתזמן נחשב לא תקין אם הדופק האחרון התקבל יותר מ-30 שניות (ערך ברירת המחדל) לפני השעה הנוכחית.
בוחרים בקטע DAG statistics, מאתרים את הפריט Zombie tasks killed בלוח הבקרה ומתבוננים במדד Zombie tasks killed.
בתרשים הזה מוצג מספר המשימות הלא פעילות שהופסקו בחלון זמן קצר. משימות זומבי נגרמות לרוב בגלל סיום חיצוני של תהליכי Airflow (למשל, כשמבטלים את התהליך של משימה).
מתזמן המשימות של Airflow מפסיק מדי פעם משימות זומבי, וזה משתקף בתרשים הזה.
בוחרים בקטע Workers (עובדים), מאתרים את הפריט Worker container restarts (הפעלות מחדש של מאגר תגים של עובד) בלוח הבקרה, ומעיינים במדד Worker container restarts (הפעלות מחדש של מאגר תגים של עובד).
- גרף שמציין את המספר הכולל של הפעלה מחדש של קונטיינרים של עובדים בודדים. יותר מדי הפעלות מחדש של מאגרי מידע יכולות להשפיע על הזמינות של השירות שלכם או של שירותים אחרים במורד הזרם שמשתמשים בו כתלות.
השוואה לשוק ופעולות מתקנות אפשריות למדדים מרכזיים
הרשימה הבאה מתארת ערכי השוואה לשוק שיכולים להצביע על בעיות, ומציעה פעולות מתקנות שאפשר לבצע כדי לפתור את הבעיות האלה.
תקינות הסביבה (DAG לניטור Airflow)
יחס הצלחה של פחות מ-90% במהלך חלון זמן של 4 שעות
הכשלים יכולים להיות תוצאה של פינוי Pod או סיום של תהליך worker, כי הסביבה עמוסה מדי או שיש בה תקלות. אזורים אדומים בציר הזמן של תקינות הסביבה בדרך כלל תואמים לאזורים אדומים בסרגלי התקינות האחרים של רכיבי הסביבה האישיים. כדי לזהות את שורש הבעיה, בודקים מדדים אחרים בלוח הבקרה Monitoring.
תקינות מסד הנתונים
שיעור ההצלחה נמוך מ-95% בחלון זמן של 4 שעות
כשלים מצביעים על בעיות בחיבור למסד הנתונים של Airflow, שיכולות להיות תוצאה של קריסת מסד הנתונים או השבתה שלו בגלל עומס יתר (לדוגמה, בגלל שימוש גבוה במעבד או בזיכרון או חביון גבוה יותר בזמן ההתחברות למסד הנתונים). התסמינים האלה נגרמים בדרך כלל מ-DAGs לא אופטימליים, למשל כש-DAGs משתמשים במשתני סביבה או במשתני Airflow רבים שמוגדרים באופן גלובלי. כדי לזהות את שורש הבעיה, בודקים את מדדי השימוש במשאב של מסד הנתונים SQL. אפשר גם לבדוק את יומני המתזמן כדי לראות אם יש שגיאות שקשורות לקישוריות של מסד הנתונים.
שימוש במעבד (CPU) ובזיכרון של מסד הנתונים
יותר מ-80% בממוצע של השימוש במעבד או בזיכרון בחלון זמן של 12 שעות
יכול להיות שעומס היתר על מסד הנתונים. ניתוח המתאם בין הפעלות של DAG לבין עליות חדות בשימוש במעבד או בשימוש בזיכרון של מסד הנתונים.
אפשר להפחית את העומס על מסד הנתונים באמצעות DAG יעילים יותר עם שאילתות וחיבורים מותאמים להפעלה, או באמצעות פיזור העומס בצורה אחידה יותר לאורך זמן.
אפשרות נוספת היא להקצות יותר מעבד או זיכרון למסד הנתונים. המשאבים של מסד הנתונים נשלטים על ידי מאפיין גודל הסביבה של הסביבה שלכם, והסביבה צריכה להיות מוגדלת.
תמונת מצב של מתזמן
יחס הצלחה של פחות מ-90% במהלך חלון זמן של 4 שעות
להקצות יותר משאבים למתזמן או להגדיל את מספר המתזמנים מ-1 ל-2 (מומלץ).
משימות זומבי שהופסקו
יותר ממשימת זומבי אחת כל 24 שעות
הסיבה הנפוצה ביותר למשימות זומבי היא מחסור במשאבי CPU או זיכרון באשכול של הסביבה שלכם. כדאי לבדוק את הגרפים של השימוש במשאבי העובדים ולהקצות יותר משאבים לעובדים, או להגדיל את הזמן הקצוב לתפוגה של משימות זומבי כדי שמנהל התזמון ימתין זמן רב יותר לפני שהוא מחשיב משימה כזומבי.
הפעלה מחדש של מאגר העובדים
יותר מהפעלה מחדש אחת כל 24 שעות
הסיבה הנפוצה ביותר היא חוסר בזיכרון או באחסון של העובד. כדאי לבדוק את צריכת המשאבים של העובדים ולהקצות יותר זיכרון או נפח אחסון לעובדים. אם חוסר משאבים הוא לא הסיבה, כדאי לעיין בפתרון בעיות שקשורות להפעלה מחדש של תהליכי Worker ולהשתמש בשאילתות של רישום ביומן כדי לגלות את הסיבות להפעלה מחדש של תהליכי Worker.
יצירת ערוצי התראות
כדי ליצור ערוץ התראות באימייל, פועלים לפי ההוראות שמפורטות במאמר בנושא יצירת ערוץ התראות.
מידע נוסף על ערוצי התראות זמין במאמר בנושא ניהול ערוצי התראות.
יצירת כללי מדיניות התראות
כדי לעקוב באופן רציף אחרי ערכי המדדים ולקבל התראות כשהמדדים האלה לא עומדים בתנאי מסוים, אתם יכולים ליצור כללי מדיניות התראות על סמך נקודות ההשוואה שמופיעות בקטעים הקודמים של המדריך הזה.
המסוף
כדי להגדיר התראות לכל מדד שמוצג בלוח הבקרה 'מעקב', לוחצים על סמל הפעמון בפינה של הפריט המתאים:
מחפשים כל מדד שרוצים לעקוב אחריו בלוח הבקרה 'מעקב' ולוחצים על סמל הפעמון בפינה של פריט המדד. ייפתח הדף Create alerting policy.
בקטע Transform data (טרנספורמציה של נתונים):
מגדירים את הקטע Within each time series (בכל סדרת זמן) כמו שמתואר בהגדרת מדיניות ההתראות למדד.
לוחצים על הבא, ואז מגדירים את הקטע הגדרת טריגר להתראה כמו שמתואר בהגדרת מדיניות ההתראות למדד.
לוחצים על הבא.
מגדירים את ההתראות. מרחיבים את התפריט Notification channels ובוחרים את ערוצי ההתראות שיצרתם בשלב הקודם.
לוחצים על OK.
בקטע Name the alert policy, ממלאים את השדה Alert policy name. כדאי להשתמש בשם תיאורי לכל אחד מהמדדים. משתמשים בערך של 'Name the alert policy' (מתן שם למדיניות ההתראות) כפי שמתואר בהגדרת מדיניות ההתראות לגבי המדד.
לוחצים על הבא.
בודקים את מדיניות ההתראות ולוחצים על 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 Environment - Database Healthy
- 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) מתגלגלת: count
הגדרת טריגר להתראה:
- סוגי התנאים: סף
- הפעלת ההתראה: כל סדרת נתונים מבוססת זמן שמפרה את
- מיקום הסף: מתחת לסף
ערך הסף: 216
- אפשר לקבל את המספר הזה על ידי הפעלת שאילתה שמצטברת לערך
_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) מתגלגלת: sum
הגדרת טריגר להתראה:
- סוגי התנאים: סף
- הפעלת ההתראה: כל סדרת נתונים מבוססת זמן שמפרה את
- מיקום הסף: מעל הסף
- ערך הסף: 1
- שם התנאי: תנאי משימות זומבי
הגדרת התראות וסיום ההגדרה של ההתראה:
- נותנים שם למדיניות ההתראות: 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 שיוצר ערוץ התראות באימייל ומעלה מדיניות התראות לגבי המדדים העיקריים שמופיעים במדריך הזה, על סמך נקודות ההשוואה המתאימות:
- שומרים את קובץ Terraform לדוגמה במחשב המקומי.
מחליפים את מה שכתוב בשדות הבאים:
-
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,
)
הסבר על התראות ומדדים ב-Monitoring
ממתינים כ-10 דקות אחרי הפעלת ה-DAG לדוגמה ומעריכים את תוצאות הבדיקה:
בודקים בתיבת הדואר הנכנס אם קיבלתם התראה מ-Google Cloud Alerting עם שורת הנושא שמתחילה ב-
[ALERT]. התוכן של ההודעה הזו כולל את פרטי האירוע של מדיניות ההתראות.לוחצים על הלחצן View Incident (הצגת האירוע) בהתראה באימייל. תועברו אוטומטית אל Metrics Explorer. בודקים את פרטי האירוע שהפעיל את ההתראה:
איור 2. פרטים על האירוע שהוביל להתראה (לחצו כדי להגדיל) הגרף של מדדי האירוע מציין שהמדדים שיצרתם חרגו מסף של 1, כלומר Airflow זיהה והפסיק יותר ממשימה אחת מסוג זומבי.
בסביבת Managed Airflow, עוברים לכרטיסייה Monitoring, פותחים את הקטע DAG statistics ומחפשים את התרשים Zombie tasks killed:
איור 3. תרשים של משימות זומבי (לחצו כדי להגדיל) הגרף מראה ש-Airflow הפסיק כ-20 משימות זומבי תוך 10 דקות בלבד מהרצת ה-DAG לדוגמה.
על סמך המדדים ופעולות התיקון, הסיבה הנפוצה ביותר למשימות זומבי היא חוסר בזיכרון או במעבד של העובד. כדי לזהות את שורש הבעיה של משימות זומבי, צריך לנתח את ניצול המשאבים של העובדים.
פותחים את הקטע Workers (עובדים) בלוח הבקרה Monitoring (מעקב) ובודקים את מדדי השימוש במעבד ובשימוש בזיכרון של העובד:
איור 4. מדדי השימוש ב-CPU ובזיכרון של העובד (לחצו כדי להגדיל) התרשים Total workers CPU usage (השימוש במעבד של כל העובדים) מצביע על כך שהשימוש במעבד של העובדים היה מתחת ל-50% מהמגבלה הכוללת הזמינה בכל רגע נתון, ולכן המעבד הזמין מספיק. הגרף 'שימוש בזיכרון של כל העובדים' מראה שהרצת ה-DAG לדוגמה הובילה להגעה למגבלת הזיכרון שניתן להקצות, ששווה לכמעט 75% ממגבלת הזיכרון הכוללת שמוצגת בגרף (GKE שומר 25% מ-4 הגיגה-בייט הראשונים של הזיכרון ועוד 100 מגה-בייט של זיכרון בכל צומת כדי לטפל בהוצאת Pod).
אפשר להסיק שלעובדים חסרים משאבי הזיכרון כדי להריץ את ה-DAG לדוגמה בהצלחה.
אופטימיזציה של הסביבה והערכת הביצועים שלה
על סמך הניתוח של ניצול משאבי העובדים, צריך להקצות יותר זיכרון לעובדים כדי שכל המשימות ב-DAG יצליחו.
בסביבת Composer, פותחים את הכרטיסייה DAGs, לוחצים על שם ה-DAG לדוגמה (
memory_consumption_dag) ואז על Pause DAG.הקצאת זיכרון נוסף לעובד:
בכרטיסייה Environment configuration (הגדרת הסביבה), מוצאים את ההגדרה Resources (משאבים) > Workloads (עומסי עבודה) ולוחצים על Edit (עריכה).
בפריט Worker, מגדילים את מגבלת הזיכרון. במדריך הזה, נשתמש ב-3.25GB.
שומרים את השינויים וממתינים כמה דקות עד שהתהליך יופעל מחדש.
פותחים את הכרטיסייה DAGs, לוחצים על השם של ה-DAG לדוגמה (
memory_consumption_dag) ואז על Unpause DAG.
עוברים אל Monitoring ומוודאים שלא הופיעו משימות זומבי חדשות אחרי שעדכנתם את מגבלות המשאבים של העובד:
סיכום
במדריך הזה למדתם על מדדי התקינות והביצועים העיקריים ברמת הסביבה, איך להגדיר מדיניות התראות לכל מדד ואיך לפרש כל מדד לפעולות מתקנות. לאחר מכן הפעלתם DAG לדוגמה, זיהיתם את שורש הבעיות שמשפיעות על תקינות הסביבה בעזרת התראות ותרשימי מעקב, וביצעתם אופטימיזציה של הסביבה על ידי הקצאת יותר זיכרון לעובדים. עם זאת, מומלץ לבצע אופטימיזציה ל-DAG כדי לצמצם את צריכת המשאבים של העובדים מלכתחילה, כי אי אפשר להגדיל את המשאבים מעבר לסף מסוים.
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים הספציפיים.
מחיקת הפרויקט
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
מחיקת משאבים בודדים
אם אתם מתכננים להיעזר בכמה מדריכי לימוד או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.
המסוף
- מחיקת סביבת Managed Airflow במהלך התהליך הזה, נמחק גם הדלי של הסביבה.
- מוחקים כל אחת ממדיניות ההתראות שיצרתם ב-Cloud Monitoring.
Terraform
- מוודאים שתסריט Terraform לא מכיל רשומות של משאבים שעדיין נדרשים לפרויקט. לדוגמה, יכול להיות שתרצו להשאיר כמה ממשקי API מופעלים והרשאות IAM עדיין מוקצות (אם הוספתם הגדרות כאלה לסקריפט Terraform).
- מריצים את
terraform destroy. - מוחקים ידנית את הקטגוריה של הסביבה. Managed Airflow לא מוחק אותו באופן אוטומטי. אפשר לעשות את זה דרך מסוף Google Cloud או Google Cloud CLI.