בממשק המעקב של Dataflow אפשר לראות תרשימי מעקב אחרי התאמה אוטומטית לעומס (autoscaling) של משימות סטרימינג. התרשימים האלה מציגים מדדים לאורך משך הזמן של משימת צינור עיבוד הנתונים, וכוללים את הפרטים הבאים:
- מספר ה-worker instances שמשמשות את המשימה בכל נקודת זמן
- קובצי היומן של ההתאמה לעומס (autoscaling)
- הצבר המשוער לאורך זמן
- ניצול המעבד (CPU) הממוצע לאורך זמן
התרשימים מיושרים אנכית כדי שתוכלו לקשר בין מדדי ה-backlog וניצול ה-CPU לבין אירועי התאמה לעומס של ה-workers.
למידע נוסף על האופן שבו Dataflow מקבל החלטות לגבי התאמה אוטומטית לעומס, קראו את מאמרי העזרה תכונות של כוונון אוטומטי. איך משתמשים בממשק המעקב של Dataflow
גישה לתרשימי מעקב אחרי התאמה אוטומטית לעומס (autoscaling)
אפשר לגשת לממשק המעקב של Dataflow באמצעותGoogle Cloud console. כדי לגשת לכרטיסיית המדדים Autoscaling:
- נכנסים למסוף Google Cloud .
- בוחרים את הפרויקט ב- Google Cloud .
- פותחים את תפריט הניווט.
- ב-Analytics, לוחצים על Dataflow. מופיעה רשימה של משימות Dataflow והסטטוס שלהן.
- לוחצים על המשימה שרוצים לעקוב אחריה ואז על הכרטיסייה Autoscaling.
מעקב אחרי מדדי התאמה לעומס (autoscaling)
שירות Dataflow בוחר באופן אוטומטי את מספר המכונות של ה-worker שנדרשות להפעלת משימת ההתאמה לעומס. מספר המכונות של ה-worker יכול להשתנות עם הזמן בהתאם לדרישות של המשימה.
אפשר לראות את מדדי ההתאמה האוטומטית לעומס בכרטיסייה Autoscaling בממשק של Dataflow. כל מדד מאורגן בתרשימים הבאים:
בסרגל הפעולות של ההתאמה האוטומטית מוצגים הסטטוס הנוכחי של ההתאמה האוטומטית ומספר ה-workers.
התאמה אוטומטית לעומס (Automatic scaling)
בתרשים Autoscaling מוצג גרף של סדרת זמנים עם מספר ה-workers הנוכחי, מספר ה-workers המטורגט ומספר ה-workers המינימלי והמקסימלי.
כדי לראות את יומני ההתאמה האוטומטית לעומס, לוחצים על Show autoscaling logs.
כדי לראות את היסטוריית השינויים של ההתאמה האוטומטית לעומס, לוחצים על More history. תוצג טבלה עם מידע על היסטוריית ה-worker של צינור עיבוד הנתונים. ההיסטוריה כוללת אירועי התאמה אוטומטית לעומס, כולל אם מספר ה-workers הגיע למספר המינימלי או המקסימלי של ה-workers.
הסבר על התאמה אוטומטית לעומס (Streaming Engine בלבד)
בתרשים Autoscaling rationale מוצגת הסיבה לכך שהמידרוג האוטומטי הגדיל או הקטין את המשאבים, או לא ביצע פעולות במהלך תקופה נתונה.
כדי לראות תיאור של הנימוק בנקודה מסוימת, מעבירים את הסמן מעל התרשים.
בטבלה הבאה מפורטות פעולות התאמה וסיבות אפשריות להתאמה.
| פעולת התאמה לעומס (scaling) | הסבר לגבי ההנחיה | תיאור |
|---|---|---|
| אין שינוי בקנה המידה | המערכת אוספת עוד נתונים כדי לקבל החלטה | למערכת ההתאמה האוטומטית לעומס אין מספיק אותות כדי להגדיל או להקטין את קנה המידה. לדוגמה, הסטטוס של מאגר ה-workers השתנה לאחרונה, או שהמדדים של צבר המשימות או הניצול משתנים. |
| אין שינוי בהתאמה לעומס, האותות יציבים | הגעתם למגבלה שלא קשורה למשאבים | ההתאמה לעומס מוגבלת על ידי מגבלה כמו התאמה מקבילה של מפתחות או מספר העובדים המינימלי והמקסימלי שהוגדר. |
| הגעת למגבלה שקשורה ללוח הזמנים | ההתאמה לעומס מוגבלת על ידי המספר המינימלי או המקסימלי של ה-workers בלוח הזמנים הפעיל של ההתאמה האוטומטית לעומס. | |
| צבר משימות קטן וניצול גבוה של משאבי העובדים | ההתאמה האוטומטית לעומס של צינור עיבוד הנתונים התכנסה לערך יציב בהתאם לתנועה ולהגדרות הנוכחיות. לא צריך לשנות את קנה המידה. | |
| הגדלה | צבר משימות גדול | אנחנו מגדילים את היקף הפעילות כדי לצמצם את העומס. |
| ניצול גבוה של משאבי ה-worker | הגדלת ההיקף כדי להגיע לניצול היעד של המעבד (CPU). | |
| הגעתם למגבלה שלא קשורה למשאבים | מספר ה-workers המינימלי עודכן, והמספר הנוכחי של ה-workers נמוך מהמינימום שהוגדר. | |
| הגעת למגבלה שקשורה ללוח הזמנים | יש לוח זמנים פעיל להתאמה אוטומטית לעומס, ומספר ה-workers הנוכחי נמוך ממספר ה-workers המינימלי בלוח הזמנים. | |
| צמצום אנכי בהתאם לעומס (scale down) | ניצול נמוך של משאבי העובדים | צמצום אנכי בהתאם לעומס (scale down) כדי להגיע לניצול היעד של המעבד (CPU). |
| הגעתם למגבלה שלא קשורה למשאבים | המספר המקסימלי של ה-workers עודכן, והמספר הנוכחי של ה-workers גבוה מהמקסימום שהוגדר. | |
| הגעת למגבלה שקשורה ללוח הזמנים | יש לוח זמנים פעיל להתאמה אוטומטית של קנה המידה, ומספר ה-workers הנוכחי גבוה ממספר ה-workers המקסימלי בלוח הזמנים. |
ניצול המעבד (CPU) של ה-worker
ניצול המעבד הוא כמות המעבד שנעשה בה שימוש חלקי כמות המעבד שזמינה לעיבוד. בתרשים Mean CPU utilization מוצג ניצול המעבד הממוצע של כל ה-workers לאורך זמן, ההצעה לניצול ה-worker, ואם Dataflow השתמש בהצעה באופן פעיל כיעד.
צבר משימות (מנוע סטרימינג בלבד)
בתרשים Maximum backlog מוצג מידע על רכיבים שממתינים לעיבוד. בתרשים מוצג אומדן של משך הזמן בשניות שנדרש כדי לצרוך את הצבר הנוכחי, אם לא מגיעים נתונים חדשים וקצב הנתונים לא משתנה. הזמן המשוער של צבר המשימות מחושב לפי קצב העברת הנתונים ולפי הבייטים של צבר המשימות ממקור הקלט שעדיין צריך לעבד. התכונה התאמה אוטומטית לעומס (scaling) של סטרימינג משתמשת במדד הזה כדי לקבוע מתי להגדיל או להקטין את העומס.
הנתונים בתרשים הזה זמינים רק למשימות שמשתמשות ב-Streaming Engine. אם משימת הסטרימינג לא משתמשת ב-Streaming Engine, התרשים ריק.
המלצות
ריכזנו כאן כמה התנהגויות שאתם עשויים לראות בצינור עיבוד הנתונים, והמלצות על כוונון ההתאמה האוטומטית לעומס:
הקטנה מוגזמת. אם יעד ניצול ה-CPU גבוה מדי, יכול להיות שתראו דפוס שבו Dataflow מצמצם את מספר ה-workers, הצבר מתחיל לגדול ו-Dataflow מגדיל שוב את מספר ה-workers כדי לפצות על כך, במקום להתכנס למספר יציב של workers. כדי לפתור את הבעיה, נסו להגדיר רמז נמוך יותר לניצול משאבי ה-worker. בודקים את ניצול המעבד (CPU) בנקודה שבה הצבר מתחיל לגדול, ומגדירים את רמז הניצול לערך הזה.
הגדלת הרזולוציה איטית מדי. אם הגדלת ההתאמה האישית איטית מדי, יכול להיות שהיא תפגר אחרי העליות החדות בתנועה, וכתוצאה מכך יהיו תקופות של זמן אחזור מוגבר. נסו להקטין את ההנחיה לניצול ה-worker, כדי ש-Dataflow יגדיל את קנה המידה מהר יותר. בודקים את ניצול המעבד (CPU) בנקודה שבה הצבר מתחיל לגדול, ומגדירים את רמז הניצול לערך הזה. חשוב לעקוב גם אחרי זמן האחזור וגם אחרי העלות, כי ערך רמז נמוך יותר יכול להגדיל את העלות הכוללת של צינור עיבוד הנתונים, אם מוקצים יותר עובדים.
הגדלה מוגזמת. אם אתם מבחינים בהרחבה מוגזמת שגורמת לעלייה בעלויות, כדאי להגדיל את הערך של הרמז לניצול ה-Worker. עוקבים אחרי זמן האחזור כדי לוודא שהוא נשאר בטווחים המקובלים בתרחיש שלכם.
מידע נוסף זמין במאמר הגדרת רמז לניצול משאבי ה-worker. כשאתם מתנסים בערך חדש של רמז לניצול משאבי ה-worker, המתינו כמה דקות עד שהצינור יתייצב אחרי כל התאמה.