ניסיון חוזר של אירועים

מתקדם

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

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

שגיאות זמניות

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

• HTTP 408 Request Timeout
• HTTP 409 Conflict
• HTTP 429 Too Many Requests
• HTTP 500 Internal Server Error
• HTTP 502 Bad Gateway
• HTTP 503 Service Unavailable
• HTTP 504 Gateway Time-out

שגיאות מתמשכות

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

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

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

ניסיון חוזר לתיקון שגיאות חולפות

ב-Eventarc Advanced נעשה שימוש בהשהיה מעריכית לפני ניסיון חוזר כדי לטפל בשגיאות שאפשר לנסות שוב. מדיניות ברירת המחדל לניסיון חוזר מתחילה בעיכוב של שנייה אחת, והעיכוב מוכפל אחרי כל ניסיון כושל (עד מקסימום של 60 שניות וחמישה ניסיונות).

אפשר לשנות את מדיניות ברירת המחדל לניסיון חוזר באמצעות מסוף Google Cloud או הפקודה gcloud eventarc pipelines update.

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

המסוף

1. במסוף Google Cloud , נכנסים לדף Eventarc > Pipelines.

   מעבר אל Pipelines

2. לוחצים על שם הצינור.

3. בדף פרטי צינור, לוחצים על עריכה.

4. בדף Edit pipeline, בקטע Retry policy, משנים את השדות הבאים:

   • מספר ניסיונות מקסימלי: מספר ניסיונות המסירה. ברירת המחדל היא 5 ניסיונות. יכול להיות כל מספר שלם חיובי. אם הערך הוא 1, לא מוחלת מדיניות ניסיון חוזר ומתבצע רק ניסיון אחד למסירת ההודעה.
   • השהיה מינימלית (בשניות): ההשהיה הראשונית בשניות. ברירת המחדל היא 1 שניות. חייב להיות בין 1 לבין 600.
   • השהיה מקסימלית (בשניות): ההשהיה המקסימלית בשניות. ברירת המחדל היא 60 שניות. חייב להיות בין 1 לבין 600.

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

5. לוחצים על Save.

gcloud

gcloud eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

מחליפים את מה שכתוב בשדות הבאים:

• ‫PIPELINE_NAME: המזהה או המזהה המוגדר במלואו של הצינור.
• ‫MIN_DELAY: העיכוב הראשוני בשניות. ברירת המחדל היא 1 שניות. חייב להיות בין 1 לבין 600.
• ‫MAX_DELAY: ההשהיה המקסימלית בשניות. ברירת המחדל היא 60 שניות. חייב להיות בין 1 לבין 600.
• ‫MAX_ATTEMPTS: מספר ניסיונות המסירה; ברירת המחדל היא 5 ניסיונות. יכול להיות כל מספר שלם חיובי. אם המדיניות מוגדרת לערך 1, לא מוחלת מדיניות ניסיון חוזר ומתבצע ניסיון אחד בלבד למסירת הודעה.

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

gcloud eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

העברת הודעות לארכיון כדי לטפל בשגיאות חוזרות

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

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

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

4. יוצרים צינור עיבוד נתונים ורישום שמנתב כל הודעה שמתקבלת באפיק (באמצעות --cel-match="true") לנושא Pub/Sub. מגדירים מדיניות ניסיון חוזר לצינור עיבוד הנתונים.

   לדוגמה, הפקודות הבאות יוצרות צינור ורישום:

   gcloud eventarc pipelines create my-archive-pipeline \
       --destinations=pubsub_topic='my-archive-topic' \
       --min-retry-delay=1 \
       --max-retry-delay=20 \
       --max-retry-attempts=6 \
       --location=us-central1
   

   gcloud eventarc enrollments create my-archive-enrollment \
       --cel-match="true" \
       --destination-pipeline=my-archive-pipeline \
       --message-bus=my-message-bus \
       --message-bus-project=my-google-cloud-project \
       --location=us-central1
   

5. העברת יומני צינורות למערך נתונים אחר ב-BigQuery.

   עכשיו אמורים להיות לכם שני מערכי נתונים נפרדים ב-BigQuery: אחד לאחסון כל ההודעות שמתקבלות באוטובוס Eventarc Advanced, ואחד לאחסון יומני הפייפליין.

6. כדי לזהות הודעות שנכשלו, משתמשים בהצהרת שאילתה כדי לצרף את שני מערכי הנתונים ב-BigQuery בשדה message_uid.

7. אחרי שמזהים את ההודעות שנכשלו, אפשר לפרסם אותן שוב באוטובוס באמצעות Eventarc Publishing API. לדוגמה, אתם יכולים לפרוס שירות או משימה של Cloud Run כדי לקרוא את ההודעות מ-BigQuery ולפרסם אותן ישירות באוטובוס המתקדם של Eventarc.

הפיכת גורמים מטפלים באירועים לאידמפוטנטיים

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

• הרבה ממשקי API חיצוניים מאפשרים לספק מפתח אידמפוטנטיות כפרמטר. אם אתם משתמשים ב-API כזה, עליכם להשתמש במקור האירוע ובמזהה שלו כמפתח האידמפוטנטיות. (המפיקים צריכים לוודא שכל אירוע שונה מקבל ערך ייחודי של source + id).
• בנוסף, אפשר להשתמש במאפיין CloudEvents‏, xgooglemessageuid, כדי לספק אידמפוטנטיות. הערך של המאפיין הזה זהה לערך בשדה message_uid בהודעות Eventarc Advanced. המזהה הייחודי של פעולת פרסום האירוע. לדוגמה, אם אותו אירוע מתפרסם פעמיים באפיק, לכל אירוע יהיה ערך xgooglemessageuid שונה כשהוא נשלח לגורם מטפל באירועים.
• אידמפוטנטיות פועלת היטב עם מסירה של פעם אחת לפחות, כי היא מאפשרת ניסיון חוזר בבטחה. לכן, שיטה מומלצת כללית לכתיבת קוד מהימן היא לשלב בין אידמפוטנטיות לבין ניסיונות חוזרים.
• חשוב לוודא שהקוד שלכם הוא אידמפוטנטי באופן פנימי. לדוגמה:
  • מוודאים שהמוטציות יכולות לקרות יותר מפעם אחת בלי לשנות את התוצאה.
  • שאילתת מצב מסד הנתונים בעסקה לפני שינוי המצב.
  • חשוב לוודא שכל תופעות הלוואי הן אידמפוטנטיות.
• להטיל בדיקה טרנזקציונלית מחוץ לשירות, ללא תלות בקוד. לדוגמה, אפשר לשמור את הסטטוס במקום כלשהו שבו מתועד שמזהה אירוע מסוים כבר עבר עיבוד.
• טיפול בשיחות כפולות מחוץ לפס. לדוגמה, אפשר להגדיר תהליך ניקוי נפרד שינקה אחרי שיחות כפולות.

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

• פתרון בעיות
• הצגה של יומני ביקורת