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

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

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