מעקב אחרי 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 עם חיוב מופעל

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

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

לוח בקרה מאפשר לכם להציג ולנתח נתונים ממקורות שונים באותו הקשר. ‫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

• כדי לראות אילו מדדים Pub/Sub מדווח ל-Cloud Monitoring, אפשר לעיין ברשימת המדדים של Pub/Sub במסמכי Cloud Monitoring.

• פרטים על סוגי המשאבים במעקב pubsub_topic,‏ pubsub_subscription או pubsub_snapshot מופיעים במאמר סוגי המשאבים במעקב במסמכי העזרה של Cloud Monitoring.

גישה לעורך 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 ואדמין אפשר לראות את המכסות והשימוש הנוכחיים בפרויקט מסוים.

כדי לראות את היסטוריית השימוש במכסת האחסון, אפשר להשתמש במדדים הבאים:

• serviceruntime.googleapis.com/quota/rate/net_usage
• serviceruntime.googleapis.com/quota/limit

המדדים האלה משתמשים בסוג המשאב המפוקח 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. לדוגמה, אתם יכולים לעקוב אחרי נפח ההודעות שלא אושרו, אחרי תאריכי היעד לאישור ההודעות וכו'. אפשר גם לבדוק אם המינוי שלכם תקין מספיק כדי להשיג חביון נמוך של מסירת הודעות.

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

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

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

• הודעות שלא אושרו (subscription/num_unacked_messages_by_region) כדי לראות את מספר ההודעות שלא אושרו.

• הגיל של ההודעה הכי ישנה שלא אושרה (subscription/oldest_unacked_message_age_by_region) כדי לראות את הגיל של ההודעה הכי ישנה שלא אושרה בפיגור של המינוי.

• ציון תקינות זמן הטעינה של המסירה (subscription/delivery_latency_health_score) כדי לבדוק את התקינות הכוללת של המינוי ביחס לזמן הטעינה של המסירה. מידע נוסף על המדד הזה מופיע בקטע הרלוונטי במסמך הזה.

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

שימוש בגרסה האזורית של המדדים במקום בגרסאות הגלובליות

שירות Pub/Sub מציע גרסאות אזוריות וגלובליות של המדדים שמשמשים למעקב אחר ה-backlog של המינוי. חשוב לוודא שאתם משתמשים בגרסאות האזוריות עם הסיומת by_region:

• ‫subscription/num_unacked_messages_by_region (במקום subscription/num_undelivered_messages)
• ‫subscription/oldest_unacked_message_age_by_region (במקום subscription/oldest_unacked_message_age)

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

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

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

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

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

  • משיכה: אם אין לכם מספיק בקשות משיכה פתוחות, הציון יהיה 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) של הודעה מסוימת. התקופה הזו נקראת 'מועד אחרון לאישור קבלה'. אם המנויים לא מאשרים את קבלת ההודעות בזמן, ההודעות נשלחות מחדש, והמנויים רואים הודעות כפולות. יכולות להיות לכך כמה סיבות:

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

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

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

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

• Pull and StreamingPull: subscription/expired_ack_deadlines_count

• הודעת פוש: subscription/push_request_count מסונן לפי response_code != "success"

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

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

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

• משיכה: subscription/pull_request_count (הערה: יכול להיות שהמדד הזה יכלול גם בקשות משיכה שלא הוחזרו עם הודעות)

• ‫StreamingPull: subscription/streaming_pull_response_count

אתם יכולים לעקוב אחרי קצב העברת הנתונים של הודעות בודדות או של הודעות שלא נשלחו באצווה, שמטופלות על ידי המנויים שלכם, באמצעות המדד 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])
)

מעקב אחרי מינויים לקבלת עדכונים

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

• subscription/push_request_count

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

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

• subscription/num_outstanding_messages

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

• subscription/push_request_latencies

  המדד הזה עוזר להבין את התפלגות זמן האחזור של נקודת הקצה של ה-push. בגלל המגבלה על מספר ההודעות שלא נמסרו, חביון נקודת הקצה משפיע על קצב העברת הנתונים של המינוי. אם העיבוד של כל הודעה נמשך 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 מעביר את ההודעות האלה.

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

• subscription/num_unacked_messages_by_region

  מספר ההודעות שהועברו שהצטברו במינוי

• subscription/oldest_unacked_message_age_by_region

  הגיל של ההודעה הכי ישנה שהועברה במינוי

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

המטרה העיקרית של בעל תוכן דיגיטלי היא לשמור את נתוני ההודעות במהירות. מעקב אחרי הביצועים האלה באמצעות 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}])
)

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

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

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

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

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

• מידע נוסף על השימוש ב-PromQL כדי ליצור תרשימי מעקב זמין במאמר שימוש בעורך הקוד ל-PromQL.

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