מדדי משימות ב-Dataflow

‫Dataflow אוסף מדדים לגבי העבודות שלכם, שיכולים לעזור לכם לנפות באגים, לפתור בעיות בביצועים או לבצע אופטימיזציה של צינור הנתונים. בממשק המעקב של Dataflow מוצגות המחשות של המדדים האלה. אפשר גם להשתמש ב-Cloud Monitoring כדי ליצור התראות או ליצור שאילתות ב-Metrics Explorer.

גישה למדדי משימות

כדי לראות את מדדי העבודה של משימה, מבצעים את השלבים הבאים:

1. במסוף Google Cloud , נכנסים לדף Dataflow‏ > Jobs.

   מעבר אל Jobs

2. בוחרים משרה.

3. לוחצים על הכרטיסייה מדדי משרות.

4. בוחרים מדד להצגה.

5. כדי לגשת למידע נוסף בתרשימים של מדדי המשרות, לוחצים על ניתוח נתונים.

כל מדד מאורגן בלוחות הבקרה הבאים:

• מדדים להתאמה אוטומטית של נפח התעבורה
• מדדים של סקירה כללית
• מדדי סטרימינג
• מדדי משאבים
• מדדי קלט/פלט

רשימה מלאה של מדדי Dataflow זמינה במאמר בנושא מדדים של Dataflow.Google Cloud

תמיכה ומגבלות

כשמשתמשים במדדים של Dataflow, חשוב לשים לב לפרטים הבאים.

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

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

• כדי לכתוב נתונים של מדדים, לחשבון שירות שמנוהל על ידי המשתמש צריכה להיות הרשאת IAM API‏ monitoring.timeSeries.create. ההרשאה הזו כלולה בתפקיד של עובד Dataflow.

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

מדדים להתאמה אוטומטית לעומס

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

בקטע Autoscaling בכרטיסייה Job metrics מוצג מספר העובדים ומספר העובדים היעד לאורך זמן. אם העבודה משתמשת ב-Streaming Engine, מוצגים גם המספר המינימלי והמקסימלי של העובדים.

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

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

מדדים בדף הסקירה הכללית

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

עדכניות הנתונים

המדד הזה רלוונטי רק לעבודות סטרימינג.

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

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

אם חלק מנתוני הקלט עדיין לא עברו עיבוד, יכול להיות שסימן המים של הפלט יופיע באיחור, מה שישפיע על רעננות הנתונים. הבדל משמעותי בין הזמן של סימן המים לבין הזמן של האירוע עשוי להצביע על פעולה איטית או תקועה. מידע נוסף זמין במאמר Watermarks and late data (סימני מים ונתונים מאוחרים) במסמכי התיעוד של Apache Beam.

מרכז הבקרה כולל את שני התרשימים הבאים:

• עדכניות הנתונים לפי שלבים
• עדכניות הנתונים

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

הבעיות הבאות עשויות לגרום לערכים גבוהים במדד הזה:

• צווארי בקבוק בביצועים: אם יש שלבים בצינור עם זמן אחזור גבוה במערכת או יומנים שמצביעים על טרנספורמציות תקועות, יכול להיות שיש בעיות בביצועים של צינור הנתונים, שיכולות להשפיע על עדכניות הנתונים. כדי לבדוק את הבעיה לעומק, אפשר לעיין במאמר בנושא פתרון בעיות של עבודות סטרימינג איטיות או תקועות.
• צווארי בקבוק במקורות הנתונים: אם יש לכם עומס הולך וגדל של נתונים במקורות הנתונים, יכול להיות שחותמות הזמן של האירועים של הרכיבים יהיו שונות מסימן המים כי הם ממתינים לעיבוד. בדרך כלל, הצטברות גדולה של נתונים נובעת מבעיות בביצועים או מבעיות במקור הנתונים. הדרך הכי טובה לזהות את הבעיות האלה היא לעקוב אחרי המקורות שבהם נעשה שימוש בצינור עיבוד הנתונים.
  • מקורות לא מסודרים כמו Pub/Sub יכולים ליצור סימני מים תקועים גם כשהם פולטים נתונים בקצב גבוה. המצב הזה קורה כי הפלט של הרכיבים לא מסודר לפי חותמת הזמן, וסימן המים מבוסס על חותמת הזמן המינימלית שלא עברה עיבוד.
