מעקב אחרי Pub/Sub ב-Cloud Monitoring

אתם יכולים להשתמש במסוף Google Cloud או ב-Cloud Monitoring API כדי לעקוב אחרי Pub/Sub.

במאמר הזה מוסבר איך לעקוב אחרי השימוש ב-Pub/Sub במסוף Google Cloud באמצעות Monitoring.

  • אם רוצים לראות מדדים ממשאבים אחרים Google Cloud בנוסף למדדים של Pub/Sub, צריך להשתמש ב-Monitoring.

  • אחרת, אפשר להשתמש בלוחות הבקרה של המעקב שזמינים ב-Pub/Sub. מעקב אחרי נושאים ומעקב אחרי מינויים

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

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

לפני שמשתמשים בכלי המעקב, חשוב לוודא שביצעתם את הפעולות הבאות:

  • חשבון לחיוב ב-Cloud

  • פרויקט Pub/Sub עם חיוב מופעל

אחת הדרכים לוודא שקיבלתם את שניהם היא להשלים את המדריך למתחילים לשימוש במסוף Cloud.

צפייה במרכז בקרה קיים

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

כדי לעקוב אחרי פרויקט Pub/Sub באמצעות Cloud Monitoring, מבצעים את השלבים הבאים:

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

    מעבר למעקב

  2. אם שם הפרויקט לא נבחר אוטומטית, בוחרים אותו בחלק העליון של הדף.

  3. בתפריט הניווט, לוחצים על לוחות בקרה.

  4. בדף Dashboards overview, יוצרים מרכז בקרה חדש או בוחרים את מרכז הבקרה הקיים Pub/Sub.

    כדי לחפש את מרכז הבקרה הקיים של Pub/Sub, במסנן All Dashboards, בוחרים במאפיין Name ומזינים Pub/Sub.

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

הצגת מדד יחיד של Pub/Sub

כדי לראות מדד Pub/Sub יחיד באמצעות מסוף Google Cloud , מבצעים את השלבים הבאים:

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

    מעבר למעקב

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

  3. בקטע הגדרה, לוחצים על בחירת מדד.

  4. במסנן, מזינים Pub/Sub.

  5. בקטע Active resources, בוחרים באפשרות Pub/Sub Subscription או באפשרות Pub/Sub Topic.

  6. מצמצמים את התצוגה למדד מסוים ולוחצים על החלה.

    ייפתח הדף של מדד ספציפי.

מידע נוסף על לוח הבקרה של המעקב זמין במאמר Cloud Monitoring.

צפייה במדדים ובסוגי משאבים של Pub/Sub

גישה לעורך PromQL

‫Metrics Explorer הוא ממשק ב-Cloud Monitoring שנועד לניתוח ולהצגה חזותית של נתוני המדדים. בMetrics Explorer, אפשר להשתמש בשפת השאילתות של Prometheus‏ (PromQL) כדי לשלוח שאילתות על מדדי Pub/Sub ולנתח אותם.

כדי לגשת לעורך הקוד ולשאול שאילתות על מדדי Cloud Monitoring באמצעות PromQL ב-Metrics Explorer, אפשר לעיין במאמר בנושא שימוש בעורך הקוד ל-PromQL.

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

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

מעקב אחרי השימוש במכסה

בלוח הבקרה של מכסות IAM ואדמין אפשר לראות את המכסות והשימוש הנוכחיים בפרויקט מסוים.

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

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

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

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

אם אתם צופים שתחרגו ממכסות ברירת המחדל, כדאי ליצור מדיניות התראות לכל המכסות הרלוונטיות. ההתראות האלה מופעלות כשהשימוש מגיע לחלק מסוים מהמגבלה. לדוגמה, שאילתת PromQL הבאה מפעילה מדיניות התראות כשכל מכסת Pub/Sub חורגת מ-80% שימוש:

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

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

מידע נוסף על מכסות זמין במאמר מכסות ומגבלות.

שמירה על מינוי תקין

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

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

מעקב אחרי הודעות בהמתנה

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

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

בעיות נפוצות ב-backlog

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

מעקב אחרי תקינות זמן האחזור של המסירה

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

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

  • בקשות מיקום זניחות.

  • הודעות עם אישור שלילי (NACK) שאין להן השפעה.

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

  • זמן אחזור עקבי של אישור קבלה של פחות מ-30 שניות.

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

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

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

  • הודעות עם אישור שלילי (NACK): אם המינוי קיבל בקשות לאישור שלילי (NACK) ב-10 הדקות האחרונות, הציון מוגדר ל-0. אישור שלילי גורם למסירה מחדש של הודעה עם זמן אחזור מוגדל.

  • מועדים אחרונים לאישור שחלף: אם חלפו 10 דקות מאז המועד האחרון לאישור המינוי, הציון יהיה 0. הודעות שתאריך היעד לאישור שלהן פג נמסרות מחדש עם זמן אחזור ארוך יותר.

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

  • ניצול נמוך: הניצול מחושב באופן שונה לכל סוג מינוי.

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

    • Push: אם יש יותר מדי הודעות שממתינות לשליחה לנקודת הקצה של ה-Push, הציון מוגדר ל-0. כדאי להגדיל את הקיבולת של נקודת הקצה של הודעות הפוש כדי שתהיה לכם קיבולת להודעות חדשות.

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

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

