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

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

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

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

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

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