• ניסיונות חוזרים תכופים: אם מופיעות שגיאות שמציינות שרכיבים לא עברו עיבוד ונעשה ניסיון חוזר לעיבוד שלהם, יכול להיות שחותמות הזמן הישנות יותר של הרכיבים האלה גורמות לבעיה של רעננות הנתונים. רשימת השגיאות הנפוצות ב-Dataflow יכולה לעזור לכם לפתור בעיות.

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

זמן האחזור של המערכת

המדד הזה רלוונטי רק לעבודות סטרימינג.

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

במקרים הבאים יש שיקולים נוספים:

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

מרכז הבקרה כולל את שני התרשימים הבאים:

• זמן האחזור של המערכת לפי שלבים
• זמן האחזור של המערכת

תפוקה

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

• התפוקה לכל שלב באלמנטים לשנייה
• קצב העברת הנתונים לכל שלב בבייט לשנייה

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

במדד Worker error log count מוצג שיעור השגיאות שנצפו בכל העובדים בכל נקודת זמן.

מדדי סטרימינג

המדדים הבאים מופיעים בקטע מדדי סטרימינג.

Backlog

המדד הזה רלוונטי רק לעבודות סטרימינג.

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

• Backlog seconds (שניות של עומס יתר) (Streaming Engine בלבד)
• בייט של נתונים שממתינים לעיבוד (עם Streaming Engine ובלי)

בתרשים Backlog seconds מוצגת הערכה של משך הזמן בשניות שיידרש כדי לצרוך את ה-backlog הנוכחי אם לא יגיעו נתונים חדשים וקצב העברת הנתונים לא ישתנה. זמן הטיפול המשוער בבקשות שעדיין לא טופלו מחושב על סמך קצב העברת הנתונים והנתונים שעדיין לא עברו עיבוד ממקור הקלט. המדד הזה משמש את התכונה שינוי גודל אוטומטי של סטרימינג כדי לקבוע מתי להגדיל או להקטין את קצב הנתונים.

בתרשים Backlog bytes מוצג נפח הקלט הידוע שלא עבר עיבוד בשלב מסוים, בבייטים. המדד הזה משווה בין הבייטים שנותרו לשימוש בכל שלב לבין השלבים במעלה הזרם. כדי שהמדד הזה ידווח בצורה מדויקת, צריך להגדיר נכון כל מקור שמוזן לצינור. מקורות מובנים כמו Pub/Sub ו-BigQuery כבר נתמכים מחוץ לקופסה, אבל מקורות בהתאמה אישית דורשים הטמעה נוספת. פרטים נוספים זמינים במאמר בנושא שינוי גודל אוטומטי של מקורות מותאמים אישית ללא הגבלה.

בטיפול

המדד הזה רלוונטי רק לעבודות סטרימינג.

כשמריצים פייפליין של Apache Beam בשירות Dataflow, משימות הפייפליין רצות במכונות וירטואליות של עובדים. בלוח הבקרה Processing מוצג מידע על משך הזמן שבו המשימות עובדו במכונות הווירטואליות של העובדים. מרכז הבקרה כולל את שני התרשימים הבאים:

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

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

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

בתרשים User processing latencies by stage מוצג האחוזון ה-99 של כל המשימות שהעובדים מעבדים, בחלוקה לפי שלב. אם קוד המשתמש גורם לצוואר בקבוק, בתרשים הזה מוצג השלב שבו נוצר צוואר הבקבוק. כדי לנפות באגים בצינור, אפשר לפעול לפי השלבים הבאים:

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

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