לפניכם צילום מסך של המדד ששורטט לתקופה של שעה אחת באמצעות תרשים שטח משולב. הציון המשולב של תקינות החשבון עולה ל-5 בשעה 4:15, עם ציון של 1 לכל קריטריון. בהמשך, הציון המשולב יורד ל-4 בשעה 4:20 לפנות בוקר, כשהציון של רמת הניצול יורד ל-0.

צילום מסך של מדד זמן האחזור של הצגת המודעות

‫PromQL מספקת ממשק מבוסס-טקסט שמאפשר לשלוח שאילתות על נתונים של סדרות זמן ב-Cloud Monitoring. השאילתה הבאה ב-PromQL יוצרת תרשים למדידת ציון הבריאות של זמן האחזור של המסירה עבור מינוי.

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

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

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

  • אין הקצאה מספקת למנויים שלכם (אתם צריכים עוד תהליכים או מכונות).

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

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

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

שיעורי תפוגה גבוהים מדי של תאריכי יעד לאישורים עלולים לגרום לחוסר יעילות יקר במערכת. אתם משלמים על כל מסירה חוזרת ועל כל ניסיון לעבד כל הודעה שוב ושוב. לעומת זאת, שיעור תפוגה נמוך (לדוגמה, 0.1% עד 1%) יכול להיות תקין.

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

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

אפשר לעקוב אחרי קצב העברת הנתונים של הודעות בודדות או של הודעות שלא נשלחו באצווה, שמנוהלות על ידי המנויים, באמצעות המדד subscription/sent_message_count שסונן לפי התווית delivery_type.

השאילתה הבאה ב-PromQL יוצרת תרשים של סדרת זמנים שמציג את המספר הכולל של ההודעות שנשלחו למינוי ספציפי ב-Pub/Sub במהלך תקופה של 10 דקות. מחליפים את ערכי ה-placeholder של $PROJECT_NAME ושל $SUBSCRIPTION_NAME במזהים של הפרויקט והנושא בפועל.

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

מעקב אחר הרשמות ל-Push

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

  • subscription/push_request_count

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

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

  • subscription/num_outstanding_messages

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

  • subscription/push_request_latencies

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

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

אפשר לחשב את החלק היחסי של ההודעות שהמנויים מאשרים באמצעות PromQL. השאילתה הבאה ב-PromQL יוצרת תרשים עם החלק של ההודעות שהמנויים מאשרים במינוי:

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

מעקב אחר מינויים באמצעות מסננים

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

מדדי ה-backlog כוללים רק הודעות שתואמות למסנן.

כדי לעקוב אחרי שיעור ההודעות שאושרה קבלתן באופן אוטומטי ולא תואמות למסנן, משתמשים במדד subscription/ack_message_count עם התווית delivery_type שהערך שלה הוא filter.

כדי לעקוב אחרי התפוקה והעלות של הודעות עם אישור אוטומטי שלא תואמות למסנן, משתמשים במדד subscription/byte_cost עם התווית operation_type שהערך שלה הוא filter_drop. מידע נוסף על העמלות עבור ההודעות האלה זמין במחירון של Pub/Sub.

מעקב אחר מינויים באמצעות SMT

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

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

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

כדי לוודא שהודעות שלא ניתן למסור מועברות ב-Pub/Sub, אפשר להשוות בין המדד subscription/dead_letter_message_count לבין המדד topic/send_request_count. מבצעים את ההשוואה לנושא להודעות ללא מוצא שאליו Pub/Sub מעביר את ההודעות האלה.

אפשר גם לצרף מינוי לנושא להודעות ללא מוצא, ואז לעקוב אחרי ההודעות הלא ניתנות למסירה שמועברות במינוי הזה באמצעות המדדים הבאים:

שמירה על מצב תקין של בעל האפליקציה

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

שיעור שגיאות שניתן לנסות שוב (מתחת ל-1%) ברקע לא מעורר דאגה, כי רוב ספריות הלקוח של Cloud מנסות שוב לשלוח הודעות שנכשלו. כדאי לבדוק את שיעורי השגיאות שגדולים מ-1%. מכיוון שהאפליקציה מטפלת בקודים שלא ניתן לנסות שוב (ולא ספריית הלקוח), כדאי לבדוק את קודי התגובה. אם אין בבקשה של בעל האתר דרך טובה לאותת על מצב לא תקין, כדאי להגדיר התראה על מדד topic/send_request_count.

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

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

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

  • ‫topic/send_request_count: הנפח של הודעות batch שנשלחות על ידי בעלי תוכן דיגיטלי.

  • מספר ההודעות topic/message_sizes: נפח ההודעות הבודדות (לא בקבוצות) שנשלחות על ידי בעלי תוכן דיגיטלי.

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

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

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

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

  • אפשר להשתמש בתרשימי עמודות כדי לייצג את מספר ההודעות היומי.

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