פתרון בעיות בנושא רגיל

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

מידע נוסף על פרסום הודעות בנושאים ועל התכונות השונות

זמן אחזור ארוך של פרסום

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

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

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

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

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

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

שימו לב: חביון גבוה של פרסום עלול לגרום לשגיאות DEADLINE_EXCEEDED, שמוסברות בקטע הבא.

פעולות פרסום נכשלות עם DEADLINE_EXCEEDED

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

כדי לוודא שבקשות הפרסום מגיעות לשירות Pub/Sub, צריך לעקוב אחרי הנושא באמצעות המדד topic/send_request_count, שמקובץ לפי response_code. המדד הזה עוזר לכם לקבוע אם הבקשות נכשלות לפני שהן מגיעות לנושא Pub/Sub. אם המדד ריק, יש גורם חיצוני שמונע מההודעות להגיע לשירות Pub/Sub. בנוסף, כדי לשלול את האפשרות שמדובר בבעיה לסירוגין, כדאי לבדוק את שיעור השגיאות באמצעות הגרף של מדד topic/send_request_count שצוין קודם, או באמצעות הדף APIs & Services במסוףGoogle Cloud . אם שיעור השגיאות נמוך מאוד, יכול להיות שמדובר בבעיה לסירוגין.

אם הבקשות מגיעות ל-Pub/Sub, אלה כמה סיבות אפשריות לכך שפעולות פרסום נכשלות עם שגיאה DEADLINE_EXCEEDED:

צוואר בקבוק בצד הלקוח

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

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

  • צריך לוודא שיש מספיק רוחב פס להעלאה בין המחשב שבו האתר של בעל התוכן הדיגיטלי פועל לבין Google Cloud. בדרך כלל, רוחב הפס ברשתות Wi-Fi לפיתוח הוא 1-10 MBps, או 1,000-10,000 הודעות אופייניות לשנייה. פרסום הודעות בלולאה ללא הגבלת קצב עלול ליצור פרץ קצר של רוחב פס גבוה לאורך פרק זמן קצר. כדי להימנע מכך, אפשר להריץ את השרת במחשב בתוך Google Cloud או להפחית את קצב הפרסום של ההודעות כך שיתאים לרוחב הפס הזמין.

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

  • בסופו של דבר, יש מגבלות על כמות הנתונים שמכונה אחת יכולה לפרסם. יכול להיות שתצטרכו לנסות להרחיב את המערכת באופן אופקי או להריץ כמה מופעים של לקוח בעל האתר בכמה מכונות. במאמר בדיקת לקוחות של Cloud Pub/Sub כדי למקסם את ביצועי הסטרימינג מוסבר איך Pub/Sub מתרחב במכונה וירטואלית Google Cloud אחת עם מספר הולך וגדל של מעבדים. לדוגמה, אפשר להשיג מהירות של 500MBps עד 700MBps עבור הודעות בגודל 1KB במכונה של Compute Engine עם 16 ליבות.

משך הזמן הקצוב לתפוגה של הפרסום לא מספיק

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

בעיות בספריית לקוח

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

בעיות בסכימה

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

בעיות בהצפנה של הודעות

אם הגדרתם את נושא ה-Pub/Sub להצפנת הודעות שפורסמו באמצעות מפתח הצפנה בניהול הלקוח, יכול להיות שהפרסום ייכשל עם שגיאה FAILED_PRECONDITION. השגיאה הזו עשויה להופיע אם מפתח Cloud KMS מושבת או אם מפתחות שמנוהלים חיצונית באמצעות Cloud EKM כבר לא נגישים. כדי להמשיך לפרסם, צריך לשחזר את הגישה למפתח.

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

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

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

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

או

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

בעיות שקשורות לשינוי הודעה יחידה (SMT)

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

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

מעקב אחרי SMT

כדי להבין את הביצועים וההשפעה של כללי SMT בנושא מסוים, אפשר להשתמש במדדי המעקב הבאים:

המדד topic/message_transform_latencies מודד כמה זמן לוקח להחיל SMT על הודעה. המדד הזה מודד רק את זמן האחזור של SMT, ולא כולל חלקים אחרים של זמן מסירת ההודעה.

המדד מספק שתי תוויות מרכזיות:

  • ‫status: מדווח אם הטרנספורמציה הצליחה או אם נתקלה בבעיה.

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

המדד topic/byte_cost משמש לזיהוי הודעות שמסוננות על ידי SMT או הודעות שבהן SMT נכשל. מחפשים את הערכים הספציפיים האלה:

  • כש-SMT מסנן הודעה, הערך של operation_type הוא smt_publish_filter_drop.

  • אם SMT לא מצליח לשנות הודעה, מופיע response_code שלא OK.

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

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