3. כדי למצוא את פעולות המשתמש שמשויכות לשלב הזה, לוחצים על הצומת של השלב הזה בתרשים.

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

זמן לכל מצב של פריט עבודה פעיל

המדד הזה רלוונטי רק לעבודות סטרימינג.

המדד Time per active work item state (worker/time_per_active_work_item_state) מספק מידע על זמן האחזור של השלבים העיקריים במחזור החיים של פריט עבודה. בניגוד למדדים מצטברים ברמה גבוהה, ההערכה הזו מאפשרת לכם לשייך את זמן האחזור באופן מדויק על ידי פירוק זמני האחזור ברמת השלב לפאזות נפרדות. לדוגמה, אפשר לבדוק את זמן האחזור לפי שלבים כמו אחזור נתונים (READ), הרצת קוד משתמש (ACTIVE) ושמירת מצב (COMMIT).

תמיכה בגרסאות של Runner

המדד נתמך באופן מלא ב-Streaming Java Runner, אבל יש תמיכה חלקית ב-Portable Runner.

בטבלה הזו מפורטים מצבי השהיה והתמיכה בהם לפי רץ.

סטטוס זמן האחזור	תמיכה בהפעלת Java בסטרימינג	תמיכה ב-Portable Runner
GET_WORK	נתמך	לא נתמך
QUEUED	נתמך	נתמך
ACTIVE	נתמך	נתמך
READ	נתמך	נתמך
COMMIT	נתמך	נתמך

הגדרות של מצב זמן האחזור ופתרון בעיות

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

GET_WORK

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

QUEUED

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

ACTIVE

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

READ

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

COMMIT

• זהו הזמן שנדרש לשליחת התוצאות (עדכוני מצב ורכיבי פלט) ל-Dataflow backend ולקבלת אישור.
• זמן COMMIT גבוה נובע לרוב מכתיבה של מטען ייעודי גדול או מעדכון של אובייקטים גדולים של מצב. בודקים אם יש מקשי קיצור באמצעות סטטוס צוואר הבקבוק.

מקביליות

המדד הזה רלוונטי רק לעבודות של Streaming Engine.

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

כשמריצים צינור עיבוד נתונים ב-Dataflow, העיבוד מתבצע במקביל בכמה מכונות וירטואליות (VM) של Compute Engine, שנקראות גם עובדים (workers). שירות Dataflow מבצע אוטומטית הקבלה וחלוקה של לוגיקת העיבוד בצינור אל העובדים. העיבוד של כל מפתח נתון הוא סדרתי, ולכן המספר הכולל של מפתחות בשלב מסוים מייצג את המקביליות המקסימלית הזמינה בשלב הזה.

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

התמדה

המדד הזה רלוונטי רק לעבודות סטרימינג.

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

מרכז הבקרה כולל את שני התרשימים הבאים:

• כתיבת אחסון
• קריאת אחסון

כפילויות

המדד הזה רלוונטי רק לעבודות סטרימינג.

בתרשים כפילויות מוצג מספר ההודעות שעוברות עיבוד בשלב מסוים, שסוננו ככפילויות. ‫Dataflow תומך במקורות ובמאגרי נתונים רבים שמבטיחים at least once מסירה. החיסרון של משלוח at least once הוא שהוא עלול לגרום לכפילויות. ‫Dataflow משתמש בשיטת מסירה exactly once, כלומר כפילויות מסוננות באופן אוטומטי. השלבים הבאים נשמרים מעיבוד מחדש של אותם רכיבים, וכך מוודאים שהמצב והפלט לא מושפעים. אפשר לבצע אופטימיזציה של הצינור כדי לשפר את המשאבים והביצועים על ידי צמצום מספר הכפילויות שנוצרות בכל שלב.

טיימרים

המדד הזה רלוונטי רק לעבודות סטרימינג.

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

מרכז הבקרה כולל את שני התרשימים הבאים:

• טיימרים בהמתנה לפי שלב
• עיבוד של טיימרים לפי שלב

בתרשימים האלה מוצג שיעור החלונות שנמצאים בהמתנה או בתהליך בנקודת זמן מסוימת. בתרשים Timers pending by stage (המתנה לטיימרים לפי שלב) מצוין מספר החלונות שמתעכבים בגלל צווארי בקבוק. בתרשים Timers processing by stage מוצג מספר החלונות שאוספים רכיבים.

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

מדדי משאבים

המדדים הבאים מופיעים בקטע מדדי משאבים.

ניצול יחידת העיבוד המרכזית (CPU)

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

• ניצול יחידת העיבוד המרכזית (CPU) (כל העובדים)
• ניצול יחידת העיבוד המרכזית (CPU) (נתונים סטטיסטיים)
• ניצול יחידת העיבוד המרכזית (CPU) (4 המובילים)
• ניצול יחידת העיבוד המרכזית (CPU) (4 התחתונים)

שימוש בזיכרון

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

• ניצול הזיכרון המקסימלי של העובד (בייטים משוערים לשנייה)
• ניצול הזיכרון (בייטים משוערים לשנייה)

בתרשים Max worker memory utilization (השימוש המקסימלי בזיכרון של העובדים) מוצג מידע על העובדים שמשתמשים בזיכרון הכי הרבה במשימת Dataflow בכל נקודת זמן. אם בשלבים שונים של העבודה, העובד שמשתמש בכמות הזיכרון המקסימלית משתנה, אותה שורה בתרשים מציגה נתונים של כמה עובדים. כל נקודת נתונים בקו מציגה נתונים לגבי העובד שמשתמש בכמות הזיכרון המקסימלית באותו זמן. בתרשים מוצגת השוואה בין הזיכרון המשוער שמשמש את העובד לבין מגבלת הזיכרון בבייטים.

אפשר להשתמש בתרשים הזה כדי לפתור בעיות שקשורות לחוסר זיכרון (OOM). קריסות של תהליכי Worker בגלל חוסר זיכרון לא מוצגות בתרשים הזה.

בתרשים Memory utilization (ניצול הזיכרון) מוצגת הערכה של הזיכרון שבו נעשה שימוש על ידי כל העובדים במשימת Dataflow, בהשוואה למגבלת הזיכרון בבייטים.

מדדי קלט ופלט

אם עבודת הסטרימינג של Dataflow קוראת או כותבת רשומות באמצעות Pub/Sub, בכרטיסייה Job metrics מוצגים מדדים של קריאות או כתיבות של Pub/Sub.

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

שני התרשימים הבאים מוצגים בקטעים מדדי קלט ומדדי פלט.

בקשות לשנייה

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

שגיאות בתגובה לשנייה לפי סוג השגיאה

המדד 'שגיאות בתגובה לשנייה לפי סוג שגיאה' הוא קצב הבקשות ל-API שנכשלו לקריאה או לכתיבה של נתונים לפי המקור או היעד לאורך זמן. אם שגיאות כאלה מתרחשות לעיתים קרובות, יכול להיות שעיבוד בקשות ה-API האלה יתבצע לאט יותר. צריך לבדוק בקשות API שנכשלו. כדי לפתור את הבעיות האלה, כדאי לעיין בקודי השגיאה הכלליים של קלט ופלט. כדאי גם לעיין בתיעוד של קודי שגיאה ספציפיים שמשמשים את המקור או את היעד, כמו קודי השגיאה של Pub/Sub.

הערה: התרשים יהיה ריק עד שתתרחש השגיאה הראשונה.

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

שימוש ב-Cloud Monitoring

‫Dataflow משולב באופן מלא עם Cloud Monitoring. אפשר להשתמש ב-Cloud Monitoring למשימות הבאות:

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

הוראות ליצירת התראות ולשימוש ב-Metrics Explorer זמינות במאמר שימוש ב-Cloud Monitoring לצינורות עיבוד נתונים של Dataflow.

רשימה מלאה של מדדי Dataflow זמינה Google Cloud במאמרי העזרה בנושא מדדים.

יצירת התראות ב-Cloud Monitoring

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

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

צפייה ב-Metrics Explorer

אפשר לראות את תרשימי המדדים של Dataflow ב-Metrics Explorer, שבו אפשר ליצור שאילתות ולשנות את טווח הזמן של המדדים.

כדי לראות את התרשימים של Dataflow ב-Metrics Explorer, בתצוגה Job metrics, פותחים את More chart options ולוחצים על View in Metrics Explorer.

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

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

מדדי קלט/פלט של Dataflow

אפשר לראות את מדדי הקלט/פלט של Dataflow בMetrics Explorer:

• ‫job/pubsub/write_count: בקשות פרסום ב-Pub/Sub מ-PubsubIO.Write בעבודות Dataflow.
• ‫job/pubsub/read_count: בקשות pull של Pub/Sub מ-PubsubIO.Read במשימות של Dataflow.
• ‫job/bigquery/write_count: בקשות פרסום ב-BigQuery מ-BigQueryIO.Write בעבודות של Dataflow. מדדי job/bigquery/write_count זמינים בצינורות Python באמצעות הטרנספורמציה WriteToBigQuery עם method='STREAMING_INSERTS' שהופעלה ב-Apache Beam גרסה 2.28.0 ואילך. המדד הזה זמין גם לצנרת של עיבוד באצווה וגם לצנרת של עיבוד בזמן אמת.
• אם צינור הנתונים משתמש במקור או ביעד של BigQuery, כדי לפתור בעיות שקשורות למכסות, צריך להשתמש במדדים של BigQuery Storage API.

מדדים של DoFn

במשימות סטרימינג שמשתמשות ב-Streaming Engine ולא משתמשות ב-Portable Runner, אפשר לראות את המדדים הבאים לגבי DoFns שהוגדרו על ידי המשתמש:

• ‫job/dofn_latency_average: זמן העיבוד הממוצע של הודעה יחידה מסוג DoFn במהלך חלון הזמן של 3 הדקות האחרונות, באלפיות השנייה.
• ‫job/dofn_latency_max: זמן העיבוד המקסימלי של הודעה יחידה מסוג DoFn במהלך חלון של 3 דקות, באלפיות השנייה.
• ‫job/dofn_latency_min: זמן העיבוד המינימלי של הודעה יחידה מסוג DoFn במהלך חלון של 3 דקות, באלפיות השנייה.
• ‫job/dofn_latency_num_messages: מספר ההודעות שעובדו על ידי DoFn יחיד ב-3 הדקות האחרונות.
• ‫job/dofn_latency_total: זמן העיבוד הכולל של כל ההודעות ב-DoFn יחיד במהלך חלון של 3 דקות, באלפיות השנייה.
• ‫job/oldest_active_message_age: משך הזמן שחלף מאז שההודעה הפעילה הכי ישנה נמצאת בתהליך העיבוד בתוך DoFn, באלפיות השנייה.

כדי להשתמש במדדים האלה, צריך Apache Beam SDK בגרסה 2.53.0 ואילך. כדי לראות את המדדים האלה, משתמשים ב-Metrics Explorer.

אפשר להשתמש במדדים האלה כדי לגלות אילו DoFns תורמים הכי הרבה לזמן האחזור של העיבוד בעבודות שלכם. לדוגמה, אם עבודה נתקעת, אפשר להשתמש במדד job/oldest_active_message_age כדי למצוא את DoFn עם ההודעה הפעילה הכי ישנה. בתמונה הבאה רואים DoFn עם עלייה חדה במדד הזה:

כדי לראות את השם של DoFn, מעבירים את הסמן מעל קו הגרף.

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

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